On Nov 6, 2008, at Nov 6, 2008, 1:49 PM, Trond Myklebust wrote:
On Thu, 2008-11-06 at 10:34 -0500, Alex Sidorenko wrote:
I understand the reasoning behind that. From application point of
view, NFS
file/directory should behave the same as on local FS. If we have
queued many
writes, without this patch stat() will return incorrect results,
both for
mtime and file length. Some applications may depend on stat()
results being
correct.
At the same time, the fact that we have to wait forever while
copying big
files and doing 'ls -l' on that directory (or on the file being
written) is
not very good either (two HP customers have complained about this
after
migrating from RHEL4 to RHEL5).
In order to relax that requirement, we'd have to introduce some
mechanism for the application to notify the filesystem that they don't
care about strictly correct c/mtimes. As you noted above, returning
incorrect mtimes may trip up some applications (backup applications,
and
mail readers are a couple of business critical cases that come to
mind).
I thought the preferred way to address this issue was to limit the per-
file write cache size on the client. That is effectively what you do
with "-osync" as you suggest below.
Especially on big systems, the client will delay writes until the cows
come home. Then someone does a stat(2) and the lights dim... Really
the client shouldn't need to cache that aggressively, and there are
good reasons to keep a cap on it.
The problem is still there in 2.6.27. I am not sure what can be
done to both
reduce the stat() delay and guarantee reasonable stat() results.
It is interesting that with 'noac' stat() returns much faster (just
1-3s
delay).
That would be because 'noac' enforces synchronous writes. If you don't
care about the degraded write performance, you can do the same thing
without all the extra getattr clutter that noac introduces, by simply
mounting with -osync.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
