On Tue, Oct 17, 2017 at 09:00:11AM +1100, Dave Chinner wrote: > > 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". Funny story, we was actually trying to copy XFS's semantics. Originally I had a shutdown test in ext4's readpage() and readpages() --- but during the code review, someone pointed out that xfs didn't have those tests in xfs_vm_readpage() and xfs_rm_readpages(). Since it didn't really matter for my intended use case, I ended up removing the checks from ext4's readpage() and readpages() functions. What we didn't notice the that the shutdown test was in xfs_get_blocks(). > 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.... I agree that we should formally define what the semantics should be. I also believe it should work even if the file system doesn't support journals, and the file system should be left in a consistent state if possible, since there are three different, distinct use cases: * The file system is damaged, so we want to avoid making any changes to the file system to minimize further damage. * The block device has already disappeared, and we are trying to minimize the block I/O devices. We would also prefer that attempts to write dirty pages in the writeback pages not cause a kernel panic. * The user wants to remove the USB thumb drive, but hasn't removed it yet, and the system would like to cleanly unmount the file system and leave the thumb drive in a consistent state --- without having to force userspace to brute force search through /proc and terminate processes just to allow the device to be unmounted. - Ted -- 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
