[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
>>>>> " " == Albert D Cahalan <> 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.

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.124 / U:12.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site