On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote: > On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote: > > > tmpfs seems to be incorrectly returning 0-bytes when reading from > > a file that is concurrently being truncated. > > That is an interesting observation, and you got me worried; > but in fact, it is not a tmpfs problem: if we call it a > problem at all, it's a VFS problem or a userspace problem. > > You chose a ratio of 3 preads to 1 ftruncate in your program below: > let's call that the Unterwurzacher Ratio, 3 for tmpfs; YMMV, but for > me 4 worked well to show the same issue on ramfs, and 15 on ext4. > > The Linux VFS does not serialize reads against writes or truncation > very strictly: Which is a fine, because... > it's unusual to need that serialization, and most .... many filesystems need more robust serialisation as hole punching (and other fallocate-based extent manipulations) have much stricter serialisation requirements than truncate and these .... > users prefer maximum speed to the additional locking, or intermediate > buffering, that would be required to avoid the issue you've seen. .... require additional locking to be done at the filesystem level to avoid race conditions. Throw in the fact that we already have to do this serialisation in the filesystem for direct IO as there are no page locks to serialise direct IO against truncate. And we need to lock out page faults from refaulting while we are doing things like punching holes (to avoid data coherency and corruption bugs), so we need more filesystem level locks to serialise mmap against fallocate(). And DAX has similar issues - there are no struct pages to serialise read or mmap access against truncate, so again we need filesystem level serialisation for this. Put simple: page locks are insufficient as a generic mechanism for serialising filesystem operations. The locking required for this is generally deeply filesystem implementation specific, so it's fine that the VFS doesn't attempt to provide anything stricter than it currently does.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
