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

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.084 / U:0.360 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site