Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Tue Sep 12 2000 - 13:19:12 EST


>>>>> " " == Jeff Epler <jepler@inetnebr.com> writes:

> Is there any solution that's available today, and doesn't
> depend on using Linux in the server? I suspect that we will
> have to distribute a modified nfs client with our app, and
> we're prepared to accept the cache invalidation (and reduced
> performance it causes) for a technique that will work with any
> NFS server and provide the level of guarantees we need.

> Is there a solution that would allow the kind of guarantee our
> software wants with non-linux nfsds without the cache-blowing
> that the change I'm suggesting causes?

If you ensure that the file length is changed each time it is written
to, then the cache coherency checking will detect that, and a cache
invalidation is guaranteed to occur. That is something that will
normally work on all NFS implementations.

Relying on the sub-second timing fields is a much more
implementation-specific. It depends on the capabilities of both the
filesystem and the server OS.
Linux and the knfsd server code could easily be modified to provide
such a service, but the problem (as I've stated before) is that you
need to save the time somewhere on disk. I believe currently ext2
provides only 32 bits of storage for mtime (though perhaps somebody
else could comment on that).
UFS does provide a 64-bit storage space for mtime. It would surprise
me if the other *NIX implementations aren't using this to improve NFS
cache consistency.

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:18 EST