[lkml]   [2000]   [Sep]   [12]   [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
>>>>> " " == Jeff Epler <> writes:

> But "ctime and file size are the same" does not prove that the
^^^^^ mtime
> file is unchanged. That's the root of this problem, and why
> NFS_CACHEINV(inode) is not enough to ensure coherency.

Yes, but I just demonstrated that messing around with the client is a
hack, not a solution to this situation.
It's a hack because it is not compatible with the expected behaviour
of NFS clients. The NFSv4 draft demonstrates what the expected
behaviour is, and illustrates what we have to implement for a generic
fix (one that works on all clients -- not hacked Linux ones).

This is why I'm saying the correct solution is to get the server to
change mtime. To use the 'microseconds' field that is supported by the
NFS protocol, and that we currently set to 0.

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.104 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site