On 28.05.2013 12:54, Philip Martin wrote:
> Tobias Bading<tbading_at_web.de> writes:
>> On 27.05.2013 16:12, Tobias Bading wrote:
>>> On 27.05.2013 16:01, Branko Čibej wrote:
>>>> Can you try this: run the following command for a couple of seconds, it
>>>> should give you an idea about the system clock precision.
>>>>
>>>> { while true; do date '+%M:%S.%N'; done; } | uniq
>>> Redirected to a file, I get about 1250 unique timestamps per second, nicely distributed it seems.
>> Hmm... a modified version of your command paints a completely different picture:
>>
>> { while true; do touch t; ls -l --full-time t; done; } | uniq
>>
>> prints exactly *two* lines per second, one every 0.5 second, exact down to the millisecond.
>> No idea why yet, but this explaines everything I guess. Asking Google...
> An earlier mail showed us that you are using ext4 on OSX -- does OSX
> have native support for ext4 now or are you using a 3rd party driver?
Sounds like a misunderstanding. On Saturday, I compiled Subversion 1.8
RC2 at home on my MacBook to check whether I could reproduce the problem
on a different platform. I couldn't, "make check" worked fine on Snow
Leopard (on a HFS+ disk).
On my Ubuntu Lucid machine at work, the problem persists on an ext4
partition.
> Subversion assumes that a sub-second timestamp implies at least a
> millisecond resolution but that is not the case on your ext4 filesystem.
I'm not sure where exactly the source of the problem is. So far I know:
a) 'touch -d "2013-05-27 14:27:35.069850993" t ; ls --full-time t' works
fine and shows the file's timestamp 100% correct to the nanosecond.
b) '{ while true; do echo "" >t; ls -l --full-time t; rm t; done; } |
uniq' prints exactly *two* lines per second, one every 0.5 seconds,
exact down to the millisecond.
No matter whether the test under b) uses touch or creates a new file
every time, I only get two different timestamps each second. I didn't
find an explanation via Google yet. Someone suggested that the ext4
implementation might use a cached kernel time and that time is only
updated at certain timer intervals.
> We would need to modify the sleep algorithm if we are to support this
> filesystem.
>
> We could modify the sleep calculation to something like:
>
> if timestamp has sub 1ms component
> sleep for 1ms
> else if timestamp has sub 10ms component
> sleep for 10ms
> else if timestamp has sub 100ms component
> sleep for 100ms
> else
> sleep for 1s
>
> or perhaps do it in base 2 rather than base 10?
From what I googled so far there doesn't seem to be a reliable way to
determine the timestamp resolution of a filesystem. And as my kind of
spooky case shows, there seem to be other dark forces at work as well... ;-)
Received on 2013-05-28 13:40:00 CEST