On Thu, Jul 10, 2025 at 03:10:04PM +0200, Jan Kara wrote: > On Wed 09-07-25 13:49:12, Kent Overstreet wrote: > > On Wed, Jul 09, 2025 at 07:23:07PM +0200, Jan Kara wrote: > > > > It also avoids the problem of ->mark_dead events being generated > > > > from a context that holds filesystem/vfs locks and then deadlocking > > > > waiting for those locks to be released. > > > > > > > > IOWs, a multi-device filesystem should really be implementing > > > > ->mark_dead itself, and should not be depending on being able to > > > > lock the superblock to take an active reference to it. > > > > > > > > It should be pretty clear that these are not issues that the generic > > > > filesystem ->mark_dead implementation should be trying to > > > > handle..... > > > > > > Well, IMO every fs implementation needs to do the bdev -> sb transition > > > and > > > make sb somehow stable. It may be that grabbing s_umount and active sb > > > reference is not what everybody wants but AFAIU btrfs as the second > > > multi-device filesystem would be fine with that and for bcachefs this > > > doesn't work only because they have special superblock instantiation > > > behavior on mount for independent reasons (i.e., not because active ref > > > + s_umount would be problematic for them) if I understand Kent right. > > > So I'm still not fully convinced each multi-device filesystem should be > > > shipping their special method to get from device to stable sb reference. > > > > Honestly, the sync_filesystem() call seems bogus. > > > > If the block device is truly dead, what's it going to accomplish? > > Notice that fs_bdev_mark_dead() calls sync_filesystem() only in case > 'surprise' argument is false - meaning this is actually a notification > *before* the device is going away. I.e., graceful device hot unplug when > you can access the device to clean up as much as possible.
That doesn't seem to be hooked up to anything? blk_mark_disk_dead() -> blk_report_disk_dead(), surprise is always true disk_force_media_change(), same The only call where it's falso is in s390 code. If we know that a disk is going away, that would be a userspace thing, and they can just unmount. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
