Re: __link_block_group uses GFP_KERNEL

On 3/25/17, Jeff Mahoney wrote: > On 3/24/17 5:02 AM, Denis Kirjanov wrote: >> Hi guys, >> >> Looks like that current code does GFP_KERNEL allocation inside >> __link_block_group. >> the function invokes kobject_add and internally creates sysfs files >> with the GFP_KERNEL flag set. > > Yep, that'

[PATCH] Btrfs: set scrub page's io_error if failing to submit io

Otherwise, we may later skip this page when repairing bad copy from good copy. Cc: David Sterba Signed-off-by: Liu Bo --- fs/btrfs/scrub.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index b0251eb..026c2b8 100644 --- a/fs/btrfs

Re: [PATCH v2 5/5] btrfs: raid56: Use bio_counter to protect scrub

On Fri, Mar 24, 2017 at 10:00:27AM +0800, Qu Wenruo wrote: > Unlike other place calling btrfs_map_block(), in raid56 scrub, we don't > use bio_counter to protect from race against dev replace. > > This patch will use bio_counter to protect from the beginning of calling > btrfs_map_sblock(), until

Re: __link_block_group uses GFP_KERNEL

On 3/24/17 5:02 AM, Denis Kirjanov wrote: > Hi guys, > > Looks like that current code does GFP_KERNEL allocation inside > __link_block_group. > the function invokes kobject_add and internally creates sysfs files > with the GFP_KERNEL flag set. Yep, that's a bug. > But since do_chunk_alloc execut

Re: [PATCH v2 3/5] btrfs: scrub: Don't append on-disk pages for raid56 scrub

On Fri, Mar 24, 2017 at 10:00:25AM +0800, Qu Wenruo wrote: > In the following situation, scrub will calculate wrong parity to > overwrite correct one: > > RAID5 full stripe: > > Before > | Dev 1 | Dev 2 | Dev 3 | > | Data stripe 1 | Data stripe 2 | Parity Stripe | > --

[PATCH v2] Btrfs: bring back repair during read

Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed and drop checks") made a cleanup around readpage_io_failed_hook, and it was supposed to keep the original sematics, but it also unexpectedly disabled repair during read for dup, raid1 and raid10. This fixes the problem by letti

[PATCH] Btrfs: fix wrong failed mirror_num of read-repair on raid56

In raid56 senario, after trying parity recovery, we didn't set mirror_num for btrfs_bio with failed mirror_num, hence end_bio_extent_readpage() will report a random mirror_num in dmesg log. Cc: David Sterba Signed-off-by: Liu Bo --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH] Btrfs: enable repair during read for raid56 profile

Now that scrub can fix data errors with the help of parity for raid56 profile, repair during read is able to as well. Although the mirror num in raid56 senario has different meanings, i.e. 0 or 1: read data directly > 1:do recover with parity, it could be fit into how we repair bad block durin

[PATCH] Btrfs: bring back repair during read

Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed and drop checks") made a cleanup around readpage_io_failed_hook, and it was supposed to keep the original sematics, but it also unexpectedly disabled repair during read for dup, raid1 and raid10. This fixes the problem by letti

Re: [PATCH] fix inconsistent device between /proc/pid/maps and stat

Hi, 2017-03-24 20:58 GMT+09:00 David Sterba : > On Tue, Mar 21, 2017 at 10:53:09AM +0900, Satoru Takeuchi wrote: >> There have been some discussions about inconsistent device between >> /proc/pid/maps and stat(2). >> >> http://thr3ads.net/btrfs-devel/2011/05/2346176-RFC-PATCH-0-2-btrfs-vfs-Return

[PATCH] btrfs-progs: fix btrfs send & receive with -e flag

The old check here tried to ensure that empty streams are not considered valid. The old check however, will always fail when only one run through the while(1) loop is needed and honor_end_cmd is set. So this: btrfs send /some/subvol | btrfs receive -e /some/ will consistently fail because -e caus

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/24/2017 05:32 AM, Goldwyn Rodrigues wrote: > > > On 03/16/2017 09:33 AM, Jens Axboe wrote: >> On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote: >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 0eeb99e..2e5cba2 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@

Re: [PATCH] fix inconsistent device between /proc/pid/maps and stat

2017-03-24 20:58 GMT+09:00 David Sterba : > On Tue, Mar 21, 2017 at 10:53:09AM +0900, Satoru Takeuchi wrote: >> There have been some discussions about inconsistent device between >> /proc/pid/maps and stat(2). >> >> http://thr3ads.net/btrfs-devel/2011/05/2346176-RFC-PATCH-0-2-btrfs-vfs-Return-same

Re: btrfs send non-root

On Sat, Mar 11, 2017 at 02:54:45PM +, Sam Bull wrote: > I'm getting an error when trying to send a subvolume. I only seem to be > able to do this as root. The subvolume was created by the user account, > and not root. Could anybody shed some light on why this is failing? Is > there a way to get

Re: [PATCH] fix inconsistent device between /proc/pid/maps and stat

On Tue, Mar 21, 2017 at 10:53:09AM +0900, Satoru Takeuchi wrote: > There have been some discussions about inconsistent device between > /proc/pid/maps and stat(2). > > http://thr3ads.net/btrfs-devel/2011/05/2346176-RFC-PATCH-0-2-btrfs-vfs-Return-same-device-in-stat-2-and-proc-pid-maps > https://w

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 09:33 AM, Jens Axboe wrote: > On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote: >> diff --git a/block/blk-core.c b/block/blk-core.c >> index 0eeb99e..2e5cba2 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -2014,7 +2019,7 @@ blk_qc_t generic_make_request(struct bio *

__link_block_group uses GFP_KERNEL

Hi guys, Looks like that current code does GFP_KERNEL allocation inside __link_block_group. the function invokes kobject_add and internally creates sysfs files with the GFP_KERNEL flag set. But since do_chunk_alloc executes insides the btrfs transaction it's not allowed to sleep. Thanks! -- To un