All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>,
	<linux-btrfs@vger.kernel.org>, <kernel-team@fb.com>,
	<mfasheh@suse.de>
Subject: Re: [PATCH] Btrfs: keep dropped roots in cache until transaciton commit
Date: Fri, 11 Sep 2015 11:44:08 -0400	[thread overview]
Message-ID: <55F2F6C8.60307@fb.com> (raw)
In-Reply-To: <55F22D8D.6090406@cn.fujitsu.com>

On 09/10/2015 09:25 PM, Qu Wenruo wrote:
>
>
> Josef Bacik wrote on 2015/09/10 16:27 -0400:
>> When dropping a snapshot we need to account for the qgroup changes.
>> If we drop
>> the snapshot in all one go then the backref code will fail to find
>> blocks from
>> the snapshot we dropped since it won't be able to find the root in the
>> fs root
>> cache.  This can lead to us failing to find refs from other roots that
>> pointed
>> at blocks in the now deleted root.  To handle this we need to not
>> remove the fs
>> roots from the cache until after we process the qgroup operations.  Do
>> this by
>> adding dropped roots to a list on the transaction, and letting the
>> transaction
>> remove the roots at the same time it drops the commit roots.  This
>> will keep all
>> of the backref searching code in sync properly, and fixes a problem
>> Mark was
>> seeing with snapshot delete and qgroups.  Thanks,Btrfs: keep dropped
>> roots in
>> cache until transaciton commit
>>
>> When dropping a snapshot we need to account for the qgroup changes.
>> If we drop
>> the snapshot in all one go then the backref code will fail to find
>> blocks from
>> the snapshot we dropped since it won't be able to find the root in the
>> fs root
>> cache.  This can lead to us failing to find refs from other roots that
>> pointed
>> at blocks in the now deleted root.  To handle this we need to not
>> remove the fs
>> roots from the cache until after we process the qgroup operations.  Do
>> this by
>> adding dropped roots to a list on the transaction, and letting the
>> transaction
>> remove the roots at the same time it drops the commit roots.  This
>> will keep all
>> of the backref searching code in sync properly, and fixes a problem
>> Mark was
>> seeing with snapshot delete and qgroups.  Thanks,
>
> Mark will definitely be happy with this patch, as quite a good basis for
> snapshot deletion.
>
> BTW, the commit message seems to be repeating itself.
>

Argh I usually notice when that happens, there's some weird vim key 
combo that I accidently hit pretty regularly that duplicates everything 
I just typed.  Thanks,

Josef


      reply	other threads:[~2015-09-11 15:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 20:27 [PATCH] Btrfs: keep dropped roots in cache until transaciton commit Josef Bacik
2015-09-11  1:25 ` Qu Wenruo
2015-09-11 20:43   ` Mark Fasheh
2015-09-11  1:25 ` Qu Wenruo
2015-09-11 15:44   ` Josef Bacik [this message]

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=55F2F6C8.60307@fb.com \
    --to=jbacik@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mfasheh@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.