On Tue, Apr 05, 2016 at 03:16:54PM -0700, Mark Fasheh wrote: > On Tue, Apr 05, 2016 at 09:27:01AM +0800, Qu Wenruo wrote: > > Mark Fasheh wrote on 2016/04/04 16:06 -0700: > > >Hi, > > > > > >Making a snapshot gets us the wrong qgroup numbers. This is very easy to > > >reproduce. From a fresh btrfs filesystem, simply enable qgroups and create > > >a > > >snapshot. In this example we have mounted a newly created fresh filesystem > > >and mounted it at /btrfs: > > > > > ># btrfs quota enable /btrfs > > ># btrfs sub sna /btrfs/ /btrfs/snap1 > > ># btrfs qg show /btrfs > > > > > >qgroupid rfer excl > > >-------- ---- ---- > > >0/5 32.00KiB 32.00KiB > > >0/257 16.00KiB 16.00KiB > > > > > > > Also reproduced it. > > > > My first idea is, old snapshot qgroup hack is involved. > > > > Unlike btrfs_inc/dec_extent_ref(), snapshotting just use a dirty > > hack to handle it: > > Copy rfer from source subvolume, and directly set excl to nodesize. > > > > If such work is before adding snapshot inode into src subvolume, it > > may be the reason causing the bug. > > Ok, thanks very much for looking into this Qu. > > > > >In the example above, the default subvolume (0/5) should read 16KiB > > >referenced and 16KiB exclusive. > > > > > >A rescan fixes things, so we know the rescan process is doing the math > > >right: > > > > > ># btrfs quota rescan /btrfs > > ># btrfs qgroup show /btrfs > > >qgroupid rfer excl > > >-------- ---- ---- > > >0/5 16.00KiB 16.00KiB > > >0/257 16.00KiB 16.00KiB > > > > > > > So the base of qgroup code is not affected, or we may need another > > painful rework. > > Yeah as far as I can tell the core algorithm is fine. We're just running the > extents incorrectly somehow.
Btw, I should add - my biggest fear was an algorithm change which would have made older versions of btrfsck incompatible. It seems though we can still use it for checking qgroups. --Mark -- Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html