Re: [PATCH RFC 5/6] fs: introduce a shutdown_bdev super block operation

[Christian Brauner <brauner@kernel.org>]

On Tue, Jun 24, 2025 at 06:36:01PM +0930, Qu Wenruo wrote:
> 
> 
> 在 2025/6/24 18:21, Christian Brauner 写道:
> > On Tue, Jun 24, 2025 at 06:57:08AM +0930, Qu Wenruo wrote:
> > > 
> > > 
> > > 在 2025/6/23 23:27, Christoph Hellwig 写道:
> > > > On Mon, Jun 23, 2025 at 12:56:28PM +0200, Christian Brauner wrote:
> > > > >           void (*shutdown)(struct super_block *sb);
> > > > > +       void (*drop_bdev)(struct super_block *sb, struct block_device *bdev /* , unsigned int flags/reason maybe too ? */);
> > > > >    };
> > > > > 
> > > > > You might want to drop a block device independent of whether the device
> > > > > was somehow lost. So I find that a bit more flexible.
> > > > 
> > > > Drop is weird word for what is happening here, and if it wasn't for the
> > > > context in this thread I'd expect it to be about refcounting in Linux.
> > > > 
> > > > When the VFS/libfs does an upcall into the file system to notify it
> > > > that a device is gone that's pretty much a device loss.  I'm not married
> > > > to the exact name, but drop seems like a pretty bad choice.
> > > 
> > > What about a more common used term, mark_dead()?
> > > 
> > > It's already used in blk_holder_ops, and I'd say it's more straighforward to
> > > me, compared to shutdown()/goingdown().
> > 
> > But it's not about the superblock going down necessarily. It's about the
> > device going away for whatever reason:
> > 
> > void (*yank_bdev)(struct super_block *sb, struct block_device *bdev /* , unsigned int flags/reason maybe too ? */);
> > void (*pull_bdev)(struct super_block *sb, struct block_device *bdev /* , unsigned int flags/reason maybe too ? */);
> > void (*unplug_bdev)(struct super_block *sb, struct block_device *bdev /* , unsigned int flags/reason maybe too ? */);
> > void (*remove_bdev)(struct super_block *sb, struct block_device *bdev /* , unsigned int flags/reason maybe too ? */);
> 
> All sound good to me, although the last one sounds better.
> 
> > 
> > On a single device superblock unplugging that device would obviously
> > cause an actual shutdown. On multi-device superblocks it doesn't always.
> > 
> > (That brings me to another thought. Is there a use-case for knowing in
> > advance whether removing a device would shut down the superblock?
> 
> Maybe another interface like can_remove_bdev()?
> 
> It's not hard for btrfs to provide it, we already have a check function
> btrfs_check_rw_degradable() to do that.
> 
> Although I'd say, that will be something way down the road.

Yes, for sure. I think long-term we should hoist at least the bare
infrastructure for multi-device filesystem management into the VFS.
Or we should at least explore whether that's feasible and if it's
overall advantageous to maintenance and standardization. We've already
done a bit of that and imho it's now a lot easier to reason about the
basics already.

> 
> We even don't have a proper way to let end user configure the device loss
> behavior.
> E.g. some end users may prefer a full shutdown to be extra cautious, other
> than continue degraded.

Right.