Re: Revoking filesystems [was Re: Sysfs attributes racing withunregistration]

[Tejun Heo]

Hello,

On Thu, Jan 05, 2012 at 02:28:22PM -0500, Ted Ts'o wrote:
> > I think these are two separate mechanisms.  Filesystems need to be
> > able to handle IO errors no matter what and underlying device going
> > away is the same situation.  There's no reason to mix that with force
> > unmount.  That's a separate feature and whether to force unmount
> > filesystem on device removal or permanent failure is a policy decision
> > which belongs to userland - ie. if such behavior is desired, it should
> > be implemented via udev/udisk instead of hard coded logic in kernel.
> 
> I think it's needless complexity to loop this into userspace.  If the
> block device is gone, it's *gone*.  What else could userspace do with
> this information that block device has disappeared?  Right now, once
> gone, it's never coming back.  Even if the luser plugs the USB device
> back in, it's going to be coming back as a new block device node.
> 
> So we might as well automatically forcibly unmount the file system at
> this point.  I can imagine sending an optional notification that such
> a thing has happened, perhaps via a netlink socket, but why not have
> the kernel do the right thing automatically?

* If this was the one method to deal with hotunplug, sure, but it's
  not.  We already have (supposedly) working failure mode for hot
  device removal.

* Any modern linux distro already has all the infrastructure to handle
  this.  You can't handle hotplug without userland provided poicies
  and the same mechanism is used for hotunplugging too, *today*.  If
  force umount is decided to be the action to take on block device
  removal, that would be several line changes in userland.  Userland
  is already responsible for taking actions for those events.

* Such automation might look like a good idea now but we really don't
  know how it would end up in the longer run or for different use case
  scenarios.  I think a good example of this is the cdrom driver.  It
  implents tons of automatic behaviors, and then had to be augmented
  with ioctls to turn on and off them as they no longer fit new
  hardware, new userland behavior and changing user expectations.

So, regardless of whether adding revoking is a good idea or not, I
believe that force umount should be a separate thing from internal
block error handling.

> The other use case would be a system administrator who doesn't want to
> figure out which random shell is still cd'ed into a directory of a
> file system he/she wants to unmount, he can still force the umount.
> (Other Unix systems have had this feature in the past, and the result
> is the same as what happens if you are cd'ed into a directory which is
> later rmdir'ed.)  It's an ungraceful way of running things, but
> sometimes it's the easist way to go.

More importantly, I can't really see valid use cases other than
scenarios like the above for using revocation for usual hot unplug.
For most users, it wouldn't matter one way or the other.  It's not
like sync + lazy umount can't achieve (note that all the desktop stuff
knows about "filesystem is going away" and will gracefully step aside)
most of forced umount anyway.  It could be nice to cli aficionados or
grumpy admins but for the vast majority of userbase, it just wouldn't
matter.  Given that, I'm not convinced this is a worthwhile thing to
have.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/