>>>>> " " == Jeff Epler <jepler@ispi.net> 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
nanoseconds.
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.
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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:18 EST