> The problem with "increment mtime by a nanosecond when necessary" is
> that timestamps can wind up out of order. As in:
Surely that depends on your implementation ?
> 1) Do a bunch of operations on file A
> 2) Do one operation on file B
>
> Imagine each operation on A incrementing its timestamp by a nanosecond
> "just because". If all of these operations happen in less than 4 ms,
> you can wind up with the timestamp on B being EARLIER than the
> timestamp on A. That is a big no-no (think "make" or anything else
> relying on timestamps for relative times).
[time resolution bits of data][value incremented value for that time]
if (time_now == time_last)
return { time_last , ++ct };
else {
ct = 0;
time_last = time_now
return { time_last , 0 };
}
providing it is done with the same 'ct' across the fs and you can't do
enough ops/second to wrap the nanosecs - which should be fine for now,
your ordering is still safe is it not ?
> If you can prove that the last modification on B happens after the
> last modification on A, then it is very bad for the mtime on B to be
> earlier than the mtime on A. I guarantee that will break things in
> the real world.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
