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.
