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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
