Messages in this thread |  | | Date | Tue, 12 Sep 2000 20:19:12 +0200 (CEST) | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
|  |