Replying to myself,
On Feb 09 13:16:10, Jan Stary wrote:
> Also, specifying 'cvs -d mirror' explicitly should get rid of this
> problem then (right?), and speed things up, which it doesn't.
it does; see below.
> Or is the slowdown possibly due to the sheer *number* of CVS/Root
> files that are consulted? Would that be remedied by cvs -d too?
> Actually, cvs(1) says:
>
> -d CVS_root_directory
> Use CVS_root_directory as the root directory pathname of
> the master source repository. Overrides the setting of the
> CVSROOT environment variable. This value should be specified
> as an absolute pathname.
>
> CVS/Root
> Pathname to the repository ( CVSROOT ) location at the
> time of checkout. This file is used instead of the CVSROOT
> environment variable if the environment variable is not
> set. A warning message will be issued when the contents
> of this file and the CVSROOT environment variable differ.
> The file may be over- ridden by the presence of the
> CVS_IGNORE_REMOTE_ROOT environment variable.
>
> It doesn't state explicitly whether 'cvs -d'
> makes the CVS/Root files ignored. Does it?
I think it does: I tested with ktrace.
Without the explicit -d cvsroot, the kdump of 'ktrace cvs -q up -Pd'
contains a lot of sequences like this (ommiting sigprocmask and mprotect):
27461 cvs CALL stat(0x8a0af780,0xcfbf3da8)
27461 cvs NAMI "CVS"
27461 cvs STRU struct stat {dev=1028, ino=27355, mode=drwxr-xr-x ,
nlink=2, uid=0, gid=0, rdev=117141, atime=1313508893,
stime=1328714573.403561510, ctime=1328714573.403561510, size=512, blocks=4,
blksize=16384, flags=0x0, gen=0x7c8f81d }
27461 cvs RET stat 0
27461 cvs CALL access(0x8a0aff10,0x4<R_OK>)
27461 cvs NAMI "CVS/Root"
27461 cvs RET access 0
27461 cvs CALL open(0x8a0aff10,0<O_RDONLY>,<unused>0x1b6)
27461 cvs NAMI "CVS/Root"
27461 cvs RET open 3
27461 cvs CALL fstat(0x3,0xcfbf3cd0)
27461 cvs STRU struct stat {dev=1028, ino=28235, mode=-rw-r--r-- ,
nlink=1, uid=0, gid=0, rdev=113711, atime=1328714573.403561510,
stime=1328714573.403561510, ctime=1328714573.403561510, size=21, blocks=4,
blksize=16384, flags=0x0, gen=0xbde86d5b }
27461 cvs RET fstat 0
27461 cvs CALL read(0x3,0x85d34000,0x4000)
27461 cvs GIO fd 3 read 21 bytes
"/home/cvsync/openbsd
"
27461 cvs RET read 21/0x15
I haven't looked at the cvs source code, but this is
undoubtedly cvs checking if there is a readable CVS/Root,
opening it, and reading it (indeed, "/home/cvsync/openbsd"
is my locally cvsync'd cvsroot).
Now, with the explicit cvs -d cvsroot, a kdump of
'ktrace cvs -q -d /home/cvsync/openbsd up -Pd' says
3670 cvs CALL access(0x3c00f315,0<F_OK>)
3670 cvs NAMI "CVS/Root"
3670 cvs RET access 0
which is just a check whether the file exists.
It is never opened, read from, or written to.
So it seems that 'cvs -d mirror up -d' creates the CVS/Root file
(and writes mirror into it) if the file doesn't exist; if it does
exist, it is ignored.
> > > The exact cause of the slowdown is not known to me. But when you are
> > > switch repositories once in a while it's easy to get this case.
> > >
> > > I repair this by find . -name Root | xargs rm and using a explicit cvs
> > > root.
>
> So, using an explicit cvs root does not ignore the CVS/Root files?
> Because if it does, then the 'find | xargs rm' should make no difference,
> right?
Given the above, doing
find . -name Root | xargs rm
cvs -d mirror up -Pd
actually means *more* work, as it creates and writes all the CVS/Root files.
If they are left there (skip the find | xargs rm), it is only checked that
they exist and left intact -- which is less work, right?
(Then again, I am just reading a kdump. I don't know what CVS really does.)
Here are the "tests" I did on /usr/src, in the simplest case
of having a local cvsroot, uniform for all files in the tree:
With the CVS/Root files present, all containing "/home/cvsync/openbsd":
time cvs -q up -Pd
4m44.15s real 0m4.64s user 0m8.49s system
4m43.67s real 0m4.25s user 0m8.84s system
4m11.57s real 0m4.36s user 0m8.77s system
4m20.84s real 0m4.55s user 0m8.46s system
4m24.09s real 0m4.43s user 0m8.82s system
4m52.91s real 0m4.32s user 0m8.40s system
4m42.52s real 0m4.53s user 0m8.36s system
4m33.40s real 0m4.64s user 0m8.35s system
4m55.80s real 0m4.43s user 0m8.51s system
time cvs -q -d /home/cvsync/openbsd up -Pd
4m24.48s real 0m4.28s user 0m8.35s system
4m21.63s real 0m4.27s user 0m8.43s system
4m14.73s real 0m4.44s user 0m8.43s system
4m13.98s real 0m4.26s user 0m7.93s system
4m17.07s real 0m4.38s user 0m7.90s system
4m18.60s real 0m4.35s user 0m8.77s system
3m55.10s real 0m4.09s user 0m7.97s system
(So specifying the cvsroot is a bit faster.)
Without any CVS/Root present (so 'cvs -d' is actually necessary):
{ find . -name Root | xargs rm ;
time cvs -q -d /home/cvsync/openbsd up -Pd ; }
4m42.88s real 0m4.52s user 0m8.53s system
4m35.68s real 0m4.74s user 0m8.43s system
4m31.55s real 0m4.69s user 0m7.97s system
4m29.73s real 0m4.79s user 0m8.23s system
4m58.93s real 0m4.67s user 0m8.68s system
4m38.06s real 0m4.05s user 0m8.47s system
(So removing the CVS/Root files first only makes it a bit slower
for me when using 'cvs -d'; possibly because it has to create
and write all the CVS/Root files, see above.)
Note that my cvs root is local, and is uniform for all the files.
Also, I am not cvsyncing my local cvsroot during this (obviously).
So the above cvs up's don't actually do nothing to the tree. Which
I believe is a good thing, for the purpose of testing this.
It only occured to me now that if I did an 'umount && mount'
in between the runs, I could also eliminate the FS caching
that probably influences these (naive) tests.
Things might change if (1) the cvsroot is remote (2) it is not
the same for all files. I will try that next.
Jan
