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(-) -- 2.23.0
