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

J. Bruce Fields
2009-06-01T22:30:13Z

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.