I think that both the NFS server changes that Trond is suggesting and the
NFS client changes that I am suggesting have their place.
The fact that the tuple (mtime, size) is used to test to test for
unchangedness of a file indicates that the people who designed NFS
understood that just using mtime wasn't enough. The problem is that using
(mtime, size) is not enough either, and I don't understand why anyone ever
thought it would be. Trivial example:
write(fd, "a", 1);
llseek(fd, 0, 0);
write(fd, "b", 1);
My solution will enable the Linux client (and other clients implementing
the same fix) to achieve the coherency promised by the comment in
nfs_lock(), at the expense of slightly lower performance, no matter what
NFS server they use (even a hypothetical one with mtime resolution of a
year).
Trond's nfs server changes would enable any client communicating with it to
achieve the coherency promised in nfs_lock(), without the performance
loss, but unfortunately the changes can't be made today and don't solve
anything for non-Linux NFS servers.
Thus, the only thing that is missing from my proposal is a way to fall back
on the old invalidation code, for that time in the future where mtime
changes are always sufficient to distinguish changes n a file. I'm not
going to sweat this, since it sounds like this isn't implemented anywhere
else and won't be in Linux for some time. When it comes along, we can
upgrade mount and the nfs client with a new flag.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:22 EST