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

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?

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.208 / U:24.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site