[PATCH v2 2/2] fstests: btrfs: Introduce stress test for deadlock between snapshot delete and other read-write operations

Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting time out of commit trans") could cause ABBA deadlock between backref lookup with write lock hold (subvolume deletion) and other read/write operations. It's going to be fixed by "btrfs: qgroup: Don't trigger backref walk at del

Re: [PATCH v2] btrfs: add kernel scrub log messages

On 01/03/2019 04:17 PM, Anand Jain wrote: scrub kernel messages helps debug and audit, add them to the log. Signed-off-by: Anand Jain Ping. Thanks. --- v1->v2: fix btrfs_info, using string directly. Add spacing. fs/btrfs/scrub.c | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [PATCH v2 0/5] Fix incorrectly created uuid tree

On Thu, Jan 03, 2019 at 03:32:16PM +0800, Qu Wenruo wrote: > This patchset can be fetched from github: > https://github.com/adam900710/btrfs-progs/tree/uuid_tree_support > Which is based on v4.19.1 tag. > > Qu Wenruo (5): > btrfs-progs: Export btrfs_create_tree() and move it to disk-io.c > btr

Re: Balance of Raid1 pool, does not balance properly.

for the future you can create a little cron script to avoid this issue. the data distribution should then be more regular, even if you delete or overwrite a lot. deppend on your workload use the right : # cron.daily / cron.weekly btrfs balance start -musage=0 -dusage=0 # releases empty blocks for

Re: Balance of Raid1 pool, does not balance properly.

Thanks for the answer. I had already tried " btrfs balance start -musage=75 -dusage=75 /mnt It only reallocated 3 blocks. But after I had moved some data, I ran it with 90, and it realocated a lot more. I have a new balance running, and this time it seems to be doing its job. At least data i

[PATCH v1] Btrfs: Switch to use new generic UUID API

There are new types and helpers that are supposed to be used in new code. As a preparation to get rid of legacy types and API functions do the conversion here. Signed-off-by: Andy Shevchenko --- - not tested on actual FS fs/btrfs/disk-io.c | 6 +++--- fs/btrfs/ioctl.c | 12 ++

Re: [PATCH v2] btrfs: raid56: data corruption on a device removal

On 07/01/2019 16:34, David Sterba wrote: > On Mon, Jan 07, 2019 at 12:03:43PM +0100, Johannes Thumshirn wrote: + /* + * Since the failed bio can return partial data, bi_sector might be + * incremented by that value. We need to revert it back to the + * state before the bio wa

Re: [For 5.0-rc PATCH] btrfs: Use real device structure to verify dev extent

On Tue, Jan 08, 2019 at 02:08:18PM +0800, Qu Wenruo wrote: > [BUG] > Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel > message: > > BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len > 8388608 is beyond device boundary 0 > BTRFS error (device dm-6)

Re: Nasty corruption on large array, ideas welcome

On Tue, Jan 8, 2019 at 10:05 PM Qu Wenruo wrote: > > > > On 2019/1/9 上午3:33, Thiago Ramon wrote: > > I have a pretty complicated setup here, so first a general description: > > 8 HDs: 4x5TB, 2x4TB, 2x8TB > > > > Each disk is a LVM PV containing a BCACHE backing device, which then > > contains the

Re: [PATCH 2/2] fstests: btrfs: Introduce stress test for deadlock between snapshot delete and other read-write operations

On 2019/1/10 下午9:53, Filipe Manana wrote: [snip] +# Workaround to handle killed workload with unreturned syscall +sync >>> >>> I can't understand that comment, nor why the call to sync (probably >>> most readers won't either). >>> What do you mean by "unreturned syscall"? It hangs, bloc

Re: [PATCH 2/2] fstests: btrfs: Introduce stress test for deadlock between snapshot delete and other read-write operations

On Thu, Jan 10, 2019 at 1:49 PM Qu Wenruo wrote: > > > > On 2019/1/10 下午8:08, Filipe Manana wrote: > > On Thu, Jan 10, 2019 at 6:15 AM Qu Wenruo wrote: > >> > >> Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting > >> time out of commit trans") could cause ABBA deadlock betwe

Re: [PATCH 2/2] fstests: btrfs: Introduce stress test for deadlock between snapshot delete and other read-write operations

On 2019/1/10 下午8:08, Filipe Manana wrote: > On Thu, Jan 10, 2019 at 6:15 AM Qu Wenruo wrote: >> >> Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting >> time out of commit trans") could cause ABBA deadlock between backref >> lookup with write lock hold (subvolume deletion) a

Re: [PATCH 2/2] fstests: btrfs: Introduce stress test for deadlock between snapshot delete and other read-write operations

On Thu, Jan 10, 2019 at 6:15 AM Qu Wenruo wrote: > > Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting > time out of commit trans") could cause ABBA deadlock between backref > lookup with write lock hold (subvolume deletion) and other read/write > operations. > > It's going t

Re: btrfs hang on nfs?

Nikolay Borisov writes: > > > > Unfortunately the cfq scheduler did not help. The system wedged. > > > > I did notice this for the first time... > > > > [Wed Jan 9 06:03:41 2019] BTRFS info (device sda1): the free space > > cache file (83320273633280) is invalid, skip it > > W

Re: btrfs hang on nfs?

On 10.01.19 г. 13:46 ч., Scott E. Blomquist wrote: > > Scott E. Blomquist writes: > > > > Thank you so much, I would have never guessed that. > > > > In my case the scheduler was set to deadline > > > > cat /sys/block/sd[a-c]/queue/scheduler > > noop [deadline] cfq > > no

Re: btrfs hang on nfs?

Scott E. Blomquist writes: > > Thank you so much, I would have never guessed that. > > In my case the scheduler was set to deadline > > cat /sys/block/sd[a-c]/queue/scheduler > noop [deadline] cfq > noop [deadline] cfq > noop [deadline] cfq > > I have set it to cfq,