>>>>> " " == 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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:19 EST