Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

From: Jamie Lokier (lk@tantalophile.demon.co.uk)
Date: Wed Sep 13 2000 - 07:46:24 EST


Trond Myklebust wrote:
> > It would not be reasonable to try extending ext2 to 64-bit
> > times, but milliseconds might be doable. You'd need 4 bytes to
> > support the 3 standard time stamps.
>
> > Going to microseconds would require 8 free bytes, which I don't
> > think we have. (but we do have more that one might think, due
> > to the unimplemented junk)
>
> Don't forget that 2^20 > 10^6, hence if you really want units of
> microseconds, you actually only need to save 3 bytes worth of data per
> timestamp.
>
> For the purposes of NFS, however the 'microseconds' field doesn't
> actually have to mean anything. It's just used as a cookie.
> Furthermore, only the mtime field, and to a limited extent the ctime
> field, are used for attribute consistency checking.

If we're getting serious about adding finer-grained mtimes to ext2,
could we please consider using those bits as a way to know, for sure,
whether a file has changed?

Btw, the whole cache coherency thing would probably work very well just
updating times in in-core inodes.

thanks,
-- Jamie
-
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:20 EST