| Message ID | 1448432346-2842-1-git-send-email-quwenruo@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Wed, Nov 25, 2015 at 02:19:06PM +0800, Qu Wenruo wrote: > In process_extent_item(), it gives 'metadata' initial value 0, but for > non-skinny-metadata case, metadata extent can't be judged just from key > type and it forgot that case. > > This causes a lot of false alert in non-skinny-metadata filesystem. > > Fix it by set correct metadata value before calling add_extent_rec(). > > Reported-by: Christoph Anton Mitterer <calestyo@scientia.net> > Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Patch replaced, thanks. The test image is pushed as well. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey. I can confirm that the new patch fixes the issue on both test filesystems. Thanks for working that out. I guess there's no longer a need to keep that old filesystems now?! Cheers, Chris. On Thu, 2015-11-26 at 15:27 +0100, David Sterba wrote: > On Wed, Nov 25, 2015 at 02:19:06PM +0800, Qu Wenruo wrote: > > In process_extent_item(), it gives 'metadata' initial value 0, but > > for > > non-skinny-metadata case, metadata extent can't be judged just from > > key > > type and it forgot that case. > > > > This causes a lot of false alert in non-skinny-metadata filesystem. > > > > Fix it by set correct metadata value before calling > > add_extent_rec(). > > > > Reported-by: Christoph Anton Mitterer <calestyo@scientia.net> > > Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> > > Patch replaced, thanks. The test image is pushed as well.
Christoph Anton Mitterer wrote on 2015/11/26 16:20 +0100: > Hey. > > I can confirm that the new patch fixes the issue on both test > filesystems. > > Thanks for working that out. I guess there's no longer a need to keep > that old filesystems now?! Of course no need to keep. But since there is no real error, feel free to keep using it or just re format it with skinny-metadata. Thanks, Qu > > Cheers, > Chris. > > On Thu, 2015-11-26 at 15:27 +0100, David Sterba wrote: >> On Wed, Nov 25, 2015 at 02:19:06PM +0800, Qu Wenruo wrote: >>> In process_extent_item(), it gives 'metadata' initial value 0, but >>> for >>> non-skinny-metadata case, metadata extent can't be judged just from >>> key >>> type and it forgot that case. >>> >>> This causes a lot of false alert in non-skinny-metadata filesystem. >>> >>> Fix it by set correct metadata value before calling >>> add_extent_rec(). >>> >>> Reported-by: Christoph Anton Mitterer <calestyo@scientia.net> >>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> >> >> Patch replaced, thanks. The test image is pushed as well. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2015-11-27 at 08:40 +0800, Qu Wenruo wrote: > But since there is no real error sure... > feel free to keep using it or just re > format it with skinny-metadata. That's just onging =) Thanks for all your efforts in that issue =) Chris.
diff --git a/cmds-check.c b/cmds-check.c index fd661d9..938b863 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -5134,6 +5134,10 @@ static int process_extent_item(struct btrfs_root *root, ei = btrfs_item_ptr(eb, slot, struct btrfs_extent_item); refs = btrfs_extent_refs(eb, ei); + if (btrfs_extent_flags(eb, ei) & BTRFS_EXTENT_FLAG_TREE_BLOCK) + metadata = 1; + else + metadata = 0; add_extent_rec(extent_cache, NULL, 0, key.objectid, num_bytes, refs, 0, 0, 0, metadata, 1, num_bytes);
In process_extent_item(), it gives 'metadata' initial value 0, but for non-skinny-metadata case, metadata extent can't be judged just from key type and it forgot that case. This causes a lot of false alert in non-skinny-metadata filesystem. Fix it by set correct metadata value before calling add_extent_rec(). Reported-by: Christoph Anton Mitterer <calestyo@scientia.net> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- v2: Use bit AND instead of equal to check TREE_BLOCK bit. --- cmds-check.c | 4 ++++ 1 file changed, 4 insertions(+)