On Wed, 25 Jun 2008, Miklos Szeredi wrote:
quoted text
> 
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/