Re: [PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

2018-05-03 Thread Qu Wenruo
On 2018年05月04日 00:43, David Sterba wrote: > On Tue, Dec 19, 2017 at 03:44:54PM +0800, Qu Wenruo wrote: >> When multiple pending snapshots referring the same source subvolume are >> executed, enabled quota will cause root item corruption, where root >> items are using old bytenr (no backref in

Re: [PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

2018-05-03 Thread David Sterba
On Tue, Dec 19, 2017 at 03:44:54PM +0800, Qu Wenruo wrote: > When multiple pending snapshots referring the same source subvolume are > executed, enabled quota will cause root item corruption, where root > items are using old bytenr (no backref in extent tree). > > This can be triggered by fstests

Re: [PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

2018-03-07 Thread David Sterba
On Fri, Feb 02, 2018 at 11:45:46AM +, Filipe Manana wrote: > On Tue, Dec 19, 2017 at 7:44 AM, Qu Wenruo wrote: > > When multiple pending snapshots referring the same source subvolume are > > executed, enabled quota will cause root item corruption, where root > > items are using

Re: [PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

2018-02-02 Thread Filipe Manana
On Tue, Dec 19, 2017 at 7:44 AM, Qu Wenruo wrote: > When multiple pending snapshots referring the same source subvolume are > executed, enabled quota will cause root item corruption, where root > items are using old bytenr (no backref in extent tree). > > This can be triggered by

[PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

2017-12-18 Thread Qu Wenruo
When multiple pending snapshots referring the same source subvolume are executed, enabled quota will cause root item corruption, where root items are using old bytenr (no backref in extent tree). This can be triggered by fstests btrfs/152. The cause is when source subvolume is still dirty, extra