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). > 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. Cheers Trond -- 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
