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

From: Jeff Epler (jepler@inetnebr.com)
Date: Tue Sep 12 2000 - 12:49:55 EST


On Tue, Sep 12, 2000 at 07:08:09PM +0200, Trond Myklebust wrote:
> This is a known issue, and is not easy to fix. Neither of the
> solutions you propose are correct since they will both cause a cache
> invalidation. This is not the same as cache coherency checking.
>
>
> The correct solution in this case would be to add a 'sub-second time
> field' to ext2fs & friends. Both NFSv2 and NFSv3 pass a 64 bit field
[...]

Trond,
Thanks for your swift answer. I sent a message a few months ago with
a much poorer solution which was perhaps rightly ignored....

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?

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