From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Dave Chinner <david@fromorbit.com>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, ntfs3@lists.linux.dev,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 1/6] fs: enhance and rename shutdown() callback to remove_bdev()
Date: Tue, 8 Jul 2025 08:52:47 +0930 [thread overview]
Message-ID: <dbd955f7-b9b4-402f-97bf-6b38f0c3237e@gmx.com> (raw)
In-Reply-To: <aGxSHKeyldrR1Q0T@dread.disaster.area>
在 2025/7/8 08:32, Dave Chinner 写道:
> On Fri, Jul 04, 2025 at 10:12:29AM +0930, Qu Wenruo wrote:
>> Currently all the filesystems implementing the
>> super_opearations::shutdown() callback 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, with multi-device filesystems like
>> btrfs and bcachefs the filesystem can handle certain device loss without
>> shutting down the whole filesystem.
>>
>> To allow those multi-device filesystems to be integrated to use
>> fs_holder_ops:
>>
>> - Replace super_opearation::shutdown() with
>> super_opearations::remove_bdev()
>> To better describe when the callback is called.
>
> This conflates cause with action.
>
> The shutdown callout is an action that the filesystem must execute,
> whilst "remove bdev" is a cause notification that might require an
> action to be take.
>
> Yes, the cause could be someone doing hot-unplug of the block
> device, but it could also be something going wrong in software
> layers below the filesystem. e.g. dm-thinp having an unrecoverable
> corruption or ENOSPC errors.
>
> We already have a "cause" notification: blk_holder_ops->mark_dead().
>
> The generic fs action that is taken by this notification is
> fs_bdev_mark_dead(). That action is to invalidate caches and shut
> down the filesystem.
>
> btrfs needs to do something different to a blk_holder_ops->mark_dead
> notification. i.e. it needs an action that is different to
> fs_bdev_mark_dead().
>
> Indeed, this is how bcachefs already handles "single device
> died" events for multi-device filesystems - see
> bch2_fs_bdev_mark_dead().
I do not think it's the correct way to go, especially when there is
already fs_holder_ops.
We're always going towards a more generic solution, other than letting
the individual fs to do the same thing slightly differently.
Yes, the naming is not perfect and mixing cause and action, but the end
result is still a more generic and less duplicated code base.
>
> Hence Btrfs should be doing the same thing as bcachefs. The
> bdev_handle_ops structure exists precisly because it allows the
> filesystem to handle block device events in the exact manner they
> require....
>
>> - Add a new @bdev parameter to remove_bdev() callback
>> To allow the fs to determine which device is missing, and do the
>> proper handling when needed.
>>
>> For the existing shutdown callback users, the change is minimal.
>
> Except for the change in API semantics. ->shutdown is an external
> shutdown trigger for the filesystem, not a generic "block device
> removed" notification.
The problem is, there is no one utilizing ->shutdown() out of
fs_bdev_mark_dead().
If shutdown ioctl is handled through super_operations::shutdown, it will
be more meaningful to split shutdown and dev removal.
But that's not the case, and different fses even have slightly different
handling for the shutdown flags (not all fses even utilize journal to
protect their metadata).
Thanks,
Qu
>
> Hooking blk_holder_ops->mark_dead means that btrfs can also provide
> a ->shutdown implementation for when something external other than a
> block device removal needs to shut down the filesystem....
>
> -Dave.
next prev parent reply other threads:[~2025-07-07 23:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1751589725.git.wqu@suse.com>
2025-07-04 0:42 ` [PATCH v4 1/6] fs: enhance and rename shutdown() callback to remove_bdev() Qu Wenruo
2025-07-04 9:00 ` (subset) " Christian Brauner
2025-07-04 9:05 ` Jan Kara
2025-07-07 23:02 ` Dave Chinner
2025-07-07 23:22 ` Qu Wenruo [this message]
2025-07-08 0:45 ` Darrick J. Wong
2025-07-08 2:09 ` Qu Wenruo
2025-07-08 3:06 ` Qu Wenruo
2025-07-08 5:05 ` Dave Chinner
2025-07-08 5:41 ` Qu Wenruo
2025-07-08 7:55 ` Christian Brauner
2025-07-08 22:59 ` Dave Chinner
2025-07-08 23:07 ` Qu Wenruo
2025-07-09 0:35 ` Kent Overstreet
2025-07-09 0:55 ` Qu Wenruo
2025-07-09 1:13 ` Kent Overstreet
2025-07-10 8:33 ` Christian Brauner
2025-07-10 10:54 ` Christoph Hellwig
2025-07-08 10:20 ` Jan Kara
2025-07-08 20:20 ` Darrick J. Wong
2025-07-08 22:12 ` Qu Wenruo
2025-07-10 8:40 ` Christian Brauner
2025-07-10 9:54 ` Qu Wenruo
2025-07-11 9:34 ` Christian Brauner
2025-07-10 10:52 ` Christoph Hellwig
2025-07-09 17:23 Jan Kara
2025-07-09 17:49 ` Kent Overstreet
2025-07-10 13:10 ` Jan Kara
2025-07-10 18:41 ` Kent Overstreet
2025-07-11 14:20 ` Jan Kara
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=dbd955f7-b9b4-402f-97bf-6b38f0c3237e@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=wqu@suse.com \
/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).