Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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]

  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