Messages in this thread | | | Date | Tue, 12 Sep 2000 21:10:56 +0200 (CEST) | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> |
| |
>>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> Providing everyone is careful to hold a lock I think it is
> lockf() is a read barrier providing the local cache is flushed, > the unlock is a write barrier providing the local cache is > flushed first. Providing all users are using lockf for their > I/O then it seems to be coherent
Sure, but what happens if you're in a mixed client environment? If we have a purely Linux-specific hack to ensure cache coherency, that will still corrupt the cache on those *NIX clients that use ordinary cache coherency checking (i.e. checking mtime + file size) rather than cache invalidation.
There's nothing in the NLM+NFSv2+NFSv3 notes about this situation, but on page 77 of the latest NFSv4 draft it states:
o First, when a client obtains a file lock for a particular region, the data cache corresponding to that region (if any cache data exists) must be revalidated. If the change attribute indicates that the file may have been updated since the cached data was obtained, the client must flush or invalidate the cached data for the newly locked region. A client might choose to invalidate all of non-modified cached data that it has for the file but the only requirement for correct operation is to invalidate all of the data in the newly locked region.
-------
Making mtime a true 64-bit cookie on Linux servers would be a solution that works on all clients. It also avoids a lot of unnecessary cache flushing. Imagine having to reread your entire mailbox every time you open the file whether or not a new message has arrived. Ugh...
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/
| |