btrfs-progs: enhance detection on unknown keys in subvolumes #1069
+25
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is a bug report that a bitflip corrupted one tree block, causing a corruption that can not be repaired by btrfs-check. The corruption looks like this: item 10 key (730455 INODE_ITEM 0) itemoff 15456 itemsize 160 generation 7280 transid 9794 size 13829 nbytes 16384 block group 0 mode 100600 links 1 uid 1000 gid 1000 rdev 0 sequence 11 flags 0x0(none) atime 1765397443.29231914 (2025-12-11 06:40:43) ctime 1764798591.882909548 (2025-12-04 08:19:51) mtime 1764798591.882909548 (2025-12-04 08:19:51) otime 1764712848.413821734 (2025-12-03 08:30:48) item 11 key (730455 UNKNOWN.8 1924) itemoff 15406 itemsize 50 Note item 11, it has a unknown key, but the itemsize indicates it's an INODE_REF with 40 name_len (which matches the DIR_ITEM). bin(BTRFS_INODE_REF_KEY) = 0b1100 bin(8) = 0b1000 So it's indeed a bitflip. At least we should report such unknown inode key types as errors. The lowmem mode is already doing such report, although not treating them as an error. The original mode just ignores them completely. So this patch enhance btrfs check to: - Report such unknown item and treat them as error for the original mode - Treat such unknown item as error for the lowmem mode Reported-by: mikkel+btrfs@mikkel.cc Link: https://lore.kernel.org/linux-btrfs/5d5e344e-96be-4436-9a58-d60ba14fdb4f@gmx.com/T/#me22cef92653e660e88a4c005b10f5201a8fd83ac Signed-off-by: Qu Wenruo <wqu@suse.com>
The image has the following corrupted key in fs tree: item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 9 size 0 nbytes 0 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 sequence 1 flags 0x0(none) item 5 key (257 UNKNOWN.8 256) itemoff 15879 itemsize 0 <<< item 6 key (257 INODE_REF 256) itemoff 15863 itemsize 16 index 2 namelen 6 name: foobar This is inspired by a real world memory bitflip, which lead to a bitflip from 12 to 8, causing the above unknown key type in a subvolume. Although we will need to properly enhance btrfs-check to handle such case better, let's start from detecting and report such unknown keys as an error. The image is created by inserting an empty item with above unknown key type. Signed-off-by: Qu Wenruo <wqu@suse.com>
adam900710
force-pushed
the
unknown_key_error
branch
from
1b9d624 to
4acdcb5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is inspired by a real world bitflip corruption, where an INODE_REF
is now 8 (an unknown key type), causing btrfs-check to freak out and the
existing INODE_REF/DIR_ITEM/DIR_INDEX repair is not cutting this
particular case for the original mode.
Lowmem mode is better, but for this particular image it's too large and
lowmem is too slow to be practical.
As the first step, detect and report such unknown keys in subvolume
trees as an error.
With a new test case for it.
In the long run we should allow btrfs-check --repair to delete such
unknown keys.