lkml.org 
[lkml]   [2000]   [Sep]   [12]   [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
>>>>> " " == 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/

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