[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0806250928460.4769@hp.linux-foundation.org>
Date: Wed, 25 Jun 2008 09:30:50 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Miklos Szeredi <miklos@...redi.hu>
cc: 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()
On Wed, 25 Jun 2008, Miklos Szeredi wrote:
>
> We discussed this yesterday. My conclusion was (which I still think
> is true) that it can't be fixed in page_cache_pipe_buf_confirm(),
> because due to current practice of not setting PG_error for I/O errors
> for read, it is impossible to distinguish between a never-been-uptodate
> page and a was-uptodate-before-invalidation page.
Umm. The regular read does this quite well. If something isn't up-to-date,
it tries a synchronous read. Once.
> And it's not just an nfsd issue. Userspace might also expect that if
> a zero count is returned, that means it went beyond EOF, and not that
> it should retry the splice, maybe it has better luck this time.
You're totally ignoring the real issue - user space that uses splice()
*knows* that it uses splice(). It's a private mmap().
NFSD, on the other hand, is supposed to act as NFSD. I think that
currently it assumes that nobody else modifies the files, which is
reasonable, but breaks with FUSE.
But do you see? That's a NFSD/FUSE issue, not a splice one!
Linus
--
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