From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs-progs: follow-ups for issue #622
Date: Sun, 22 Oct 2023 14:10:06 +1030 [thread overview]
Message-ID: <cover.1697945679.git.wqu@suse.com> (raw)
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
next reply other threads:[~2023-10-22 3:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-22 3:40 Qu Wenruo [this message]
2023-10-22 3:40 ` [PATCH 1/3] btrfs-progs: dump-tree: output the sequence number for inline references Qu Wenruo
2023-10-22 3:40 ` [PATCH 2/3] btrfs-progs: check/lowmem: verify the sequence of inline backref items Qu Wenruo
2023-10-22 3:40 ` [PATCH 3/3] btrfs-progs: fsck-tests: add test image of out-of-order " Qu Wenruo
2023-10-24 5:28 ` Anand Jain
2023-10-24 5:47 ` Qu Wenruo
2023-10-24 11:15 ` David Sterba
2023-10-23 13:42 ` [PATCH 0/3] btrfs-progs: follow-ups for issue #622 David Sterba
2023-10-24 6:18 ` Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1697945679.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.