From: Mark Fasheh <mfasheh@suse.de>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, jbacik@fb.com, clm@fb.com
Subject: Re: Qgroups wrong after snapshot create
Date: Tue, 5 Apr 2016 15:28:04 -0700 [thread overview]
Message-ID: <20160405222804.GC2187@wotan.suse.de> (raw)
In-Reply-To: <20160405221654.GB2187@wotan.suse.de>
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
next prev parent reply other threads:[~2016-04-05 22:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 23:06 Qgroups wrong after snapshot create Mark Fasheh
2016-04-05 1:27 ` Qu Wenruo
2016-04-05 22:16 ` Mark Fasheh
2016-04-05 22:28 ` Mark Fasheh [this message]
2016-04-05 13:27 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160405222804.GC2187@wotan.suse.de \
--to=mfasheh@suse.de \
--cc=clm@fb.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).