On Tue, Jun 24, 2025 at 10:51:51AM +0200, Christian Brauner wrote: > > 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 ? */); Out of these remove_bdev is the most sane. > (That brings me to another thought. Is there a use-case for knowing in > advance whether removing a device would shut down the superblock? > Because then the ability to probe whether a device can be safely > removed or an option to only remove the device if it can be removed > without killing the superblock would be a natural extension.) I don't think there is a use for it at this (holder_ops) level. If the device driver notifies about a device going to away we're already committed. It makes some sense at the file system administration level, but you want to tie that much deepter into the file system, i.e. you'd actually usually want to migrate all data off the device first.
