[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Strange failure of log_tests.py#7 -- missing commit in guarantee_repos_and_wc ?

From: Tobias Bading <tbading_at_web.de>
Date: Thu, 06 Jun 2013 13:17:53 +0200

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

Received on 2013-06-06 13:18:32 CEST

This is an archived mail posted to the Subversion Dev mailing list.