[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
>>>>> " " == Jeff Epler <> 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.

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:38    [W:0.207 / U:8.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site