Messages in this thread | | | Date | Wed, 13 Sep 2000 07:15:58 -0500 | From | Jeff Epler <> | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
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/
| |