Messages in this thread | | | Date | Thu, 5 Jan 2012 13:27:52 -0500 | From | Ted Ts'o <> | Subject | Re: Revoking filesystems [was Re: Sysfs attributes racing with unregistration] |
| |
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?
| |