On 27.05.2013 15:40, Tobias Bading wrote:
> On 27.05.2013 12:43, Branko Čibej wrote:
>> On 27.05.2013 09:59, Tobias Bading wrote:
>>> Quick update:
>>> The problem is definitely timestamp related. "touch 3449_spurious"
>>> fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
>>> properly afterwards. I'll try to figure out why my machine is living
>>> in its own timeline. All I can say after reading just a few lines of
>>> python code is that I don't have
>>> SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS
>>> hard-wired to 'yes' :-).
>> Well, that's a relief, at least.
>>
>> Can you please get two pieces of information:
>>
>> 1) run the "mount" command and past the line representing the ext4
>> filesystem where your working copy lives
>
> /dev/sdb1 on / type ext4 (rw,relatime,errors=remount-ro)
>
>> 2) Get the ext4 superblock info, using "sudo tune2fs -l /dev/something";
>> the mount output will tell you which /dev/something
>
> tune2fs 1.41.11 (14-Mar-2010)
> Filesystem volume name: <none>
> Last mounted on: /
> Filesystem UUID: dcabb217-5e67-45ee-bbd1-bc78b9755514
> Filesystem magic number: 0xEF53
> Filesystem revision #: 1 (dynamic)
> Filesystem features: has_journal ext_attr resize_inode dir_index
> filetype needs_recovery extent flex_bg sparse_super large_file
> huge_file uninit_bg dir_nlink extra_isize
> Filesystem flags: signed_directory_hash
> Default mount options: (none)
> Filesystem state: clean
> Errors behavior: Continue
> Filesystem OS type: Linux
> Inode count: 15269888
> Block count: 61049088
> Reserved block count: 3052452
> Free blocks: 26233604
> Free inodes: 13780922
> First block: 0
> Block size: 4096
> Fragment size: 4096
> Reserved GDT blocks: 1009
> Blocks per group: 32768
> Fragments per group: 32768
> Inodes per group: 8192
> Inode blocks per group: 512
> RAID stride: 32730
> Flex block group size: 16
> Filesystem created: Tue Jul 5 15:41:05 2011
> Last mount time: Mon May 27 09:14:16 2013
> Last write time: Mon Apr 29 09:44:35 2013
> Mount count: 18
> Maximum mount count: 27
> Last checked: Mon Apr 29 09:44:35 2013
> Check interval: 15552000 (6 months)
> Next check after: Sat Oct 26 09:44:35 2013
> Lifetime writes: 1283 GB
> Reserved blocks uid: 0 (user root)
> Reserved blocks gid: 0 (group root)
> First inode: 11
> Inode size: 256
> Required extra isize: 28
> Desired extra isize: 28
> Journal inode: 8
> First orphan inode: 4072404
> Default directory hash: half_md4
> Directory Hash Seed: 3cc06f24-54d0-4435-94d0-d8ce07f75445
> Journal backup: inode blocks
>
>
>
> Further tests:
> After the failed test, 'ls -l --full-time 3449_spurious' prints the
> timestamp '2013-05-27 14:27:35.069850993 +0200'.
> At this point, 'svn status 3449_spurious' claims that 3449_spurious is
> unmodified. (This is what caused the test failure).
>
> After a 'touch -d "2013-05-27 14:27:35.069850" 3449_spurious', 'ls -l
> --full-time 3449_spurious' prints the timestamp '2013-05-27
> 14:27:35.069850000 +0200' and 'svn status 3449_spurious' still claims
> that the file is unmodified.
>
> After a 'touch -d "2013-05-27 14:27:35.069851" 3449_spurious', 'svn
> status 3449_spurious' admits that the file has been modified.
>
> This makes sense I guess, because apr_finfo_t has microsecond
> resolution, whereas stat(2) (and ext4 obviously) have nanosecond
> resolution. What doesn't make sense to me is why I have to patch
> svn_io_sleep_for_timestamps to sleep a whole second. Waiting e.g. 0.1
> seconds is not sufficient.
>
> I tested a 'touch t1 ; touch t2 ; ... ; touch t50' and then 'ls -l
> --full-time', which shows identical timestamps for all 50 files. Isn't
> that a bit... odd?
Hmmmm .... there's a difference between the /resolution/ of the
timestamp (in the filesystem) and the /precision/ of either the
timestamp or the system clock.
In this case, judging from your "touch" test, it would appear that the
system clock has a much lower precision than one would expect.
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
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
