Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee | Date | Wed, 13 Sep 2000 11:42:46 -0400 (EDT) |
| |
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/
|  |