From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz
Subject: [PATCH v5 1/6] fs: add a new remove_bdev() callback
Date: Mon, 14 Jul 2025 14:55:57 +0930 [thread overview]
Message-ID: <09909fcff7f2763cc037fec97ac2482bdc0a12cb.1752470276.git.wqu@suse.com> (raw)
In-Reply-To: <cover.1752470276.git.wqu@suse.com>
Currently all filesystems which implement super_operations::shutdown()
can not afford losing a device.
Thus fs_bdev_mark_dead() will just call the ->shutdown() callback for the
involved filesystem.
But it will no longer be the case, as multi-device filesystems like
btrfs and bcachefs can handle certain device loss without the need to
shutdown the whole filesystem.
To allow those multi-device filesystems to be integrated to use
fs_holder_ops:
- Add a new super_operations::remove_bdev() callback
- Try ->remove_bdev() callback first inside fs_bdev_mark_dead()
If the callback returned 0, meaning the fs can handling the device
loss, then exit without doing anything else.
If there is no such callback or the callback returned non-zero value,
continue to shutdown the filesystem as usual.
This means the new remove_bdev() should only do the check on whether the
operation can continue, and if so do the fs specific handlings.
The shutdown handling should still be handled by the existing
->shutdown() callback.
For all existing filesystems with shutdown callback, there is no change
to the code nor behavior.
Btrfs is going to implement both the ->remove_bdev() and ->shutdown()
callbacks soon.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/super.c | 11 +++++++++++
include/linux/fs.h | 9 +++++++++
2 files changed, 20 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index 80418ca8e215..7f876f32343a 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1459,6 +1459,17 @@ static void fs_bdev_mark_dead(struct block_device *bdev, bool surprise)
if (!sb)
return;
+ if (sb->s_op->remove_bdev) {
+ int ret;
+
+ ret = sb->s_op->remove_bdev(sb, bdev);
+ if (!ret) {
+ super_unlock_shared(sb);
+ return;
+ }
+ /* Fallback to shutdown. */
+ }
+
if (!surprise)
sync_filesystem(sb);
shrink_dcache_sb(sb);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b085f161ed22..6a8a5e63a5d4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2367,6 +2367,15 @@ struct super_operations {
struct shrink_control *);
long (*free_cached_objects)(struct super_block *,
struct shrink_control *);
+ /*
+ * If a filesystem can support graceful removal of a device and
+ * continue read-write operations, implement this callback.
+ *
+ * Return 0 if the filesystem can continue read-write.
+ * Non-zero return value or no such callback means the fs will be shutdown
+ * as usual.
+ */
+ int (*remove_bdev)(struct super_block *sb, struct block_device *bdev);
void (*shutdown)(struct super_block *sb);
};
--
2.50.0
next prev parent reply other threads:[~2025-07-14 5:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 5:25 [PATCH v5 0/6] btrfs: add remove_bdev() callback Qu Wenruo
2025-07-14 5:25 ` Qu Wenruo [this message]
2025-07-14 10:14 ` [PATCH v5 1/6] fs: add a new " Jan Kara
2025-07-15 11:40 ` (subset) " Christian Brauner
2025-07-14 5:25 ` [PATCH v5 2/6] btrfs: introduce a new fs state, EMERGENCY_SHUTDOWN Qu Wenruo
2025-07-14 5:25 ` [PATCH v5 3/6] btrfs: reject file operations if in shutdown state Qu Wenruo
2025-07-14 5:26 ` [PATCH v5 4/6] btrfs: reject delalloc ranges " Qu Wenruo
2025-07-14 5:26 ` [PATCH v5 5/6] btrfs: implement shutdown ioctl Qu Wenruo
2025-07-14 5:26 ` [PATCH v5 6/6] btrfs: implement remove_bdev and shutdown super operation callbacks Qu Wenruo
2025-07-15 11:36 ` Christian Brauner
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=09909fcff7f2763cc037fec97ac2482bdc0a12cb.1752470276.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).