[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.020 / U:5.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site