The svn server is running what I think is the most up to date version:
Berkeley db 4.2.52 from the default win32 setup package, upgraded from svn
1.0.2 last weekend (the repository is not accessible from outside the 5
people team so the step to 1.0.3 wasn't critical) and Apache 2.0.49. I
heard some previous versions of BDB had issues with multiple cpus. I don't
know if it's entirely fixed, or if windows fs is buggy (duh) under these
conditions for the strict requirements of BDB.
I just finished moving everything to a single CPU box. During the move at
some point I noticed one of my previous 'svnadmin verify' was still frozen
(2-3 hours later), so I killed it. Then, the 'svnadmin recover' finally
kicked in (don't know if it's related to a timeout somewhere, or the verify
that got killed). Note that before launching the verify and/or recover, I
shut down Apache and rebooted the server to make sure no user was connected.
Which leads me to a question: can I trust a database after a 'svnadmin
recover' succeeds, or it is valuable to take back the previous backup?
(which is the safe road I took) I start with the assumption that recover
tools can only check for a defined number of inconsistencies, and that you
can never be sure once you run these tools.
Ben Collins-Sussman wrote:
>I'm seeing a general trend: a lot of users seem to think 'verify' means
>'read and repair'. It doesn't. It just means 'read'. Only the
>'svnadmin recover' command does any repair.
I totally agree with your definition of the feautre, and was expecting
verify to do just that: verify and let me know if something was wrong. If
the verify doesn't tell me something is wrong, I don't have too much hope
for the recover. In my case, using svnadmin to verify or check the list of
opened transactions would not return, they would hang for a long time (even
launched right after a fresh reboot).
About what caused the initial problem, I don't know. One user told me he
started to do an update (using TortoiseSvn 1.0.4 built against svn 1.0.2 - I
know the 1.0.5 is out but features are broken and already fixed in the trunk
so they'll wait for 1.0.6) and it never returned anything. I tried to
reproduce it on the dual cpu machine but not luck. We even tried multiple
updates at the same time.
If other people start to report problems using svn on multiple cpus w2k
machines, then there is a pattern. Without that... hard to tell.
Brice.
-----Original Message-----
From: Erik Huelsmann [mailto:e.huelsmann@gmx.net]
Sent: Monday, May 24, 2004 13:24
To: Brice Dardel
Cc: users@subversion.tigris.org
Subject: RE: Berkeley DB error + svnadmin freezes
Which version of BDB are you using? Some versions of it are known to have
trouble wich dual cpu setups.
> Yes I tried svnrecover. It doesn't output anything after "Please wait;
> recovering the repository may take some time...". I let it run for almost
> 40 minutes (I disabled one cpu, now it's a single P3 600 Mhz, operating on
> a
> 70 Mb repository), and the cpu is used at 0%. All the svn command freezes
> and don't complete (I've shut down apache and that's the only way the
> users
> got there so I'm sure to be the only one accessing it).
>
> It's probably not even a direct svn bug but it sounds to me like the
> berkeley db is in a bad shape, and the cause is potentially the same that
> this user below experienced: dual cpus and/or raid.
Erik.
>
>
>
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Monday, May 24, 2004 12:46
> To: Brice Dardel
> Cc: users@subversion.tigris.org
> Subject: RE: Berkeley DB error + svnadmin freezes
>
> On Mon, 2004-05-24 at 12:42, Brice Dardel wrote:
> > I just encountered the same error as described by Stefan below. I have
> a
> > few repositories on the machine, one of them when I do a "svnadmin
> verify"
> > does:
> >
> > svn: Berkeley DB error while opening 'revisions' table for filesystem
> > marketing/
> > db:
> > Not enough space
>
> Did you run 'svnadmin recover'?
>
> 'svnadmin verify' is equivalent to checking out (reading) every single
> revision. If other read-operations fail, so will 'verify'.
>
> I'm seeing a general trend: a lot of users seem to think 'verify' means
> 'read and repair'. It doesn't. It just means 'read'. Only the
> 'svnadmin recover' command does any repair.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 25 02:29:00 2004