[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectNFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
>>>>> " " == Jeff Epler <> writes:

> I believe I have discovered a problem in the Linux 2.2 nfs
> client. The short story is that NFS_CACHEINV(inode) does not
> "act as a cache coherency point" (as nfs/file.c:nfs_lock()'s
> comment implies) when multiple modifications to a file take
> place during the same second, because in that case the file's
> mtime is not changed.

> The fix we have found is to *either* have NFS_CACHEINV(inode)
> change inode-> i_mtime to an artificial value (0) or to call
> nfs_zap_caches instead. Since I am not sure which fix is
> appropriate, I'm not enclosing an actual patch.

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
for the mtime. Under NFSv2, the low 32 bits are meant to be
interpreted in units of micro-seconds. Under NFSv3, the units are
For the purposes of ensuring cache coherency, the 'sub-second' field
doesn't actually have to be a time-related thing at all. It could
simply be an 'operation count' or something like that. The
nfs_refresh_inode() uses the mtime field as a 64-bit cookie, so it
doesn't care as long as the field is conserved across server reboots.

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