Re: Read/Write NFS I/O performance degraded by FLUSH_STABLE page flushing

["J. Bruce Fields" <bfields@fieldses.org>]

On Sat, May 30, 2009 at 03:57:56AM -0400, Christoph Hellwig wrote:
> On Sat, May 30, 2009 at 10:22:58AM +1000, Greg Banks wrote:
> >  * The underlying filesystem might be doing more or better things in
> > one or the other code paths e.g. optimising allocations.
> 
> Which is the case with ext3 which is pretty common.  It does reasonably
> well on O_SYNC as far as I can see, but has a catastrophic fsync
> implementation. 
> 
> >  * The Linux NFS server ignores the byte range in the COMMIT rpc and
> > flushes the whole file (I suspect this is a historical accident rather
> > than deliberate policy).  If there is other dirty data on that file
> > server-side, that other data will be written too before the COMMIT
> > reply is sent.  This may have a performance impact, depending on the
> > workload.
> 
> Right now we can't actually implement that proper because the fsync
> file operation can't actually flush sub ranges.  There have been some
> other requests for this, but my ->fsync resdesign in on hold until
> NFSD stops calling ->fsync without a file struct.
> 
> I think the open file cache will help us with that, if we can extend
> it to also cache open file structs for directories.

Krishna Kumar--do you think that'd be a reasonable thing to do?

--b.