On Thursday 26 June 2008 04:35, Miklos Szeredi wrote: > > > I also really don't think this even fixes the problems you have with > > > FUSE/NFSD - because you'll still be reading zeroes for a truncated > > > file. Yes, you get the rigth counts, but you don't get the right data. > > > > ... > > > > > That's "correct" from a splice() kind of standpoint (it's essentially a > > > temporary mmap() with MAP_PRIVATE), but the thing is, it just sounds > > > like the whole "page went away" thing is a more fundamental issue. It > > > sounds like nfds should hold a read-lock on the file while it has any > > > IO in flight, or something like that. > > > > I'm thinking any kind of user-space server using splice() will not > > want to transmit zeros either, when another process truncates the file. > > E.g. Apache, Samba, etc. > > > > Does this problem affect sendfile() users? > > AFAICS it does. > > And I agree, that splice should handle truncation better. But as I > said, this affects every single filesystem out there. And yes, my > original patch wouldn't solve this (although it wouldn't make it > harder to solve either). > > However the page invalidation issue is completely orthogonal, and only > affects a few filesystems which call invalidate_complete_page2(), > namely: 9p, afs, fuse and nfs. I don't know what became of this thread, but I agree with everyone else you should not skip clearing PG_uptodate here. If nothing else, it weakens some important assertions in the VM. But I agree that splice should really try harder to work with it and we should be a little careful about just changing things like this. -- 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