From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/4] btrfs: introduce btrfs specific bdev holder ops and implement mark_dead() call back
Date: Mon, 9 Jun 2025 14:49:46 +0930 [thread overview]
Message-ID: <cover.1749446257.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Extra patches to properly handle fs mounting/unmounting races
- Harden freeze/thaw races
As they can be called on a per-fs and per-bdev basis, can cause extra
races.
Btrfs doesn't implement any callbacks of blk_holder_ops, this means:
- No sync/freeze/thaw support for an opened btrfs device
Not sure if this is the root cause of btrfs + hiberantion data loss,
but it won't hurt if we have such support.
- No ability to detect dead device at runtime
Meaning we can have "living" dead device in btrfs, the worst case is
generic/730, that the single device of a btrfs is removed, and btrfs
just abort transaction when it fails to write the transaction.
This series improve the situation by:
- Use a per-fs holder for block device
This is a dependency to implement proper blk_holder_ops, as we need a
way to grab the fs_info from a block device.
- Use bdev_fput() for btrfs devices
This ensures the bdev holder reclaim will not be delayed, thus ensure
the fs_info's lifespan is always covering any opened block devices.
This is another dependency to implement blk_holder_ops, or we can grab
an fs_info which is already released.
- Implement per-bdev sync/freeze/thaw callbacks
This has a special requirement for freeze/thaw, as freeze/thaw can be
triggered from two different paths, by ioctl (aka, per-fs) and by
block device (aka, per-bdev).
This means for the worst case, per-fs and per-dev freezing/thawing can
race with each other, and this requires fs level serialization.
- Implement the mark_dead() call back
This will automatically mark the dead devices as missing, and degrade
the fs.
Furthermore, if the remaining devices can no longer maintain RW
operations, immediately mark the fs as error (thus also read-only) to
prevent further data loss.
Qu Wenruo (4):
btrfs: use fs_info as the block device holder
btrfs: replace fput() with bdev_fput() for block devices
btrfs: implement a basic per-block-device call backs
btrfs: add a simple dead device detection mechanism
fs/btrfs/dev-replace.c | 4 +-
fs/btrfs/disk-io.c | 11 +++
fs/btrfs/fs.h | 14 +++-
fs/btrfs/ioctl.c | 4 +-
fs/btrfs/super.c | 27 ++++++--
fs/btrfs/super.h | 2 +
fs/btrfs/volumes.c | 154 +++++++++++++++++++++++++++++++++++++----
fs/btrfs/volumes.h | 6 ++
8 files changed, 197 insertions(+), 25 deletions(-)
--
2.49.0
next reply other threads:[~2025-06-09 5:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 5:19 Qu Wenruo [this message]
2025-06-09 5:19 ` [PATCH v2 1/4] btrfs: use fs_info as the block device holder Qu Wenruo
2025-06-09 5:19 ` [PATCH v2 2/4] btrfs: replace fput() with bdev_fput() for block devices Qu Wenruo
2025-06-09 5:19 ` [PATCH v2 3/4] btrfs: implement a basic per-block-device call backs Qu Wenruo
2025-06-09 5:19 ` [PATCH v2 4/4] btrfs: add a simple dead device detection mechanism Qu Wenruo
2025-06-09 5:21 ` [PATCH v2 0/4] btrfs: introduce btrfs specific bdev holder ops and implement mark_dead() call back Christoph Hellwig
2025-06-09 5:31 ` Qu Wenruo
2025-06-09 5:38 ` Christoph Hellwig
2025-06-09 6:27 ` 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.1749446257.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox