On 16/04/2021 05:05, Damien Le Moal wrote:
[...]
> + CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
> */
[...]
> - if (ivmode == NULL)
> + if (ivmode == NULL) {
> cc->iv_gen_ops = NULL;
> - else if (strcmp(ivmode, "plain") == 0)
> +
On 2021/04/16 16:13, Johannes Thumshirn wrote:
> On 16/04/2021 05:05, Damien Le Moal wrote:
>
> [...]
>
>> +CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
>> */
>
> [...]
>
>> -if (ivmode == NULL)
>> +if (ivmode == NULL) {
>> cc->iv_gen_ops = NU
On 16/04/2021 09:30, Damien Le Moal wrote:
> On 2021/04/16 16:13, Johannes Thumshirn wrote:
>> On 16/04/2021 05:05, Damien Le Moal wrote:
>>
>> [...]
>>
>>> + CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
>>> */
>>
>> [...]
>>
>>> - if (ivmode == NULL)
>>> + if (ivmo
On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
wrote:
>
> When relocating a block group the freed up space is not discarded in one
> big block, but each extent is discarded on it's own with -odisard=sync.
>
> For a zoned filesystem we need to discard the whole block group at once,
> so btrfs_d
On 16/04/2021 11:12, Filipe Manana wrote:
> On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
> wrote:
>>
>> When relocating a block group the freed up space is not discarded in one
>> big block, but each extent is discarded on it's own with -odisard=sync.
>>
>> For a zoned filesystem we need to
On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
wrote:
>
> As a preparation for another user, rename the unused_bgs_mutex into
> reclaim_bgs_lock.
>
> Signed-off-by: Johannes Thumshirn
Reviewed-by: Filipe Manana
Looks good, thanks.
> ---
> fs/btrfs/block-group.c | 6 +++---
> fs/btrfs/ct
On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
wrote:
>
> When a file gets deleted on a zoned file system, the space freed is not
> returned back into the block group's free space, but is migrated to
> zone_unusable.
>
> As this zone_unusable space is behind the current write pointer it is not
On Fri, Apr 16, 2021 at 10:14 AM Johannes Thumshirn
wrote:
>
> On 16/04/2021 11:12, Filipe Manana wrote:
> > On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
> > wrote:
> >>
> >> When relocating a block group the freed up space is not discarded in one
> >> big block, but each extent is discarde
On 16/04/2021 11:30, Filipe Manana wrote:
> The comment refers to deleting the device extent items from the device
> tree, not really extents on disk.
> I.e. it's all about the items from the block group in the chunk and
> device trees.
OK I'll move it back where it was.
On Thu, Apr 15, 2021 at 11:06:32AM -0600, Chris Murphy wrote:
> First computer/file system:
>
> (from the photo):
>
> [ 136.259984] BTRFS critical (device nvme0n1p8): corrupt leaf: root=257
> block=31259951104 slot=9 ino=3244515, name hash mismatch with key, have
> 0xF22F547D expect 0x0
On 4/15/21 7:28 PM, Qu Wenruo wrote:
On 2021/4/16 上午3:27, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
The new function, submit_eb_subpage(), will submit all the dirty extent
buffers in the page.
The major difference between submit_eb_page() and submit_eb_subpage()
is:
- How to gr
On 4/15/21 7:25 PM, Qu Wenruo wrote:
On 2021/4/16 上午3:03, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
The new function, write_one_subpage_eb(), as a subroutine for subpage
metadata write, will handle the extent buffer bio submission.
The major differences between the new write_on
On 4/15/21 1:04 AM, Qu Wenruo wrote:
The parameter @len is not really used in btrfs_bio_fits_in_stripe(),
just remove it.
Signed-off-by: Qu Wenruo
Reviewed-by: Josef Bacik
Thanks,
Josef
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Function btrfs_bio_fits_in_stripe() now requires a bio with at least one
page added.
Or btrfs_get_chunk_map() will fail with -ENOENT.
But in fact this requirement is not needed at all, as we can just pass
sectorsize for btrfs_get_chunk_map().
This tiny behav
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Unlike btrfs_file_extent_item, btrfs_ordered_extent has its length
limit (BTRFS_MAX_EXTENT_SIZE), which is far smaller than U32_MAX.
Using u64 for those length related members are just a waste of memory.
This patch will make the following members u32:
- num_
On 4/15/21 1:04 AM, Qu Wenruo wrote:
There is a pretty bad abuse of btrfs_writepage_endio_finish_ordered() in
end_compressed_bio_write().
It passes compressed pages to btrfs_writepage_endio_finish_ordered(),
which is only supposed to accept inode pages.
Thankfully the important info here is the
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Btrfs has two endio functions to mark certain io range finished for
ordered extents:
- __endio_write_update_ordered()
This is for direct IO
- btrfs_writepage_endio_finish_ordered()
This for buffered IO.
However they go different routines to handle orde
On 4/15/21 1:04 AM, Qu Wenruo wrote:
The existing comments in btrfs_invalidatepage() don't really get to the
point, especially for what Private2 is really representing and how the
race avoidance is done.
The truth is, there are only three entrances to do ordered extent
accounting:
- btrfs_writep
On 4/15/21 1:04 AM, Qu Wenruo wrote:
This patch will refactor btrfs_invalidatepage() for the incoming subpage
support.
The invovled modifcations are:
- Use while() loop instead of "goto again;"
- Use single variable to determine whether to delete extent states
Each branch will also have comme
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Currently btrfs uses page Private2 bit to incidate if we have ordered
extent for the page range.
But the lifespan of it is not consistent, during regular writeback path,
there are two locations to clear the same PagePrivate2:
T - Page marked Dirty
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Inside btrfs, we use Private2 page status to indicate we have ordered
extent with pending IO for the sector.
But the page status name, Private2, tells us nothing about the bit
itself, so this patch will rename it to Ordered.
And with extra comment about the b
On 4/15/21 1:04 AM, Qu Wenruo wrote:
As a preparation for incoming subpage support, we need bytenr passed to
__process_pages_contig() directly, not the current page index.
So change the parameter and all callers to pass bytenr in.
With the modification, here we need to replace the old @index_re
On 4/15/21 1:04 AM, Qu Wenruo wrote:
In __process_pages_contig() we update page status according to page_ops.
That update process is a bunch of if () {} branches, which lies inside
two loops, this makes it pretty hard to expand for later subpage
operations.
So this patch will extract this opera
On 4/15/21 1:04 AM, Qu Wenruo wrote:
In the coming subpage RW supports, there are a lot of page status update
calls which need to be converted to subpage compatible version, which
needs @start and @len.
Some call sites already have such @start/@len and are already in
page range, like various end
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Just like read page, for subpage support we only require sector size
alignment.
So change the error message condition to only require sector alignment.
This should not affect existing code, as for regular sectorsize ==
PAGE_SIZE case, we are still requiring
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Since the extent io tree operations in btrfs_dirty_pages() are already
subpage compatible, we only need to make the page status update to use
subpage helpers.
Signed-off-by: Qu Wenruo
Reviewed-by: Josef Bacik
Thanks,
Josef
On 4/15/21 1:04 AM, Qu Wenruo wrote:
For __process_pages_contig() and process_one_page(), to handle subpage
we only need to pass bytenr in and call subpage helpers to handle
dirty/error/writeback status.
Signed-off-by: Qu Wenruo
Reviewed-by: Josef Bacik
Thanks,
Josef
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Now in end_bio_extent_writepage(), the only subpage incompatible code is
the end_page_writeback().
Just call the subpage helpers.
Signed-off-by: Qu Wenruo
Reviewed-by: Josef Bacik
Thanks,
Josef
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Introduce a new data inodes specific subpage member, writers, to record
how many sectors are under page lock for delalloc writing.
This member acts pretty much the same as readers, except it's only for
delalloc writes.
This is important for delalloc code to
On Wed, Apr 14, 2021 at 10:33:38AM +0900, Naohiro Aota wrote:
> It also supports temporary magic ("!BHRfS_M") in zone #0. The mkfs.btrfs
> first writes the temporary superblock to the zone during the mkfs process.
> It will survive there until the zones are filled up and reset. So, we also
> need t
On Wed, Apr 14, 2021 at 03:57:42PM +0200, Karel Zak wrote:
> On Wed, Apr 14, 2021 at 10:33:39AM +0900, Naohiro Aota wrote:
> > /**
> > * blkid_do_wipe:
> > * @pr: prober
> > @@ -1267,6 +1310,7 @@ int blkid_do_wipe(blkid_probe pr, int dryrun)
> > const char *off = NULL;
> > size_t len =
On Fri, Apr 16, 2021 at 12:05:27PM +0900, Damien Le Moal wrote:
> From: Johannes Thumshirn
>
> For zoned btrfs, zone append is mandatory to write to a sequential write
> only zone, otherwise parallel writes to the same zone could result in
> unaligned write errors.
>
> If a zoned block device do
On Thu, Apr 15, 2021 at 10:58:34PM +0900, Johannes Thumshirn wrote:
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -957,7 +957,7 @@ struct btrfs_fs_info {
> spinlock_t unused_bgs_lock;
> struct list_head unused_bgs;
> struct mutex unused_bg_unpin_mutex;
> - struct mute
On Thu, Apr 15, 2021 at 10:58:35PM +0900, Johannes Thumshirn wrote:
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -954,10 +954,14 @@ struct btrfs_fs_info {
> struct work_struct async_data_reclaim_work;
> struct work_struct preempt_reclaim_work;
>
> + /* Used to reclaim da
On Thu, Apr 15, 2021 at 10:58:35PM +0900, Johannes Thumshirn wrote:
> @@ -2974,6 +2982,9 @@ void btrfs_init_fs_info(struct btrfs_fs_info *fs_info)
> fs_info->swapfile_pins = RB_ROOT;
>
> fs_info->send_in_progress = 0;
> +
> + fs_info->bg_reclaim_threshold = 75;
The value should b
On 21/04/16 02:14PM, Qu Wenruo wrote:
>
>
> On 2021/4/16 下午1:50, riteshh wrote:
> > On 21/04/16 09:34AM, Qu Wenruo wrote:
> > >
> > >
> > > On 2021/4/16 上午7:34, Qu Wenruo wrote:
> > > >
> > > >
> > > > On 2021/4/16 上午7:19, Qu Wenruo wrote:
> > > > >
> > > > >
> > > > > On 2021/4/15 下午10:52, riteshh
On Thu, Apr 15, 2021 at 2:29 PM Luis Chamberlain wrote:
>
> On Thu, Apr 15, 2021 at 02:17:58PM -0400, Josef Bacik wrote:
> > There's a lot of larger things that need to
> > be addressed in general to support the volume approach inside file systems
> > that is going to require a lot of work inside
On Tue, Apr 13, 2021 at 02:06:04PM +0100, Khaled ROMDHANI wrote:
> The variable zone is not initialized. It
> may causes a failed assertion.
Failed assertion means the 2nd one checking that the result still fits
to 32bit type. That would mean that none of the cases were hit, but all
callers pass v
On Thu, Apr 01, 2021 at 05:41:00PM +0900, Naohiro Aota wrote:
> Marking BUG() unreachable helps us silence unnecessary warnings e.g.
> "warning: control reaches end of non-void function [-Wreturn-type]" like
> the code below.
>
>int foo()
>{
>...
> if (XXX)
> return
On Wed, Apr 14, 2021 at 03:49:06PM +0800, An Long wrote:
> The exclusive ops will not start if there's one already running. The
> enqueue parameter allows operations to be queued.
>
> Signed-off-by: An Long
> ---
> .../misc-tests/048-enqueue-parameter/test.sh | 52 +++
> 1 file
On Fri, Mar 26, 2021 at 08:50:46PM +0800, Qu Wenruo wrote:
> [BUG]
> If restoring dumpped image into a new file, under most cases kernel will
> reject it:
>
> # mkfs.btrfs -f /dev/test/test
> # btrfs-image /dev/test/test /tmp/dump
> # btrfs-image -r /tmp/dump ~/test.img
> # mount ~/test.img /m
On Fri, Mar 26, 2021 at 08:50:47PM +0800, Qu Wenruo wrote:
> This new test case is to make sure the restored image file has been
> properly enlarged so that newer kernel won't complain.
>
> Signed-off-by: Qu Wenruo
> ---
> .../047-image-restore-mount/test.sh | 19 +++
>
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> Currently mkfs.btrfs will output a warning message if the sectorsize is
> not the same as page size:
> WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
> page size 65536
>
> But since btrfs subpage support f
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> Currently mkfs.btrfs will output a warning message if the sectorsize is
> not the same as page size:
> WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
> page size 65536
>
> But since btrfs subpage support f
On Tue, Apr 06, 2021 at 04:55:03PM +0300, Nikolay Borisov wrote:
> In case the right buffer is emptied it's first set to null and
> subsequently it's dereferenced to get its size to pass to root_sub_used.
> This naturally leads to a null pointer dereference. The correct thing
> to do is to pass the
On Tue, Mar 30, 2021 at 09:21:40AM -0400, Neal Gompa wrote:
> On Tue, Mar 23, 2021 at 11:53 AM David Sterba wrote:
> >
> > On Wed, Mar 17, 2021 at 04:01:43PM -0400, Neal Gompa wrote:
> > > This is a patch requesting all substantial copyright owners to sign off
> > > on changing the license of the
We are using btrfs on one of our embedded devices and we got filesystem
corruption on one of them.
This product undergo a lot of tests on our side and apparently it's the first
it happened so it seems to be a pretty rare occurrence. However we still want
to get to the bottom of this to ensure i
On Fri, Apr 16, 2021 at 11:14:08AM -0700, Boris Burkov wrote:
> On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> > +/*
> > + * The buffer size if strlen("4096 8192 16384 32768 65536"),
> > + * which is 28, then round up to 32.
>
> I think there is a typo in this comment, because it doe
On Fri, Apr 16, 2021 at 10:07:09PM +0200, David Sterba wrote:
> On Fri, Apr 16, 2021 at 11:14:08AM -0700, Boris Burkov wrote:
> > On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> > > +/*
> > > + * The buffer size if strlen("4096 8192 16384 32768 65536"),
> > > + * which is 28, then roun
On Thu, Apr 08, 2021 at 06:02:24PM +, Luis Chamberlain wrote:
> On Sat, Apr 03, 2021 at 08:25:38PM +, Luis Chamberlain wrote:
> > So creating say 1000 random files in /lib/firmware on a freshly created
> > btrfs partition helps reproduce:
> >
> > mkfs.btrfs /dev/whatever
> > mount /dev/wah
On 2021/4/16 下午9:54, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Unlike btrfs_file_extent_item, btrfs_ordered_extent has its length
limit (BTRFS_MAX_EXTENT_SIZE), which is far smaller than U32_MAX.
Using u64 for those length related members are just a waste of memory.
This patch
On 2021/4/16 下午9:58, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
There is a pretty bad abuse of btrfs_writepage_endio_finish_ordered() in
end_compressed_bio_write().
It passes compressed pages to btrfs_writepage_endio_finish_ordered(),
which is only supposed to accept inode pages.
On 2021/4/16 下午10:09, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Btrfs has two endio functions to mark certain io range finished for
ordered extents:
- __endio_write_update_ordered()
This is for direct IO
- btrfs_writepage_endio_finish_ordered()
This for buffered IO.
Howev
On 2021/4/16 下午10:42, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
This patch will refactor btrfs_invalidatepage() for the incoming subpage
support.
The invovled modifcations are:
- Use while() loop instead of "goto again;"
- Use single variable to determine whether to delete exten
On 2021/4/16 下午10:58, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
As a preparation for incoming subpage support, we need bytenr passed to
__process_pages_contig() directly, not the current page index.
So change the parameter and all callers to pass bytenr in.
With the modificatio
On 2021/4/16 下午11:13, Josef Bacik wrote:
On 4/15/21 1:04 AM, Qu Wenruo wrote:
Just like read page, for subpage support we only require sector size
alignment.
So change the error message condition to only require sector alignment.
This should not affect existing code, as for regular sectorsiz
On 2021/4/17 上午1:40, David Sterba wrote:
On Fri, Mar 26, 2021 at 08:50:46PM +0800, Qu Wenruo wrote:
[BUG]
If restoring dumpped image into a new file, under most cases kernel will
reject it:
# mkfs.btrfs -f /dev/test/test
# btrfs-image /dev/test/test /tmp/dump
# btrfs-image -r /tmp/dump
On 2021/4/17 上午1:46, David Sterba wrote:
On Fri, Mar 26, 2021 at 08:50:47PM +0800, Qu Wenruo wrote:
This new test case is to make sure the restored image file has been
properly enlarged so that newer kernel won't complain.
Signed-off-by: Qu Wenruo
---
.../047-image-restore-mount/test.sh
On 2021/4/17 上午2:14, Boris Burkov wrote:
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 6553
On 2021/4/17 上午3:35, Gervais, Francois wrote:
We are using btrfs on one of our embedded devices and we got filesystem
corruption on one of them.
This product undergo a lot of tests on our side and apparently it's the first
it happened so it seems to be a pretty rare occurrence. However we s
Hello,
I have a system that btrfs sends daily its rootfs to another system
far away. Incrementally (this is important to saving bandwidth since
we're talking about half a TB).
For a while my first system's hardware was out of commission, so I
spun it up (systemd-nspawn) on the second system since
On Fri, Apr 16, 2021 at 9:03 PM Alexandru Stan wrote:
>
> # sending back incrementally (eg: without sending back file-0) fails
> alex@alex-desktop:/mnt% sudo btrfs send bigfs/myvolume-1 -p
> bigfs/myvolume-3|sudo btrfs receive ssdfs/
> At subvol bigfs/myvolume-1
> At snapshot myvolume-
On Fri, 16 Apr 2021 at 20:29, Chris Murphy wrote:
>
> On Fri, Apr 16, 2021 at 9:03 PM Alexandru Stan wrote:
> >
> > # sending back incrementally (eg: without sending back file-0) fails
> > alex@alex-desktop:/mnt% sudo btrfs send bigfs/myvolume-1 -p
> > bigfs/myvolume-3|sudo btrfs receive ssdf
On 17.04.2021 06:29, Chris Murphy wrote:
> On Fri, Apr 16, 2021 at 9:03 PM Alexandru Stan wrote:
>>
>> # sending back incrementally (eg: without sending back file-0) fails
>> alex@alex-desktop:/mnt% sudo btrfs send bigfs/myvolume-1 -p
>> bigfs/myvolume-3|sudo btrfs receive ssdfs/
>> At sub
64 matches
Mail list logo
