Messages in this thread | | | Date | Wed, 13 Sep 2000 23:56:56 +0200 (CEST) | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
| |