| Message ID | cover.1697945679.git.wqu@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs-progs: follow-ups for issue #622 | expand |
On Sun, Oct 22, 2023 at 02:10:06PM +1030, Qu Wenruo wrote: > Issue #622 is a very interesting bug report, that ntfs2btrfs has a fixed > bug that it can generate out-of-order inline backref items. > > This leads to kernel transaction abort, but btrfs-check failed to detect > it at all. > > Although the fix for btrfs-progs is already merged in the latest v6.5.3 > release, we still lacks the following thing: > > - Better dump-tree support to show the weird inline backref order > This is very weird, as we have the inline type in ascending order, > but for the sequence number (hash for EXTENT_DATA_REF, offset for all > other types) it is descending inside the same type. > > That's why the following output of one data extent item looks > out-of-order: > > item 0 key (13631488 EXTENT_ITEM 4096) itemoff 16143 itemsize 140 > refs 4 gen 7 flags DATA > extent data backref root FS_TREE objectid 258 offset 0 count 1 > extent data backref root FS_TREE objectid 257 offset 0 count 1 > extent data backref root FS_TREE objectid 260 offset 0 count 1 > extent data backref root FS_TREE objectid 259 offset 0 count 1 > > - Lowmem mode support to detect the error > > - Test case to make sure we can detect the error > > This series would address all the three points above. > > Qu Wenruo (3): > btrfs-progs: dump-tree: output the sequence number for inline > references > btrfs-progs: check/lowmem: verify the sequence of inline backref items > btrfs-progs: fsck-tests: add test image of out-of-order inline backref > items Thanks, added to misc-next. We can add ntfs2btrfs conversion tests to btrfs-progs, either with the external utility or on-demand build from git.
With the image file prefix fixed.
You can add
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Issue #622 is a very interesting bug report, that ntfs2btrfs has a fixed bug that it can generate out-of-order inline backref items. This leads to kernel transaction abort, but btrfs-check failed to detect it at all. Although the fix for btrfs-progs is already merged in the latest v6.5.3 release, we still lacks the following thing: - Better dump-tree support to show the weird inline backref order This is very weird, as we have the inline type in ascending order, but for the sequence number (hash for EXTENT_DATA_REF, offset for all other types) it is descending inside the same type. That's why the following output of one data extent item looks out-of-order: item 0 key (13631488 EXTENT_ITEM 4096) itemoff 16143 itemsize 140 refs 4 gen 7 flags DATA extent data backref root FS_TREE objectid 258 offset 0 count 1 extent data backref root FS_TREE objectid 257 offset 0 count 1 extent data backref root FS_TREE objectid 260 offset 0 count 1 extent data backref root FS_TREE objectid 259 offset 0 count 1 - Lowmem mode support to detect the error - Test case to make sure we can detect the error This series would address all the three points above. Qu Wenruo (3): btrfs-progs: dump-tree: output the sequence number for inline references btrfs-progs: check/lowmem: verify the sequence of inline backref items btrfs-progs: fsck-tests: add test image of out-of-order inline backref items check/mode-lowmem.c | 31 ++++++++++++++++++ check/mode-lowmem.h | 1 + kernel-shared/print-tree.c | 31 +++++++++++------- .../btrfs_image.xz | Bin 0 -> 2264 bytes .../061-out-of-order-inline-backref/test.sh | 19 +++++++++++ 5 files changed, 70 insertions(+), 12 deletions(-) create mode 100644 tests/fsck-tests/061-out-of-order-inline-backref/btrfs_image.xz create mode 100755 tests/fsck-tests/061-out-of-order-inline-backref/test.sh -- 2.42.0