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