On 2019/4/3 下午10:21, David Sterba wrote:
> On Wed, Apr 03, 2019 at 07:59:19PM +0800, Qu Wenruo wrote:
>> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
>> zero item") introduced comprehensive root owner checker.
>
> That's 4.7, so we might want to do stable backport to 4.9+.It's just a performance optimization. I'm not sure if we should backport such things even if we can solve the conflicts. >> >> However it's pretty expensive tree search to locate the owner root, >> especially when it get reused by mandatory read and write time >> tree-checker. >> >> This patch will remove that check, and completely rely on owner based >> empty leaf check, which is much faster and still works fine for most >> case. >> >> And since we skip the old root owner check, now write time tree check >> can be merged with btrfs_check_leaf_full(). > > And for that reason the change should be minimal, this patch depends on > current development queue so it's not suitable for the backport. > > I'm thinking what to do here, I want to avoid patches that effectively > revert changes that are still in the development branch and haven't been > released. OK, I'll resend write time tree checker patchset. > > This means to rework "btrfs: Do mandatory tree block check before > submitting bio", though it's deep in the branch, the scope of changes is > only 2 files so this should not cause any conflicts. BTW, I'm a little interesting in the workflow on your side. In this case, what's the correct way to handle them? Just remove those two related patches from misc-next branch and re-apply the newer version? Or remove all those write time tree checker and later enhancement patches and reapply them all? Either way, I hope to experience the same workflow so I could reduce your workload. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
