lkml.org 
[lkml]   [2000]   [Sep]   [13]   [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
> 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,
Trond

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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