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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
