On 06.06.2013 13:04, Ben Reser wrote:
> [...]
>> I think coming up with a safer implementation of
>> svn_io_sleep_for_timestamps would be a better long-term solution. The chance
>> of encountering such a failure increases as CPUs become faster and faster,
>> but the accuracy of file modification timestamps stays the same. Even on
>> 'good' Linux kernels, this accuracy seems to be only 0.01 or 0.004 seconds.
>> I almost feel the itch to rebuild Subversion 1.8 RC2 with SQLITE_NO_SYNC
>> #define'd to see whether more tests fail due to faster operations without
>> SQLite's fsync calls.
> Clearly svn_io_sleep_for_timestamps() needs some more thought. There
> was some discussions between Julian, Philip and myself about this a
> while back. svn_io_sleep_for_timestamps() can actually make things
> worse if we're using commit times as the timestamps.
>
> As far as how good the timestamp accuracy is, I was under the
> impression that ext4 had nanosecond timestamp resolution.
Yes, ext4 has nanosecond resolution, but the Linux kernels I've tested
so far, which includes the newest mainline 3.9.4 kernel, aren't able to
produce more than 250 unique file modification timestamps per second.
Some generate only 100 per second, and the really 'bad ones' (at least
Ubuntu 2.6.32-4[567]) only *two*. There obviously is some sort of
timestamp caching involved, for performance reasons would be my guess.
If https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1185730 doesn't
lead to an explanation, maybe reporting this directly to the mainline
Linux gurus might help, because the bug is not caused by Ubuntu kernel
modifications.
Tobias
Received on 2013-06-06 13:18:32 CEST