On Mon, Jul 07, 2025 at 05:45:32PM -0700, Darrick J. Wong wrote: > On second thought -- it's weird that you'd flush the filesystem and > shrink the inode/dentry caches in a "your device went away" handler. > Fancy filesystems like bcachefs and btrfs would likely just shift IO to > a different bdev, right? And there's no good reason to run shrinkers on > either of those fses, right?
No nmeed for fancy file systems, this is weird no matter what. But it is what Linux has done for 30+ years, so I kept it when refactoring this code to sit in a callback. > > 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. > > I think dchinner makes a good point that if your filesystem can do > something clever on device removal, it should provide its own block > device holder ops instead of using fs_holder_ops. I don't understand > why you need a "generic" solution for btrfs when it's not going to do > what the others do anyway. Why? You're most likely to get the locking wrong, and so on. What might make sense is to move the sync_filesystem, shrink_dcache_sb and evict_inodes into the method. That way file systems where we > As an aside: > 'twould be nice if we could lift the *FS_IOC_SHUTDOWN dispatch out of > everyone's ioctl functions into the VFS, and then move the "I am dead" > state into super_block so that you could actually shut down any > filesystem, not just the seven that currently implement it. Sure. Someone just needs to do the work.. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
