From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: bo.li.liu@oracle.com
Cc: chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: separate sequence numbers for delayed ref tracking and tree mod log
Date: Wed, 24 Apr 2013 10:26:20 +0200 [thread overview]
Message-ID: <5177972C.8040009@jan-o-sch.net> (raw)
In-Reply-To: <20130424081236.GE19283@liubo.jp.oracle.com>
On Wed, April 24, 2013 at 10:12 (+0200), Liu Bo wrote:
> On Tue, Apr 23, 2013 at 08:00:27PM +0200, Jan Schmidt wrote:
>> Sequence numbers for delayed refs have been introduced in the first version
>> of the qgroup patch set. To solve the problem of find_all_roots on a busy
>> file system, the tree mod log was introduced. The sequence numbers for that
>> were simply shared between those two users.
>
> Can't we just separate them with two vars?
My reasoning comes a few lines below ...
> thanks,
> liubo
>
>>
>> However, at one point in qgroup's quota accounting, there's a statement
>> accessing the previous sequence number, that's still just doing (seq - 1)
>> just as it had to in the very first version.
>>
>> To satisfy that requirement, this patch makes the sequence number counter 64
>> bit and splits it into a major part (used for qgroup sequence number
>> counting) and a minor part (incremented for each tree modification in the
>> log). This enables us to go exactly one major step backwards, as required
>> for qgroups, while still incrementing the sequence counter for tree mod log
>> insertions to keep track of their order. Keeping them in a single variable
>> means there's no need to change all the code dealing with comparisons of two
>> sequence numbers.
See the previous sentence :-)
And, it doesn't add too much complexity, setting and incrementing remains in
fact quite easy, even though we use the upper 32 bit and the lower 32 bit of
that integer independently.
Thanks,
-Jan
>>
>> The sequence number is reset to 0 on commit (not new in this patch), which
>> ensures we won't overflow the two 32 bit counters.
>>
>> Without this fix, the qgroup tracking can occasionally go wrong and WARN_ONs
>> from the tree mod log code may happen.
>>
>> Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
>> ---
>> [snip]
next prev parent reply other threads:[~2013-04-24 8:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 18:00 [PATCH] Btrfs: separate sequence numbers for delayed ref tracking and tree mod log Jan Schmidt
2013-04-24 8:12 ` Liu Bo
2013-04-24 8:26 ` Jan Schmidt [this message]
2013-04-24 13:04 ` Josef Bacik
2013-04-24 13:25 ` Jan Schmidt
2013-04-24 13:40 ` Josef Bacik
2013-04-24 13:59 ` Jan Schmidt
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=5177972C.8040009@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=bo.li.liu@oracle.com \
--cc=chris.mason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
/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