On Sun, Oct 15, 2017 at 09:13:01PM -0400, Theodore Ts'o wrote: > On Sun, Oct 15, 2017 at 05:14:41PM -0500, Eric W. Biederman wrote: > > > > Looking at the code it appears ext4, f2fs, and xfs shutdown path > > implements revoking a bdev from a filesystem. Further if the ext4 > > implementation is anything to go by it looks like something we could > > generalize into the vfs. > > There are two things which the current file system shutdown paths do. > The first is that they prevent the file system from attempting to > write to the bdev. That's all very file system specific, and can't be > generalized into the VFS. > > The second thing they do is they cause system calls which might modify > the file system to return an error. Currently operations that might > result in _reads_ are not shutdown, so it's not a true revoke(2) Which is different to XFS - XFS shuts down all access to the bdev, read or write, and returns EIO to the callers.(*) IOWs, a UAPI has been copy-and-pasted, but the behaviour and semantics have not been copied/duplicated. The requirement was "close enough for fstests to use it" not "must behave the exact same way on all filesystems". >From that perspective, I agree with Ted: we need an interface that provides userspace with sane, consistent semantics and allows filesystems to be disconnected from userspace references so can be unmounted. What the filesystem then does to disconnect itself from the block device and allow unmount to complete (i.e. the shutdown implementation) is irrelevant to the VFS and users.... Cheers, Dave. (*) Shutdown in XFS is primarily intended to prevent propagating damage in the filesystem when corruption is first detected or an unrecoverable error occurs. Historically speaking, it is always initiated by the XFS filesystem itself, so whatever we do to provide unmount sanity isn't going to replace internal filesystem shutdown functionality... -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
