Re: [PATCH] 2.6.0 - Watchdog patches (BK consistency checks)

[Andy Isaacson]

On Tue, Dec 30, 2003 at 08:36:15AM -0500, Ed Tomlinson wrote:
> On December 29, 2003 07:49 pm, Matthias Andree wrote:
> > Well, talk about FAAAAAAST drives (10,025/min SCSI kind) unless you have
> > time to waste on all those BK consistency checks (which are, of course,
> > what #3 is all about).
> >
> > Or am I missing some obvious short cut?
> 
> Is there a way to tell BK when to do consistency checks?  Here they
> easily take 15-20 min each time.  I would love to be able to tell BK
> to defer these checks.

The consistency check definitely should not take 15 minutes.  It should
be (much) less than 30 seconds.  What is the hardware you're running on?

I'm running on an Athlon 2 GHz (XP 2400+) with 512MB and a 7200RPM IDE
disk, and I can do a complete clone (with full data copy and consistency
check) of the 2.4 tree in 1:40.  That was with cold caches; with the
sfile copies and "checkout:get", a half-gig isn't enough to cache
everything.  The consistency check is about 19 seconds (bk -r check -acv).

If you keep all your trees on one filesystem, you can use "bk clone -l"
to make hard-links for the s. files.  This means you can create a
complete copy of the tree in about 6 MB, in 40 seconds or so.  BK is
very careful to check the links and break them when necessary.  

To save diskspace, you can turn off "checkout:get", like so:

--- 1.4/BitKeeper/etc/config    Tue Dec 30 12:16:44 2003
+++ edited/BitKeeper/etc/config Tue Dec 30 12:13:53 2003
@@ -3,4 +3,3 @@
 logging: logging@xxxxxxxxxxxxxxx
 email: torvalds@xxxxxxxxxxxxx
 [davem]checkout:none
-[]checkout:get

(Or, add a [$USER]checkout:none line if that is easier.)

If the consistency check is problematic, let's fix that problem -- don't
turn it off, it's valuable.  It's found IDE corruption, it's found BK
bugs, it's found users who move s. files around behind BK's back.

-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/