lkml.org 
[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
From
>>>>> " " == Jeff Epler <jepler@inetnebr.com> 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.

Cheers,
Trond
-
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/

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