[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
>>>>> " " == Jeff Epler <> writes:

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

> Furthermore, according to NFSv4, what I am suggesting is
> something that a client "may choose" to do anyhow---i.e., it's
> at least permitted by the spec, even if it's not required.

It appears I owe you an apology, and I'd better make it in public.

After consultation with the appropriate authorities, it turns out that
the Sun-code based clients do in fact turn off data caching entirely
when using NLM file locking. Attribute cache consistency checking on
NFSv4 differs from v2/v3 in that you have a new attribute that is
guaranteed to change every time the file changes.

I'm still not happy with that solution, as it means that performance
is sub-optimal for a number of interesting cases, and it screws up
mmap() royally. However it does shoot to pieces my argument that we
currently do conform to standard behaviour.

Cheers and sorry,

BTW: the microsecond mtime resolution on the NFS server remains an
issue, but now only for the ordinary case of attribute cache
consistency checking.
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.088 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site