Messages in this thread | | | Date | Tue, 12 Sep 2000 12:49:55 -0500 | From | Jeff Epler <> | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
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/
| |