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

From: Albert D. Cahalan (acahalan@cs.uml.edu)
Date: Wed Sep 13 2000 - 10:42:46 EST


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

>> 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.

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

So you do need 8 bytes.

> For the purposes of NFS, however the 'microseconds' field doesn't
> actually have to mean anything. It's just used as a cookie.

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.

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