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

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Wed Sep 13 2000 - 15:19:19 EST


>>>>> " " == Albert D Cahalan <acahalan@cs.uml.edu> writes:

> 20 bits * 3 timestamps == 60 bits 60 bits <= 8 bytes

> So you do need 8 bytes.

Yes. Assuming that you want to implement the microseconds field on all
3 timestamps. For NFS I would only need that precision on mtime.
Does anybody else see a need for it on ctime and/or atime?

> I thought of this, but I don't think it is safe.

> write to file X us=1 write to file Y us=1 write to file Y us=2
> write to file Y us=3 write to file X us=2

> Oops, "make" on some clients will think Y is newer than X.

> Using the wrong unit would be OK, as long as it is a real
> sub-second time unit that doesn't overflow... but then you
> might as well convert it to microseconds.

Sure, but the alternative might be to reserve some bits as an
'operations counter' that is incremented every time an update is
performed. That way you might have milisecond resolution (which is the
sort of resolution that 'jiffies' & friends offers) + a few extra bits
that would be there for make/NFS/... update consistency.

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:22 EST