[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
On Tue, Sep 12, 2000 at 09:10:56PM +0200, Trond Myklebust wrote:
> >>>>> " " == Alan Cox <> 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.

We don't alter anything about what the other clients cache. Sure, you can
connect to the same server with a client that doesn't have this fix, and
sure you might get different cached data on different clients at the same
time, but that's the current situation. You don't make it *worse* for
anybody else, you make it *better* for Linux.

> 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.

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.

> Making mtime a true 64-bit cookie on Linux servers would be a solution
> that works on all clients.

Yes, but my solution works for all servers with a Linux client. (We've been
making this modification to NFS clients in several other unices for years,
we know it works and gives the guarantees we need)

> 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...

It's better to get wrong results if you run a mail client at the same time
on two different machines, right?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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