Re: Revoking filesystems [was Re: Sysfs attributes racing with unregistration]

["Ted Ts'o" <tytso@mit.edu>]

On Thu, Jan 05, 2012 at 11:47:54AM -0500, Alan Stern wrote:
> > Well the choices are really:
> > a) On a block device hotunplug keep the device and have it simply report
> >    everything as errors, to the filesystem.  Maybe with a hint to the
> >    filesystem that something is wrong.
> > b) Have a filesystem revoke method so that we don't have to keep the
> >    unplugged block device structure around indefinitely.
> 
> When I asked Ted about this, he strongly indicated that he preferred 
> b).

Ideally, we should do both.  The block device should call a
notification function (probably run out of a workqueue context, to
avoid locking issues) which tells the file system, "the block device
is _gone_ and isn't coming back".  Any attempts to read or write to
the block device should return errors, since there maybe writeback
happening in the background while the file system is shutting down
file system mount.  Once the file system is done, it can all a
function which tells the block device layer that it's OK to release
the block device and its related structures.

In order for the file system to shut down the file system cleanly, it
will need to access VFS-level revoke functionality that replaces file
descriptors with ones that returns an error on reads and writes, and
which does the right thing with mmap's[1], etc.

So it's really more of a filesystem force-umount method.  I could
imagine that this could also be used to extend the functionality of
umount(2) so that the MNT_FORCE flag could be used with non-NFS file
systems as well as NFS file systems.

				- Ted

[1] Interesting question: do we convert an mmap region to an anonymous
region and perhaps notify the user out of band this has happened?  Or
do we just make the mapping disappear and nuke the process with a SEGV
if it attempts to access it?