[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.344 / U:1.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site