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

Christoph Hellwig
2009-05-30T07:58:01Z

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.