Re: [Gnu-arch-users] Re: cscvs--experimental--1.1 nearing doneness; call for testers

[Andrea Arcangeli]

On Tue, Sep 30, 2003 at 10:04:46AM -0500, John Goerzen wrote:
> I am now running cache -b again and it looks better.  I will shortly
> be attempting to run totla.  Then we will see just how well tla
> manages 12,000 patches.  (Personally, I've got fsck handy just in case
> :-)

;)

you won't need fsck, what you need is lots of space in the archive and
something to do while you wait tla to stat 10000 files before every new
checkin ;) The slowdown is linear, at 2000 it just takes a second.

If you use reiserfs it'll scale much better for getdeents, but the speed
of the stat will be exactly the same, the stat happens in-core dcache
layer, they never go ask the lowlevel fs, so the slwodown at the end
will be comparable for ext3 and reiserfs, the largest time will be spent
always in the lstat and in the gzip compression after you pass the 5000
commit mark.

After it finishes please let us know all the sizes of archive (compared
to 450M of _uncompressed_ bkcvs) and the time tla takes for every
checkin near the 12000 point. You can trivially measure that with
"strace -t -p pidof cscvs python script" when you're at around 10000
commits. You've to measure how long it takes for the wait4 to return.

NOTE: the bkcvs is really a cheating a bit, since all big merges from
other trees showup as a single patchset due the linearization of the
tree, real life linux with arch replacing bitkeeper would involve lots
more patchsets than what you can find now in bkcvs, but if we can handle
bkcvs at 13000 patchsets I don't think even doubling the number of
patchsets would be a big problem.

thanks for taking the time for this experiment! This is definitely
worthwhile.

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/