You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brice Dardel <bd...@plexsci.com> on 2004/05/24 17:42:43 UTC
RE: Berkeley DB error + svnadmin freezes
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
There is 17 Gb free, the repository is 35 Mb.
On another repository (same machine), if I do svnadmin verify, or svnadmin
lstxns to see the opened transactions, absolutely nothing happens. Even
after a reboot.
I think what triggers the bug is either the raid drives or the dual cpu.
I have daily backups, so I can recover a backup from last night and reapply
the changes. I'll also move that to a single cpu machine, with a single
hard drive.
RAID drive
dual CPU
W2k server SP4
svn 1.0.4
Regards,
Brice.
-----Original Message-----
From: Stefan Pettersson [mailto:stefpet@algonet.se]
Sent: Saturday, May 15, 2004 9:15
To: users@subversion.tigris.org
Subject: RE: Berkeley DB error - Not enough space
> From: Ben Collins-Sussman
>
> > Today one of our dev's reported that he got an error message when
> > doing an
> > update:
> >
> > "Berkeley DB error /path/in/repos - Not enough space" (or similar)
>
> Did the repository run out of disk space? That would be my
> first guess.
No. The server has 690 GB (yes, 4x250 GB RAID 5) free space on that disk.
- stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Berkeley DB error + svnadmin freezes
Posted by Hernan Martinez Foffani <he...@ecc.es>.
Brice Dardel escribio:
> 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.
You may try db_recover.exe. It's almost the same as 'svnadmin recover'
but it can give some more output.
You'll find it in the download page of the Subversion site as bdb tools.
> If other people start to report problems using svn on multiple cpus
> w2k machines, then there is a pattern. Without that... hard to tell.
I got a broken database some days ago. I forgot to tell the list that
we have Apache/Subversion running in a dual cpu box, failing to realize
that it may matter. Follows the output of db_recover:
db_recover: DB_ENV->log_flush: LSN of 112/193694 past current end-of-log of
112/
124415
db_recover: Database environment corrupt; the wrong log files may have been
remo
ved or incompatible database files imported from another environment
db_recover: strings: unable to flush page: 0
db_recover: txn_checkpoint: failed to flush the buffer cache Invalid
argument
db_recover: PANIC: Invalid argument
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
There were *no* manually removed logs nor incompatible imports. We *did*
have
an energy blackout, though.
Environment: Windows 2000 professional, Apache 2.0.48, Subversion 1.0.1
(berkeley db 4.2.52), dual cpu box.
After the blackout every commit hang. Same thing with 'svnadmin verify'.
-Hernan.
________________________________________________________________________________________
Este mensaje ha sido analizado y protegido por la tecnologia antivirus www.trendmicro.es
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Berkeley DB error + svnadmin freezes
Posted by Brice Dardel <bd...@plexsci.com>.
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
RE: Berkeley DB error + svnadmin freezes
Posted by Erik Huelsmann <e....@gmx.net>.
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
RE: Berkeley DB error + svnadmin freezes
Posted by Stefan Pettersson <st...@algonet.se>.
> 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.
I'm that user. In my case only one user (out of 15) did get this message
while doing an update/commit/something only once. Then everything went back
to normal and since then we've not experienced this problem. I.e in my case
it seems more likely to have been a client issue rather than something with
the Subversion repository on the server (RAID 5 but no dual CPU).
- stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Berkeley DB error + svnadmin freezes
Posted by Brice Dardel <bd...@plexsci.com>.
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.
-----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
RE: Berkeley DB error + svnadmin freezes
Posted by Ben Collins-Sussman <su...@collab.net>.
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