Re: [PATCH] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Thu, Apr 26, 2018 at 4:01 AM, David Sterba <dste...@suse.cz> wrote: > On Wed, Apr 25, 2018 at 09:40:34AM +0800, Liu Bo wrote: >> path->keep_lock is set but @path immediatley gets released, this sets >> ->keep_lock only when it's necessary. > > Can you please wr

[PATCH] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

path->keep_lock is set but @path immediatley gets released, this sets ->keep_lock only when it's necessary. Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- fs/btrfs/tree-defrag.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/btrfs/tree-defrag.c b/f

Re: [PATCH] btrfs: fix unaligned access in readdir

on a sparc64 machine: > > Kernel unaligned access at TPC[102f3080] btrfs_real_readdir+0x51c/0x718 > [btrfs] > Reviewed-by: Liu Bo <bo@linux.alibaba.com> thanks, liubo > Fixes: 23b5ec74943 ("btrfs: fix readdir deadlock with pagefault") > CC: sta...@vger.ke

Re: [PATCH] Btrfs: clean up resources during umount after trans is aborted

On Tue, Apr 17, 2018 at 03:34:04PM +0200, David Sterba wrote: > On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote: > > Currently if some fatal errors occur, like all IO get -EIO, resources > > would be cleaned up when > > a) transaction is being committed or > > b)

Re: [PATCH] btrfs: don't bug_on with enomem in __clear_state_bit

On Fri, Apr 13, 2018 at 1:28 PM, Josef Bacik wrote: > From: Josef Bacik > > Since we're allocating under atomic we could every easily enomem, so if > that's the case and we can block then loop around and try to allocate > the prealloc not under a lock. > > We

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Tue, Apr 10, 2018 at 5:12 AM, David Sterba <dste...@suse.cz> wrote: > On Mon, Apr 09, 2018 at 06:23:14PM -0700, Liu Bo wrote: >> >>> As maybe_insert_hole is only called by btrfs_cont_expand here, which >> >>> means it's a really hole, I don't expect drop

Re: [PATCH v2 1/2] btrfs: Factor out read portion of btrfs_get_blocks_direct

On Wed, Apr 11, 2018 at 12:54 AM, Nikolay Borisov wrote: > Currently this function handles both the READ and WRITE dio cases. This > is facilitated by a bunch of 'if' statements, a goto short-circuit > statement and a very perverse aliasing of "!created"(READ) case > by setting

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Fri, Apr 6, 2018 at 10:43 AM, Liu Bo <obuil.li...@gmail.com> wrote: > On Fri, Apr 6, 2018 at 6:21 AM, David Sterba <dste...@suse.cz> wrote: >> On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote: >>> On Thu, Apr 5, 2018 at 9:48 AM, David Sterba <dste...@sus

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Fri, Apr 6, 2018 at 6:21 AM, David Sterba <dste...@suse.cz> wrote: > On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote: >> On Thu, Apr 5, 2018 at 9:48 AM, David Sterba <dste...@suse.cz> wrote: >> > On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote: >

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Thu, Apr 5, 2018 at 9:48 AM, David Sterba <dste...@suse.cz> wrote: > On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote: >> This is running in a typical write path, not inside a critical path >> where we have to abort the running transaction, so it's OK to return

Re: [PATCH] Btrfs: clean up resources during umount after trans is aborted

On Thu, Apr 5, 2018 at 9:11 AM, David Sterba <dste...@suse.cz> wrote: > On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote: >> Currently if some fatal errors occur, like all IO get -EIO, resources >> would be cleaned up when >> a) transaction is being committed or

[PATCH v2] Btrfs: bail out on error during replay_dir_deletes

ay Borisov <nbori...@suse.com> Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- v2: Add Fixes tag and reviewed-by.~ fs/btrfs/tree-log.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 4ee9431..11e2c26 100644 ---

[PATCH v2] Btrfs: fix NULL pointer dereference in log_dir_items

onous operations") Reviewed-by: Nikolay Borisov <nbori...@suse.com> Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- v2: Add Fixes tag and reviewed-by. fs/btrfs/tree-log.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs

Re: [PATCH] Btrfs: fix NULL pointer dereference in log_dir_items

On Sun, Apr 1, 2018 at 3:03 AM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 31.03.2018 01:11, Liu Bo wrote: >> 0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is >> returned, path->nodes[0] could be NULL, log_dir_items lacks such a >&g

[PATCH] Btrfs: bail out on error during replay_dir_deletes

If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs to bail out, otherwise @ret would be forced to be 0 after 'break;' and the caller won't be aware of it. Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- fs/btrfs/tree-log.c | 4 +++- 1 file changed, 3 insertions

[PATCH] Btrfs: fix NULL pointer dereference in log_dir_items

0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is returned, path->nodes[0] could be NULL, log_dir_items lacks such a check for <0 and we may run into a null pointer dereference panic. Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- fs/btrfs/tree-log.c |

[PATCH] Btrfs: clean up resources during umount after trans is aborted

ans hanlde is marked as aborted while BTRFS_FS_STATE_ERROR is not set, so resources remain in memory. This makes btrfs also check BTRFS_FS_STATE_TRANS_ABORTED to make sure that all resources won't stay in memory after umount. Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- fs/btrfs/disk

Re: [PATCH] Btrfs: print error messages when failing to read trees

On Wed, Mar 28, 2018 at 11:24 PM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 29.03.2018 01:11, Liu Bo wrote: >> When mount fails to read trees like fs tree, checksum tree, extent >> tree, etc, there is not enough information about where went wrong. >

[PATCH] Btrfs: print error messages when failing to read trees

When mount fails to read trees like fs tree, checksum tree, extent tree, etc, there is not enough information about where went wrong. With this, messages like "BTRFS warning (device sdf): failed to read root (objectid=7): -5" would help us a bit. Signed-off-by: Liu Bo <bo@linu

[PATCH V2] Btrfs: replace: cache rbio when rebuild data on missing device

Rebuild on missing device is as same as recover, after it's done, rbio has data which is consistent with on-disk data, so it can be cached to avoid further reads. Signed-off-by: Liu Bo <bo.li@oracle.com> Signed-off-by: Liu Bo <bo@linux.alibaba.com> --- v2: Add comments to

Re: Status of RAID5/6

On Wed, Mar 21, 2018 at 9:50 AM, Menion <men...@gmail.com> wrote: > Hi all > I am trying to understand the status of RAID5/6 in BTRFS > I know that there are some discussion ongoing on the RFC patch > proposed by Liu bo > But it seems that everything stopped last summary. Also

Re: Crashes running btrfs scrub

On Tue, Mar 20, 2018 at 7:01 PM, Qu Wenruo wrote: > > > On 2018年03月21日 01:44, Mike Stevens wrote: >> 30 devices is really not that much, heck you get 90 disks top load JBOD storage chassis these days and BTRFS does sound like an attractive choice for things

Re: Crashes running btrfs scrub

On Sun, Mar 18, 2018 at 3:52 PM, waxhead <waxh...@dirtcellar.net> wrote: > Liu Bo wrote: >> >> On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo <obuil.li...@gmail.com> wrote: >>> >>> On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens <michael.stev...@bayer.co

Re: Crashes running btrfs scrub

On Sat, Mar 17, 2018 at 5:26 PM, Liu Bo <obuil.li...@gmail.com> wrote: > On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens <michael.stev...@bayer.com> > wrote: >>> Could you please paste the whole dmesg, it looks like it hit >>> btrfs_abort_transaction(), >&

Re: Crashes running btrfs scrub

On Fri, Mar 16, 2018 at 2:46 PM, Mike Stevens wrote: >> Could you please paste the whole dmesg, it looks like it hit >> btrfs_abort_transaction(), >> which should give us more information about where goes wrong. > > The whole thing is here https://pastebin.com/4ENq2saQ

Re: Crashes running btrfs scrub

On Thu, Mar 15, 2018 at 2:07 PM, Mike Stevens wrote: >> That's a hell of a filesystem. RAID5 and RAID5 is unstable and should >> not be used for anything but throw away data. You will be happy that you >> value you data enough to have backups because all sensible

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

pose_list+0x35/0x50 >prune_icache_sb+0x42/0x50 >super_cache_scan+0x139/0x190 >shrink_slab+0x262/0x5b0 >shrink_node+0x2eb/0x2f0 >kswapd+0x2eb/0x890 >kthread+0x102/0x140 >ret_from_fork+0x3a/0x50 > > stack backtrace: > CPU: 1 PID:

Re: [PATCH] btrfs: Document parameters of btrfs_reserve_extent

you please pick another word instead of "memory", like hole or extent or space? Others look good to me. Reviewed-by: Liu Bo <bo@linux.alibaba.com> thanks, liubo > + * allocator should try to satisfy. In some cases > + *

Re: [PATCH] missing initialization in btrfs_check_shared

On Wed, Mar 14, 2018 at 8:03 AM, Edmund Nadolski wrote: > This patch addresses an issue that causes fiemap to falsely > report a shared extent. The test case is as follows: > > # cat do_xfs_io > xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5 > sync

Re: [PATCH v2] fstests: test regression of -EEXIST on creating new file after log replay

On Mon, Mar 12, 2018 at 07:28:26PM +0800, Eryu Guan wrote: > On Sat, Mar 10, 2018 at 04:56:04PM -0700, Liu Bo wrote: > > The regression is introduced to btrfs in linux v4.4 and it refuses to create > > new files after log replay by returning -EEXIST. > > > > Although t

[PATCH v2] fstests: test regression of -EEXIST on creating new file after log replay

new inode Reviewed-by: Filipe Manana <fdman...@suse.com> Signed-off-by: Liu Bo <bo.li@oracle.com> --- v2: - Remove failed message from 481.out - Drop the unnecessary write in creating a file tests/generic/481 | 75 +++ tests

Re: [PATCH] Btrfs: replace: cache rbio when rebuild data on missing device

On Tue, Mar 06, 2018 at 12:28:18PM +0100, David Sterba wrote: > On Fri, Mar 02, 2018 at 04:10:38PM -0700, Liu Bo wrote: > > Rebuild on missing device is as same as recover, after it's done, rbio > > has data which is consistent with on-disk data, so it can be cached to > >

Re: Inconsistence between sender and receiver

On Thu, Mar 08, 2018 at 03:29:48PM +, Filipe Manana wrote: > On Wed, Mar 7, 2018 at 6:49 PM, Liu Bo <bo.li@oracle.com> wrote: > > Hi, > > > > In the following steps[1], if on receiver side has got > > changed via 'btrfs property set', then after doing

Re: Inconsistence between sender and receiver

On Thu, Mar 08, 2018 at 09:15:50AM +0300, Andrei Borzenkov wrote: > 07.03.2018 21:49, Liu Bo пишет: > > Hi, > > > > In the following steps[1], if on receiver side has got > > changed via 'btrfs property set', then after doing incremental > > updates, receiver ge

Re: [PATCH] fstests: test regression of -EEXIST on creating new file after log replay

On Thu, Mar 08, 2018 at 10:07:33AM +, Filipe Manana wrote: > On Wed, Mar 7, 2018 at 11:59 PM, Liu Bo <bo.li@oracle.com> wrote: > > The regression is introduced to btrfs in linux v4.4 and it refuses to create > > new files after log replay by returning -EEXIST. > &g

[PATCH] fstests: test regression of -EEXIST on creating new file after log replay

new inode Signed-off-by: Liu Bo <bo.li@oracle.com> --- tests/generic/481 | 75 +++ tests/generic/481.out | 5 tests/generic/group | 1 + 3 files changed, 81 insertions(+) create mode 100755 tests/generic/481 create mode

[PATCH v2] Btrfs: scrub: batch rebuild for raid56

of reads during rebuild can be avoided, the parity recover calculation(xor or raid6 algorithms) needs to be done $(BTRFS_STRIPE_LEN / blocksize) times. This makes it smarter by doing raid56 scrub/replace on stripe length. Signed-off-by: Liu Bo <bo.li@oracle.com> --- v2: - Place bio allo

Inconsistence between sender and receiver

Hi, In the following steps[1], if on receiver side has got changed via 'btrfs property set', then after doing incremental updates, receiver gets a different snapshot from what sender has sent. The reason behind it is that there is no change about file 'foo' in the send stream, such that

Re: [PATCH] Btrfs: scrub: batch rebuild for raid56

On Tue, Mar 06, 2018 at 11:47:47AM +0100, David Sterba wrote: > On Fri, Mar 02, 2018 at 04:10:37PM -0700, Liu Bo wrote: > > In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K) > > as unit, however, scrub_extent() sets blocksize as unit, so rebuild > > pro

[PATCH] Btrfs: send: fix typo in TLV_PUT

According to tlv_put()'s prototype, data and attrlen needs to be exchanged in the macro, but seems all callers are already aware of this misorder and are therefore not affected. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/send.c | 4 ++-- 1 file changed, 2 insertions

[PATCH] Btrfs: replace: cache rbio when rebuild data on missing device

Rebuild on missing device is as same as recover, after it's done, rbio has data which is consistent with on-disk data, so it can be cached to avoid further reads. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/raid56.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

[PATCH] Btrfs: scrub: remove unnecessary variable set

Variable "success" is only checked when !sctx->is_dev_replace. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/scrub.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index e3203a1..1b5ce2f 100644 --- a/fs/btrfs/scrub.c +++

[PATCH] Btrfs: dev-replace: make sure target is identical to source when raid56 rebuild fails

rather write what is stored in the source device than the data calculuated from parity. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/scrub.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index 1b5ce2f..f449dc6

[PATCH] Btrfs: raid56: remove redundant async_missing_raid56

async_missing_raid56() is identical to async_read_rebuild(). Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/raid56.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c index bb8a3c5..efb42dc 100644 --

[PATCH] Btrfs: scrub: batch rebuild for raid56

In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K) as unit, however, scrub_extent() sets blocksize as unit, so rebuild process may be triggered on every block on a same stripe. A typical example would be that when we're replacing a disappeared disk, all reads on the disks

Re: [PATCH] Btrfs: fix log replay failure after unlink and link combination

On Fri, Mar 02, 2018 at 11:29:33AM -0700, Liu Bo wrote: > On Wed, Feb 28, 2018 at 03:56:10PM +, fdman...@kernel.org wrote: > > From: Filipe Manana <fdman...@suse.com> > > > > If we have a file with 2 (or more) hard links in the same directory, > > remove on

Re: [PATCH] Btrfs: fix log replay failure after unlink and link combination

On Wed, Feb 28, 2018 at 03:56:10PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > If we have a file with 2 (or more) hard links in the same directory, > remove one of the hard links, create a new file (or link an existing file) > in the same directory with the

Re: [PATCH 1/2] Btrfs: fix log replay failure after linking special file and fsync

y > exists in both trees, but have different index, the log replay fails with > an -EEXIST error when attempting to replay the inode reference from the > log tree. > > Fix this by setting the last_unlink_trans field of the inode (our special > file) to the current transaction id when a

Re: Ongoing Btrfs stability issues

On Thu, Mar 01, 2018 at 09:40:41PM +0200, Nikolay Borisov wrote: > > > On 1.03.2018 21:04, Alex Adriaanse wrote: > > On Feb 16, 2018, at 1:44 PM, Austin S. Hemmelgarn > > wrote: ... > > > [496003.641729] BTRFS: error (device xvdc) in __btrfs_free_extent:7076: > >

Re: [PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

On Wed, Feb 28, 2018 at 04:06:40PM +, Filipe Manana wrote: > On Thu, Jan 25, 2018 at 6:02 PM, Liu Bo <bo.li@oracle.com> wrote: > > The highest objectid, which is assigned to new inode, is decided at > > the time of initializing fs roots. However, in cases wher

[PATCH] Btrfs: dev-replace: skip prealloc extents when copy nocow pages

It doens't make sense to process prealloc extents as pages will be filled with zero when reading prealloc extents. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/scrub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c

Re: [PATCH 1/1] btrfs: introduce feature to forget a btrfs device

On Thu, Jan 11, 2018 at 09:25:50AM +0800, Anand Jain wrote: > Support for a new command 'btrfs dev forget [dev]' is proposed here, > to undo the effects of 'btrfs dev scan [dev]'. For this purpose, > this patch proposes to use ioctl #5 as it was empty. > IOW(BTRFS_IOCTL_MAGIC, 5, ..) > This

Re: [PATCH] btrfs: Fix locking during DIO read

On Thu, Feb 22, 2018 at 12:09:45PM -0700, Liu Bo wrote: > On Thu, Feb 22, 2018 at 08:49:30AM +0200, Nikolay Borisov wrote: > > > > > > On 22.02.2018 00:38, Liu Bo wrote: > > > On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote: > > >> On W

Re: [PATCH] btrfs: Fix locking during DIO read

On Thu, Feb 22, 2018 at 08:49:30AM +0200, Nikolay Borisov wrote: > > > On 22.02.2018 00:38, Liu Bo wrote: > > On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote: > >> On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo <bo.li@oracle.com> wrote: > >>>

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 07:05:13PM +, Filipe Manana wrote: > On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo <bo.li@oracle.com> wrote: > > On Wed, Feb 21, 2018 at 02:42:08PM +, Filipe Manana wrote: > >> On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov &

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 04:15:38PM +0200, Nikolay Borisov wrote: > > > On 21.02.2018 15:51, Filipe Manana wrote: > > On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov wrote: > >> Currently the DIO read cases uses a botched idea from ext4 to ensure > >> that DIO reads don't

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 02:42:08PM +, Filipe Manana wrote: > On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov wrote: > > > > > > On 21.02.2018 15:51, Filipe Manana wrote: > >> On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov > >> wrote: > >>> Currently

Re: [PATCH v2 02/27] Add libbtrfsutil

e mode 100644 libbtrfsutil/errors.c > > diff --git a/.gitignore b/.gitignore > index 8e607f6e..272d53e4 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -43,6 +43,8 @@ libbtrfs.so.0.1 > library-test > library-test-static > /fssum > +/libbtrfsutil.so* > +/libbtr

Re: [PATCH v2] btrfs: fix endianness compatibility during the SB RW

On Tue, Feb 13, 2018 at 11:00:46AM +0800, Anand Jain wrote: > Fixes the endianness bug in the fs_info::super_copy by using its > btrfs_set_super...() function to set values in the SB, as these > functions manage the endianness compatibility nicely. Reviewed-by: Liu Bo <bo.li...

Re: [PATCH] Fix NULL pointer exception in find_bio_stripe()

id56.c > @@ -1370,6 +1370,7 @@ static int find_bio_stripe(struct btrfs_raid_bio *rbio, > stripe_start = stripe->physical; > if (physical >= stripe_start && > physical < stripe_start + rbio->stripe_len && > +

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Mon, Feb 12, 2018 at 07:39:02PM +0200, Nikolay Borisov wrote: > > > On 12.02.2018 16:17, Liu Bo wrote: > > On Tue, Feb 06, 2018 at 11:11:55AM +0200, Nikolay Borisov wrote: [...] > >> > >> Use list_for_each_entry_safe to make it more apparent you are going

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Fri, Feb 09, 2018 at 06:02:01PM +0100, Goffredo Baroncelli wrote: > On 02/08/2018 08:07 PM, Liu Bo wrote: > > On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote: > >> On 02/06/2018 12:15 AM, Liu Bo wrote: > >> [...] > >>> One way to mitiga

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Thu, Feb 08, 2018 at 08:57:39PM -0800, Darrick J. Wong wrote: > On Mon, Feb 05, 2018 at 04:15:02PM -0700, Liu Bo wrote: > > Btrfs tries its best to tolerate write errors, but kind of silently > > (except some messages in kernel log). > > > > For raid1 and raid10, th

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Thu, Feb 08, 2018 at 05:47:46PM +0800, Anand Jain wrote: > > > On 02/06/2018 07:15 AM, Liu Bo wrote: > > Btrfs tries its best to tolerate write errors, but kind of silently > > (except some messages in kernel log). > > > > For raid1 and raid10, this

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Tue, Feb 06, 2018 at 11:11:55AM +0200, Nikolay Borisov wrote: > > > On 6.02.2018 01:15, Liu Bo wrote: > > Btrfs tries its best to tolerate write errors, but kind of silently > > (except some messages in kernel log). > > > > For raid1 and raid10, this

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote: > On 02/06/2018 12:15 AM, Liu Bo wrote: > [...] > > One way to mitigate the data loss pain is to expose 'bad chunks', > > i.e. degraded chunks, to users, so that they can use 'btrfs balance' > > to

Re: [PATCH 1/2] btrfs: Remove invalid null checks from btrfs_cleanup_dirty_bgs

Additionally, for the dirty_bgs list the iteration is done under > dirty_bgs_lock which ensures consistency of the list. > Reviewed-by: Liu Bo <bo.li@oracle.com> -liubo > Signed-off-by: Nikolay Borisov <nbori...@suse.com> > --- > fs/btrfs/disk-io.c | 9 - >

Re: [PATCH RFC] Btrfs: expose bad chunks in sysfs

On Tue, Feb 06, 2018 at 09:28:14AM +0800, Qu Wenruo wrote: > > > On 2018年02月06日 07:15, Liu Bo wrote: > > Btrfs tries its best to tolerate write errors, but kind of silently > > (except some messages in kernel log). > > > > For raid1 and raid10, this

[PATCH RFC] Btrfs: expose bad chunks in sysfs

'btrfs balance' to relocate the whole chunk and get the full raid6 protection again (if the relocation works). This introduces 'bad_chunks' in btrfs's per-fs sysfs directory. Once a chunk of raid5 or raid6 becomes degraded, it will appear in 'bad_chunks'. Signed-off-by: Liu Bo <bo.li@oracle.

[PATCH v2] Btrfs: fix unexpected cow in run_delalloc_nocow

x nodatasum handling in balancing code") Signed-off-by: Liu Bo <bo.li@oracle.com> --- v2: fix error handling after btrfs_cross_ref_exist(). fs/btrfs/inode.c | 37 - 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs

Re: [PATCH] btrfs: btrfs_evict_inode must clear all inodes

On Mon, Jan 29, 2018 at 11:46:28AM -0500, Jeff Mahoney wrote: > btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict(). > > Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction) > Cc: Nikolay Borisov > Cc: # v4.8+ >

[PATCH] Btrfs: do not check inode's runtime flags under root->orphan_lock

It's not necessary to hold ->orphan_lock when checking inode's runtime flags. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/inode.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index b3fe0a8

[PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv

ic_dec(>orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <sta...@vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode

[PATCH] Btrfs: fix crash due to not cleaning up tree log block's dirty bits

ree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <sta...@vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li@

[PATCH] Btrfs: fix unexpected -EEXIST when creating new inode

up with -EEXIST. cc: <sta...@vger.kernel.org> v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/tree-log.c | 19 +++ 1 fi

[PATCH] Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly

This could end up hitting BUG_ON(inode->i_state != (I_FREEING | I_CLEAR)); in evict() because I_CLEAR is set in clear_inode(). Fixes: commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction") Cc: <sta...@vger.kernel.org> # v4.7-rc6+ Signed-off-by: Liu Bo <bo.li@or

[PATCH] Btrfs: enhance leak debug checker for extent state and extent buffer

This prints out eb->bflags since it contains some useful information, e.g. whether eb is dirty. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/extent_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c inde

[PATCH] Btrfs: fix extent state leak from tree log

with EXTENT_NEED_WAIT lead to memory leak. cc: <sta...@vger.kernel.org> Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/tree-log.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 22046ed..a7e6235 100644 --- a/f

[PATCH] Btrfs: fix unexpected cow in run_delalloc_nocow

x nodatasum handling in balancing code") Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/inode.c | 37 - 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e1a7f3c..ac1a1ac 100644 --- a/fs/btrfs/

[PATCH] Btrfs: fix deadlock in run_delalloc_nocow

@cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <sta...@vger.kernel.org> Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/inode.c | 5 - 1 fil

[PATCH] Fstests: btrfs/011 fix device mounted when tests aborts

. Signed-off-by: Liu Bo <bo.li@oracle.com> --- tests/btrfs/011 | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/btrfs/011 b/tests/btrfs/011 index 28f1388..f4c5309 100755 --- a/tests/btrfs/011 +++ b/tests/btrfs/011 @@ -51,6 +51,7 @@ _cleanup() fi wait

[PATCH] Fstests: btrfs/027 unmount scratch device if test fails

is mounted _scratch_unmount is added to avoid the above. Signed-off-by: Liu Bo <bo.li@oracle.com> --- tests/btrfs/027 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/btrfs/027 b/tests/btrfs/027 index 625a27f..689cd4c 100755 --- a/tests/btrfs/027 +++ b/tests/btrfs/027 @@ -95,6

Re: [PATCH] fstests: common/rc: fix device still mounted error with SCRATCH_DEV_POOL

On Mon, Jan 15, 2018 at 02:22:28PM +0800, Eryu Guan wrote: > On Fri, Jan 12, 2018 at 06:04:59PM -0700, Liu Bo wrote: > > One of btrfs tests, btrfs/011, uses SCRATCH_DEV_POOL and puts a > > non-SCRATCH_DEV > > device as the first one when doing mkfs, and this makes > >

[PATCH] Btrfs: do not cache rbio pages if using raid6 recover

->bio_pages gets modified, others remain the same so that their in-memory content is consistent with their on-disk content. This adds a check to skip caching rbio if using raid6 recover. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/raid56.c | 17 - 1 fil

[PATCH] Btrfs: raid56: iterate raid56 internal bio with bio_for_each_segment_all

xes: 6592e58c6b68e61f003a01ba29a3716e7e2e9484 ("Btrfs: fix write corruption due to bio cloning on raid5/6") Cc: <sta...@vger.kernel.org> # v4.12-rc6+ Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/raid56.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/rai

[PATCH] fstests: common/rc: fix device still mounted error with SCRATCH_DEV_POOL

and the following tests complain about 'device still mounted' alike errors. Introduce a helper to address this special case where both btrfs and scratch dev pool are in use. Signed-off-by: Liu Bo <bo.li@oracle.com> --- common/rc | 31 +++ 1 file changed, 31 insertions(+)

Re: [PATCH v5 00/19] fs: rework and optimize i_version handling in filesystems

On Tue, Jan 09, 2018 at 09:10:40AM -0500, Jeff Layton wrote: > From: Jeff Layton > > v5: > - don't corrupt refcounts stashed in i_version of ext4 xattr inodes > - add raw variants of inc and cmp functions, and have nfs use them > > v4: > - fix SB_LAZYTIME handling in

Re: [PATCH v5 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed

in-memory inode in update_time_for_write(), - step 2 is to update the time/iversion of on-disk inode in btrfs_update_inode()->fill_inode_item(). I think update_time_for_write() also needs to be updated to use the new iversion API. With that, Reviewed-by: Liu Bo <bo.li@oracle.co

[PATCH v2] Btrfs: raid56: fix race between merge_bio and rbio_orig_end_io

ugloub.eu> Signed-off-by: Liu Bo <bo.li@oracle.com> --- v2: - Remove the usage spin_lock as there is a chance of deadlock in interrupt context, it's reported by lockdep, although it'd never happen because we've taken care of it by saving irq flags at all places. -

[PATCH v2 00/10] bugfixes and regression tests of btrfs_get_extent

the bug. - Adjust bugfixes to the front so that we can merge them firstly. Liu Bo (10): Btrfs: fix incorrect block_len in merge_extent_mapping Btrfs: fix unexpected EEXIST from btrfs_get_extent Btrfs: add helper for em merge logic Btrfs: move extent map specific code to extent_map.c Btrfs: a

[PATCH v2 04/10] Btrfs: move extent map specific code to extent_map.c

These helpers are extent map specific, move them to extent_map.c. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/ctree.h | 2 - fs/btrfs/extent_map.c | 125 ++ fs/btrfs/extent_map.h | 2 + fs/btrfs/inode.c

[PATCH v2 08/10] Btrfs: add WARN_ONCE to detect unexpected error from merge_extent_mapping

This is a subtle case, so in order to understand the problem, it'd be good to know the content of existing and em when any error occurs. Signed-off-by: Liu Bo <bo.li@oracle.com> --- v2: Remove unnecessary KERN_INFO. fs/btrfs/extent_map.c | 8 +++- 1 file changed, 7 insertions

[PATCH v2 10/10] Btrfs: noinline merge_extent_mapping

In order to debug subtle bugs around merge_extent_mapping(), perf probe can be used to check the arguments, but sometimes merge_extent_mapping() got inlined by compiler and couldn't be probed. This is adding noinline attribute to merge_extent_mapping(). Signed-off-by: Liu Bo <bo

[PATCH v2 07/10] Btrfs: extent map selftest: dio write vs dio read

This test case simulates the racy situation of dio write vs dio read, and see if btrfs_get_extent() would return -EEXIST. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/tests/extent-map-tests.c | 88 +++ 1 file changed, 88 insertions(+) diff

[PATCH v2 06/10] Btrfs: extent map selftest: buffered write vs dio read

This test case simulates the racy situation of buffered write vs dio read, and see if btrfs_get_extent() would return -EEXIST. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/tests/extent-map-tests.c | 73 +++ 1 file changed, 73 insertions(+)

[PATCH v2 01/10] Btrfs: fix incorrect block_len in merge_extent_mapping

gly, and for regular extent, em->block_len always equals to em->len, hence this sets em->block_len with em->len. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/

[PATCH v2 02/10] Btrfs: fix unexpected EEXIST from btrfs_get_extent

+ start As we can see, it turns out that if start is within existing em (front inclusive), then the existing em should be returned as is, otherwise, we try our best to merge candidate em with sibling ems to form a larger em (in order to reduce the total number of em). Report

[PATCH v2 09/10] Btrfs: add tracepoint for em's EEXIST case

This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the subtle bugs around merge_extent_mapping. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/extent_map.c| 3 +++ include/trace/events/btrfs.h | 35 +++ 2 files chang

[PATCH v2 03/10] Btrfs: add helper for em merge logic

This is a prepare work for the following extent map selftest, which runs tests against em merge logic. Signed-off-by: Liu Bo <bo.li@oracle.com> --- fs/btrfs/ctree.h | 2 ++ fs/btrfs/inode.c | 80 2 files changed, 48 insertions(

Re: [PATCH v2] btrfs: not a disk error if the bio_add_page fails

On Thu, Jan 04, 2018 at 09:47:56AM -0800, Liu Bo wrote: > On Wed, Jan 03, 2018 at 09:52:43PM +0800, Anand Jain wrote: > > bio_add_page() can fail for logical reasons as from the bio_add_page() > > comments:- 'This will only fail if either > > bio->bi_vcnt == bio->bi_ma

<    1   2   3   4   5   6   7   8   9   10   >