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@xxxxxxxxxxxx> Signed-off-by: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx> --- v2: Use bit AND instead of equal to check TREE_BLOCK bit. --- cmds-check.c | 4 ++++ 1 file changed, 4 insertions(+) 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); -- 2.6.2 -- This message has been scanned for viruses and dangerous content by Fujitsu, and is believed to be clean. -- 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
