From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs: allow more fine control to rescue=usebackuproot
Date: Sun, 6 Sep 2026 16:33:36 +0930 [thread overview]
Message-ID: <cover.1788678078.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Fix a missing use_backup_slot update for rescue=all mount option
Which can trigger the ASSERT() on use_backup_slot.
- Add proper output for btrfs_show_options()
- Slightly update the commit message of the 2nd patch
To address a false alert from Sashiko, where it thinks it's a bug not
to load any backup root for the newest slot.
For the newest slot, it matches the current generation in the super
block, thus every root should be the same as the super block, and no
need to load the bytenr from backup.
There is a bug report that for a specific corrupted btrfs, the
"rescue=usebackuproot" still chose the newest slot (aka, the same tree
root as the one in the super block) to mount the fs, and resulted
transid mismatch.
Meanwhile the reporter used btrfs-mod-sb to modify the fs to use a
specific backup slot, then the fs can pass btrfs-check.
This shows the limit of the current automatic backup root detection,
that as long as all tree root nodes can be loaded, btrfs will consider
it as a valid backup slot, without trying any other slot.
And end user has no way to tell btrfs to use a specific slot.
This patchest address the problem by:
- Make "rescue=usebackuproot" to always use the second newest slot
Which has the highest chance to still get every tree block right
without transid error.
- Introduce new "rescue=usebackuproot_*" mount option
Where "*" can be 0/1/2/3.
0 means the newest slot (aka, the one matching the super block
generation), 1/2/3 means the second/third/fourth(oldest) newest slot.
Now "rescue=usebackuproot" is just the same as
"rescue=usebackuproot_1".
Although those "rescue=usebackuproot*" mount options still requires full
RO.
For proper recovery, we still need to use "btrfs check", and a new
option for btrfs-check will be introduced soon to make the backuproot
usage simpler for progs.
Qu Wenruo (2):
btrfs: always use the second newest slot for rescue=usebackuproot
btrfs: introduce more accurate usebackuproot options
fs/btrfs/disk-io.c | 106 ++++++++++++++++++++-------------------------
fs/btrfs/fs.h | 1 +
fs/btrfs/super.c | 28 +++++++++++-
3 files changed, 74 insertions(+), 61 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-06 7:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 7:03 Qu Wenruo [this message]
2026-09-06 7:03 ` [PATCH v2 1/2] btrfs: always use the second newest slot for rescue=usebackuproot Qu Wenruo
2026-09-06 7:03 ` [PATCH v2 2/2] btrfs: introduce more accurate usebackuproot options Qu Wenruo
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.1788678078.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.