On Mon 23-06-25 15:04:51, Qu Wenruo wrote: > 在 2025/6/23 14:45, Christoph Hellwig 写道: > > On Fri, Jun 20, 2025 at 05:36:52PM +0200, Jan Kara wrote: > > > On Fri 20-06-25 15:17:28, Qu Wenruo wrote: > > > > Currently we already have the super_operations::shutdown() callback, > > > > which is called when the block device of a filesystem is marked dead. > > > > > > > > However this is mostly for single(ish) block device filesystems. > > > > > > > > For multi-device filesystems, they may afford a missing device, thus may > > > > continue work without fully shutdown the filesystem. > > > > > > > > So add a new super_operation::shutdown_bdev() callback, for mutli-device > > > > filesystems like btrfs and bcachefs. > > > > > > > > For now the only user is fs_holder_ops::mark_dead(), which will call > > > > shutdown_bdev() if supported. > > > > If not supported then fallback to the original shutdown() callback. > > > > > > > > Btrfs is going to add the usage of shutdown_bdev() soon. > > > > > > > > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> > > > > > > Thanks for the patch. I think that we could actually add 'bdev' that > > > triggered shutdown among arguments ->shutdown takes instead of introducing > > > a new handler. > > > > I don't really think that's a good idea as-is. The current ->shutdown > > callback is called ->shutdown because it is expected to shut the file > > system down. That's why I suggested to Qu to add a new devloss callback, > > to describe that a device is lost. In a file system with built-in > > redundancy that is not a shutdown. So Qu, please add a devloss > > callback. And maybe if we have no other good use for the shutdown > > callback we can remove it in favor of the devloss one. But having > > something named shutdown take the block device and not always shutting > > the file system down is highly confusing. > > OK, I got the point of the name "devloss" now, didn't notice the naming > itself is important at that timing. > > And in fact a new callback is much easier on me, no need to modify the code > of other fses. > > @Jan, would this be acceptable for a new devloss() callback instead? OK, now I understand the rationale better as well. Yes, devloss() callback makes sense to me. It just looked weird to have two types shutdown callback. And yes, eventually we might provide a generic handler for devloss callback that will just shut the filesystem down and then we can remove the shutdown callback but that can happen later. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
