[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1KBZqG-0008OZ-Pw@pomaz-ex.szeredi.hu>
Date: Wed, 25 Jun 2008 20:35:40 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: jamie@...reable.org
CC: torvalds@...ux-foundation.org, miklos@...redi.hu,
jens.axboe@...cle.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, hugh@...itas.com,
nickpiggin@...oo.com.au
Subject: Re: [patch 1/2] mm: dont clear PG_uptodate in invalidate_complete_page2()
> > 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.
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists