[lkml]   [2000]   [Sep]   [13]   [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 Wed, Sep 13, 2000 at 11:56:56PM +0200, Trond Myklebust wrote:
> After consultation with the appropriate authorities, it turns out that
> the Sun-code based clients do in fact turn off data caching entirely
> when using NLM file locking.

Entirely? That's interesting, because for our consistency requirements we
only need the data cache to be flushed for a particular inode at the time
of a locking call. At least if we port to Solaris (hah!) we won't have
this particular problem in our clients.

> Attribute cache consistency checking on
> NFSv4 differs from v2/v3 in that you have a new attribute that is
> guaranteed to change every time the file changes.

That would be very welcome, but it's doubtful we could get an nfsv4 server
to run on our old bsdi 1.x-based servers :)

Thank you very much for continuing to pursue this. I wish I were an NFS
expert, but as I may have said elsewhere, this task falls to me as the
Linux evangelist at the office.

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