mbox series

[0/2] btrfs: tree-checker: Add checks to detect missing INODE_ITEM

Message ID 20190826074039.28517-1-wqu@suse.com (mailing list archive)
Headers show
Series btrfs: tree-checker: Add checks to detect missing INODE_ITEM | expand

Message

Qu Wenruo Aug. 26, 2019, 7:40 a.m. UTC
For the following items, key->objectid is inode number:
- DIR_ITEM
- DIR_INDEX
- XATTR_ITEM
- EXTENT_DATA
- INODE_REF

So in btrfs btree, such items must have its previous item shares the
same objectid, e.g.:
 (257 INODE_ITEM 0)
 (257 DIR_INDEX xxx)
 (257 DIR_ITEM xxx)
 (258 INODE_ITEM 0)
 (258 INODE_REF 0)
 (258 XATTR_ITEM 0)
 (258 EXTENT_DATA 0)

But if we have the following sequence, then there is definitely
something wrong, normally some INODE_ITEM is missing, like:
 (257 INODE_ITEM 0)
 (257 DIR_INDEX xxx)
 (257 DIR_ITEM xxx)
 (258 XATTR_ITEM 0)  <<< objecitd suddenly changed to 258
 (258 EXTENT_DATA 0)

So just by checking the previous key for above inode based key types, we
can detect missing inode item.

In this patchset, we will enhance existing check_dir_item() and
check_extent_data_item() to detect missing INODE_ITEM first, then add
INODE_REF checker.

So now we can cover the INODE_ITEM missing case in tree-checker without
much cost, but achieve the check which is normally done by btrfs-check.
(I'm already a little concerned about the fact that kernel tree-checker
is getting stronger and stronger while btrfs-progs can't fix all
problems)

Of course, there is still a limitation that the first key of a leaf
can't be verified, but we have already cover all the rest keys, which is
way better than "good enough"(TM).

Qu Wenruo (2):
  btrfs: tree-checker: Try to detect missing INODE_ITEM
  btrfs: tree-checker: Add check for INODE_REF

 fs/btrfs/tree-checker.c | 78 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 76 insertions(+), 2 deletions(-)