Re: BK->CVS, kernel.bkbits.net

[Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2003@gmx.net>]

Larry McVoy wrote:
> On Wed, Apr 23, 2003 at 05:49:47PM +0200, Carl-Daniel Hailfinger wrote:
> 
> Fast or safe, pick one.  CVS has no integrity check and you will never know

I picked bitkeeper because it is convenient, easy to use, has a
distributed structure and keeps revision history locally.

> [description of feats achieved by integrity checking snipped]
> 
> The BK integrity check will tell you right away if any of your data is bad.

Every once in a while (cron job at night), I do a
bk -r check -ac
According to the man page, that should cover me nicely. Files which
change during a bk pull are checked anyway, so the only possible
corruption remaining undetected for a few hours is corruption in files
which were not modified at all. I just don't see the BIG benefit in
knowing a few hours earlier that an unused file is corrupted.

If corruption does not affect your working set, it is nice to know about
(to get rid of the offending hardware), but it will not harm you
directly. Checking readonly files is a job for cron because it is highly
unlikely that corruption of your on-disk data will happen on read. I'ts
either already corrupt on the platter or not (cabling/RAM etc. issues
aside), READING a sector from disk should NEVER change the contents of
this sector. If it does, you have a much bigger problem.

> *Everyone* hates the check until it saves their butt and then they decide
> it's not such a bad idea.  It's a lot like a seatbelt - you don't like it
> until something goes wrong.

You should introduce periodic checks, then. Data corruption is not a
function of the read count of a specific sector, but of the write count
and/or time. Feel free to point me to contrary evidence, I'm always
willing to learn.

> BK != CVS.  You want fast and loose, by all means, use CVS, that's not our
> intended market and we don't care about fast where fast means bad data.
> 
> 
>>P.S. If anyone knows other speedup tricks for a kernel tree in bk,
>>please tell me.
> 
> 
> Mount the file system with noatime.

Did that already. But thanks for the suggestion anyway.

> Buy enough memory to fit the kernel in memory and on a 1Ghz processor that
> pull will take about 20 seconds.  Even laptop memory is pretty cheap these
> days.  Pricewatch says $80 for .5GB for laptops, that's cheap.

With a upper maximum of 192MB in my laptop (the chipset won't accept
more), I have no choice but to buy a new one or enable partial checks. I
even use ext2 instead of reiser/ext3 on my notebook to save RAM. The
only thing running during a bk pull is XFree86 and fvwm2 as windowmanager.

Unfortunately, I was unable to find a good laptop in the 80$ range;
heck, I would even consider a good used laptop in the 300$ range. And
before you ask: as an university student, I think twice before shelling
out money for a new machine. Maybe that will change if I have gobs of
money available.

Don't understand me wrong, bitkeeper is a tool which has saved me hours
of merging and debugging mismerges, but I'd perefer not to use xiafs
instead of ext2 just to save a couple more kB of RAM to speed up bk.

Regards,
Carl-Daniel

-- 
Carl-Daniel Hailfinger
Xiafs maintainer
More about Xiafs soon at
http://www.hailfinger.org/