You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by jc...@apache.org on 2016/06/26 22:23:47 UTC
svn commit: r1750262 - /subversion/site/publish/faq.html
Author: jcorvel
Date: Sun Jun 26 22:23:47 2016
New Revision: 1750262
URL: http://svn.apache.org/viewvc?rev=1750262&view=rev
Log:
FAQ: move BDB questions to Deprecated FAQ.
* site/publish/faq.html
(bdb-questions): New section in Deprecated FAQ.
(divining-bdb-version,
bdblogs,
stuck-bdb-repos,
bdb-recovery,
bdb-cannot-allocate-memory,
db3db4,
redhat-db,
bdb41-tabletype-bug,
bdb43-upgrade): Move these questions to the bdb-questions section.
Modified:
subversion/site/publish/faq.html
Modified: subversion/site/publish/faq.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/faq.html?rev=1750262&r1=1750261&r2=1750262&view=diff
==============================================================================
--- subversion/site/publish/faq.html (original)
+++ subversion/site/publish/faq.html Sun Jun 26 22:23:47 2016
@@ -80,7 +80,6 @@ For older questions, see <a href="#depre
<li><a href="#multi-merge">How do I merge two completely separate repositories?</a></li>
<li><a href="#nfs">Should I store my repository / working copy on a
NFS server?</a></li>
-<li><a href="#bdblogs">Why is my repository taking up so much disk space?</a></li>
<li><a href="#reposperms">How do I set repository permissions correctly?</a></li>
<li><a href="#readonly">Why do read-only operations still need repository write access?</a></li>
<li><a href="#removal">How do I completely remove a file from the repository's history?</a></li>
@@ -124,8 +123,6 @@ what they are, and are not, allowed to a
everything in the repository? Also, how can I make sure that every
new file coming into the repository has these properties?</a></li>
<li><a href="#svn-editor">How do I handle spaces in the editor path?</a></li>
-<li><a href="#divining-bdb-version">How do I determine which version of
-Berkeley DB a repository is using?</a></li>
<li><a href="#website-auto-update">I'm managing a website in my
repository. How can I make the live site automatically update after
every commit?</a></li>
@@ -152,14 +149,6 @@ to FSFS or from FSFS to BDB?</a></li>
<h4>Troubleshooting:</h4>
<ul>
-<li><a href="#stuck-bdb-repos">My repository seems to get stuck all the
- time, giving me errors about needing recovery (DB_RUNRECOVERY).
- What could be the cause?</a></li>
-<li><a href="#bdb-recovery">Every time I try to access
- my repository, the process just hangs. Is my repository
- corrupt?</a></li>
-<li><a href="#bdb-cannot-allocate-memory">My repository keeps giving
- errors saying "Cannot allocate memory". What should I do?</a></li>
<li><a href="#wedged-wc">Every time I try to run a svn
command, it says my working copy is locked. Is my working copy
corrupt?</a></li>
@@ -187,11 +176,6 @@ a <tt>file:</tt> URL?</a></li>
<li><a href="#revert">Why does the <tt>svn revert</tt> require an
explicit target? Why is it not recursive by default? These
behaviors differ from almost all the other subcommands.</a></li>
-<li><a href="#db3db4">When I start Apache, mod_dav_svn complains about
- a "bad database version", that it found db-3.X, rather than
- db-4.X.</a></li>
-<li><a href="#redhat-db">I'm getting "Function not implemented" errors on
- Red Hat 9, and nothing works. How do I fix this?</a></li>
<li><a href="#no-author">Why does SVN log say "(no author)" for files
committed or imported via Apache (ra_dav)?</a></li>
<li><a href="#windows-access-denied">I'm getting occasional "Access Denied"
@@ -218,15 +202,10 @@ a <tt>file:</tt> URL?</a></li>
<li><a href="#plaintext-passwords">Ahhh! I just discovered that my
Subversion client is caching passwords in plain-text on disk!
AHHH!</a></li>
-<li><a href="#bdb41-tabletype-bug">I'm getting the error "svn: bdb: call
- implies an access method which is inconsistent with previous
- calls". How do I fix this?</a></li>
<li><a href="#hotcopy-large-repos">I can't hotbackup my repository, svnadmin
fails on files larger than 2Gb!</a></li>
<li><a href="#hidden-log">I cannot see the log entry for the file
I just committed. Why?</a></li>
-<li><a href="#bdb43-upgrade">After upgrading to Berkeley DB
- 4.3 or later, I'm seeing repository errors.</a></li>
<li><a href="#tiger-apr-0.9.6">Why do I get occasional, seemingly
inconsistent errors when checking out over http:// from a repository
running on MacOS X 10.4 (Tiger)?</a></li>
@@ -1127,61 +1106,6 @@ newer Samba (3.0.6).</p>
</div>
-<div class="h3" id="bdblogs">
-<h3>Why is my repository taking up so much disk space?
- <a class="sectionlink" href="#bdblogs"
- title="Link to this section">¶</a>
-</h3>
-
-<p>The repository stores all your data in a Berkeley DB "environment"
-in the repos/db/ subdirectory. The environment contains a collection
-of tables and bunch of logfiles (log.*). Berkeley DB journals all
-changes made to the tables, so that the tables can be recovered to a
-consistent state in case of interruptions (<a
-href="#bdb-recovery">more info</a>).</p>
-
-<p>The logfiles will grow forever, eating up disk space, unless you,
-(as the repository administrator) do something about it. At any given
-moment, Berkeley DB is only using a few logfiles actively (see <a
-href="http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=15194"
->this post</a> and its associated thread); the rest can be safely
-deleted. If you keep all the logfiles around forever, then in theory
-Berkeley DB can replay every change to your repository from the day it
-was born. But in practice, if you're making backups, it's probably
-not worth the cost in disk space.</p>
-
-<p>Use <code>svnadmin</code> to see
-which log files can be deleted. You may want a cron job to do this.</p>
-
-<pre>
-$ svnadmin list-unused-dblogs /repos
-/repos/db/log.000003
-/repos/db/log.000004
-[...]
-
-$ svnadmin list-unused-dblogs /repos | xargs rm
-# disk space reclaimed!
-</pre>
-
-<p>You could instead use Berkeley DB's <code>db_archive</code> command:</p>
-
-<pre>
-$ db_archive -a -h /repos/db | xargs rm
-# disk space reclaimed!
-</pre>
-
-<p>See also <code>svnadmin hotcopy</code> or <code>hotbackup.py</code>.</p>
-
-<p><strong>Note:</strong> If you use Berkeley DB 4.2, Subversion will
-create new repositories with automatic log file removal enabled. You
-can change this by passing the <code>--bdb-log-keep</code> option to
-<code>svnadmin create</code>. Refer to the section about the <a
-href="http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE">
-<code>DB_LOG_AUTOREMOVE</code></a> flag in the Berkeley DB manual.</p>
-
-</div>
-
-
<div class="h3" id="reposperms">
<h3>How do I set repository
permissions correctly?
@@ -2074,43 +1998,6 @@ with Subversion it is best to use the SV
</div>
-<div class="h3" id="divining-bdb-version">
-<h3>How do I determine which version of
-Berkeley DB a repository is using?
- <a class="sectionlink" href="#divining-bdb-version"
- title="Link to this section">¶</a>
-</h3>
-
-<p>If it's a live repository, then the easy answer is "Whatever
-version of Berkeley DB you have installed". If, however, it is a
-repository from a backup, or some unknown source, and you have no idea
-which version of Berkeley DB it was made with, here's how you find
-out:</p>
-
-<p>Run some command to view the two 4-byte integers at offsets 12 and
-16 (decimal) in the highest-numbered db/log.* file in the repository.
-Here is an example using GNU od: "<tt>od -j12 -N8 -tx4
-log.<i><number></i></tt>". Here is an example using Mac OS X
-hexdump: "<tt>hexdump -s12 -n8 -x log.<i><number></i></tt>".
-The first integer should be the magic number 0x00040988, which
-identifies the file as a Berkeley DB logfile. The second number is
-the log format version
-- match it to a Berkeley DB version using the table below:</p>
-
-<table border="1" cellspacing="2" cellpadding="2">
- <tr><th>Log format version</th><th>Berkeley DB version</th></tr>
- <tr><td>5 (0x00000005)</td><td>4.0</td></tr>
- <tr><td>7 (0x00000007)</td><td>4.1</td></tr>
- <tr><td>8 (0x00000008)</td><td>4.2</td></tr>
- <tr><td>10 (0x0000000a)</td><td>4.3</td></tr>
- <tr><td>11 (0x0000000b)</td><td>4.4</td></tr>
- <tr><td>12 (0x0000000c)</td><td>4.5</td></tr>
- <tr><td>13 (0x0000000d)</td><td>4.6</td></tr>
-</table>
-
-</div>
-
-
<div class="h3" id="website-auto-update">
<h3>I'm managing a website in my
repository. How can I make the live site automatically update after
@@ -2542,272 +2429,87 @@ href="http://svnbook.red-bean.com/nightl
<p/>
-<div id="permissions"></div>
-<div class="h3" id="stuck-bdb-repos">
-<h3>My repository seems to get stuck all the
-time, giving me errors about needing recovery (DB_RUNRECOVERY). What
-could be the cause?
- <a class="sectionlink" href="#stuck-bdb-repos"
+<div class="h3" id="wedged-wc">
+<h3>Every time I try to run a svn command, it says my
+working copy is locked. Is my working copy corrupt?
+ <a class="sectionlink" href="#wedged-wc"
title="Link to this section">¶</a>
</h3>
-<p>The Berkeley DB database in your repository is sensitive to
-interruptions. If a process accessing the database exits without
-"cleanly" closing the environment, then the database is left in an
-inconsistent state. Common causes of this include:</p>
-
-<ul>
- <li>the process exiting when it hits a permission problem</li>
- <li>the process crashing/segfaulting</li>
- <li>the process being forcibly killed</li>
- <li>running out of disk space</li>
-</ul>
-
-<p>For most of these cases, you should run "svnadmin recover", which
-rewinds the repository back to a consistent state; see <a
-href="#bdb-recovery">this question</a> for details. Note that running
-out of disk space, combined with frequent checkouts or updates, can
-cause the repository to crash in a way where recovery is not possible
-(so keep backups).</p>
-
-<p>Segfaults, forced killings, and running out of disk space are
-pretty rare. Permission problems are far more common: one process
-accesses the repository and accidentally changes ownership or
-permissions, then another process tries to access and chokes on the
-permissions.</p>
+<p>
+Your working copy is not corrupt, nor is your data lost. Subversion's
+working copy is a journaling system, meaning that it logs everything it
+is about to do before it does so. If the svn client program is
+interrupted violently (segfault or killed, not with Control-C), then
+one or more lockfiles are left behind, along with logfiles describing
+unfinished business. (The `svn status' command will show an 'L' next
+to locked directories.) Any other process that attempts to access the
+working copy will fail when it sees the locks. To awaken your working
+copy, you need to tell the svn client to finish the work. Simply
+run:</p>
-<p>The best way to prevent this is to get your repository permissions
-and ownership set up correctly. See <a href="#reposperms">here</a>
-for our recommendations.</p>
+<pre>
+svn cleanup working-copy
+</pre>
</div>
-<div id="wedged-repos"></div>
-<div class="h3" id="bdb-recovery">
-<h3>Every time I try to access my repository, the
-process just hangs. Is my repository corrupt?
- <a class="sectionlink" href="#bdb-recovery"
+<div class="h3" id="wc-out-of-date">
+<h3>I'm trying to commit, but Subversion says my
+working copy is out of date?
+ <a class="sectionlink" href="#wc-out-of-date"
title="Link to this section">¶</a>
</h3>
-<p>
-Your repository is not corrupt, nor is your data lost. If your process
-accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or
-if you access a `file://' URL), then it's using Berkeley DB to access
-your data. Berkeley DB is a journaling system, meaning that it logs
-everything it is about to do before it does so. If your process is
-interrupted (Control-C, or segfault), then a lockfile is left behind,
-along with a logfile describing unfinished business. Any other
-process that attempts to access the database will just hang, waiting
-for the lockfile to disappear. To awaken your repository, you need to
-ask Berkeley DB to either finish the work, or rewind the database to a
-previous state that is known to be consistent.</p>
+<p>Three kinds of situation that can cause this:</p>
-<p><b><span style="color: red">WARNING:</span> you can seriously corrupt
-your repository if you run recover and another process accesses the
-repository.</b></p>
+<ol>
-<p>Make absolutely sure you disable all access to the repository before
-doing this (by shutting down Apache, removing executable permissions from
-'svn'). Make sure you run this command as the user that owns and manages
-the database, and not as root, else it will leave root-owned files in the
-db directory which cannot be opened by the non-root user that manages the
-database, which is typically either you or your Apache process. Also be
-sure to have the correct umask set when you run recover, since failing to
-do so will lock out users that are in the group allowed to access the
-repository.</p>
+<li><p>Debris from a failed commit is littering your working copy.</p>
-<p>
-Simply run:</p>
+ <p>You may have had a commit that went sour between the time the
+ new revision was added in the server and the time your client
+ performed its post-commit admin tasks (including refreshing your
+ local text-base copy). This might happen for various reasons
+ including (rarely) problems in the database back end or (more
+ commonly) network dropouts at exactly the wrong time.</p>
-<pre>
- svnadmin recover /path/to/repos
-</pre>
+ <p>If this happens, it's possible that you have already committed
+ the very changes you are trying now to commit. You can use 'svn
+ log -rHEAD' to see if your supposed-failed commit actually
+ succeeded. If it did, run 'svn revert' to revert your local
+ changes, then run 'svn update' to get your own changes back from the
+ server. (Note that only 'svn update' brings your local copies
+ up-to-date; revert doesn't do that.)</p>
+</li>
-<p>Once the command has completed, check the permissions in the
-<code>db</code> directory of the repository.</p>
+<li><p>Mixed revisions.</p>
-<p>Sometimes "svnadmin recover" doesn't work. You may see it
-give errors like this:</p>
+ <p>When Subversion commits, the client only bumps the revision
+ numbers of the nodes the commit touches, not all nodes in the
+ working copy. This means that in a single working copy, the
+ files and subdirectories might be at different revisions,
+ depending on when you last committed them. In certain operations
+ (for example, directory property modifications), if the
+ repository has a more recent version of the node, the commit will
+ be rejected, to prevent data loss. See <a
+ href="http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.limits"
+ >Mixed revisions have limitations</a> in the <a
+ href="http://svnbook.red-bean.com/">Version Control with
+ Subversion</a> book for details.</p>
-<pre>
- Repository lock acquired.
- Please wait; recovering the repository may take some time...
- svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
- svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass
- svnadmin: bdb: PANIC: No such file or directory
- svnadmin: bdb: PANIC: fatal region error detected; run recovery
-</pre>
+ <p>You can fix the problem by running 'svn update' in the working
+ copy.</p>
+</li>
-<p>or like this:</p>
-
-<pre>
- Repository lock acquired.
- Please wait; recovering the repository may take some time...
- svn: DB_RUNRECOVERY: Fatal error, run database recovery
- svn: bdb: DB_ENV->log_flush: LSN of 115/802071 past current end-of-log
- of 115/731460
- svn: bdb: Database environment corrupt; the wrong log files may have
- been removed or incompatible database files imported from another
- environment
- [...]
- svn: bdb: changes: unable to flush page: 0
- svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument
- svn: bdb: PANIC: Invalid argument
- svn: bdb: PANIC: fatal region error detected; run recovery
- svn: bdb: PANIC: fatal region error detected; run recovery
- [...]
-</pre>
-
-<p>In that case, try Berkeley DB's native <b>db_recover</b> utility
-(see <a href="http://www.oracle.com/technology/documentation/berkeley-db/db/utility/db_recover.html"
->db_recover documentation</a>). It
-usually lives in a "bin/" subdirectory of the Berkeley DB installation,
-for example if you installed Berkeley DB from source, it might be
-<tt>/usr/local/BerkeleyDB.4.2/bin/db_recover</tt>; or on systems where
-Berkeley DB comes prepackaged it might just be
-<tt>/usr/bin/db_recover</tt>. If you have multiple versions of
-Berkeley DB installed, make sure that the version of db_recover you
-use matches the version of Berkeley DB with which your repository was
-created.</p>
-
-<p>Run db_recover with the "-c" ("catastrophic recovery") flag. You
-can also add "-v" for verbosity, and "-h" with an argument telling it
-what db environment to recover (so you don't have to cd into that
-directory). Thus:</p>
-
-<pre>
- db_recover -c -v -h /path/to/repos/db
-</pre>
-
-<p>Run this command as the same user that owns the repository, and
-again, make absolutely sure that no other processes are accessing the
-repository while you do this (e.g., shut down svnserve or Apache).</p>
-
-</div>
-
-
-<div class="h3" id="bdb-cannot-allocate-memory">
-<h3>My repository keeps giving errors saying "Cannot allocate memory".
- What should I do?
- <a class="sectionlink" href="#bdb-cannot-allocate-memory"
- title="Link to this section">¶</a>
-</h3>
-
-<p>If you're using http:// access, "<b>Cannot allocate memory</b>"
-errors show up in the httpd error log and look something like
-this:</p>
-
-<blockquote>
-<pre>
-[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (20014)
-Error string not specified yet: Berkeley DB error while opening
-'strings' table for filesystem /usr/local/svn/repositories/svn/db:
-Cannot allocate memory
-[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
-Could not fetch resource information. [500, #0]
-[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
-Could not open the requested SVN filesystem [500, #160029]
-[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (17)
-File exists: Could not open the requested SVN filesystem [500, #160029]
-</pre>
-</blockquote>
-
-<p>It usually means that a Berkeley DB repository has run out of
-database locks (this does not happen with FSFS repositories). It
-shouldn't happen in the course of normal operations, but if it does,
-the solution is to run database recovery as described <a
-href="#bdb-recovery">here</a>. If it happens often, you probably need
-to raise the default lock parameters (<tt>set_lk_max_locks</tt>,
-<tt>set_lk_max_lockers</tt>, and <tt>set_lk_max_objects</tt>) in the
-db/DB_CONFIG file. When changing DB_CONFIG in an existing repository,
-remember to run recovery afterwards.</p>
-
-</div>
-
-
-<div class="h3" id="wedged-wc">
-<h3>Every time I try to run a svn command, it says my
-working copy is locked. Is my working copy corrupt?
- <a class="sectionlink" href="#wedged-wc"
- title="Link to this section">¶</a>
-</h3>
-
-<p>
-Your working copy is not corrupt, nor is your data lost. Subversion's
-working copy is a journaling system, meaning that it logs everything it
-is about to do before it does so. If the svn client program is
-interrupted violently (segfault or killed, not with Control-C), then
-one or more lockfiles are left behind, along with logfiles describing
-unfinished business. (The `svn status' command will show an 'L' next
-to locked directories.) Any other process that attempts to access the
-working copy will fail when it sees the locks. To awaken your working
-copy, you need to tell the svn client to finish the work. Simply
-run:</p>
-
-<pre>
-svn cleanup working-copy
-</pre>
-
-</div>
-
-
-<div class="h3" id="wc-out-of-date">
-<h3>I'm trying to commit, but Subversion says my
-working copy is out of date?
- <a class="sectionlink" href="#wc-out-of-date"
- title="Link to this section">¶</a>
-</h3>
-
-<p>Three kinds of situation that can cause this:</p>
-
-<ol>
-
-<li><p>Debris from a failed commit is littering your working copy.</p>
-
- <p>You may have had a commit that went sour between the time the
- new revision was added in the server and the time your client
- performed its post-commit admin tasks (including refreshing your
- local text-base copy). This might happen for various reasons
- including (rarely) problems in the database back end or (more
- commonly) network dropouts at exactly the wrong time.</p>
-
- <p>If this happens, it's possible that you have already committed
- the very changes you are trying now to commit. You can use 'svn
- log -rHEAD' to see if your supposed-failed commit actually
- succeeded. If it did, run 'svn revert' to revert your local
- changes, then run 'svn update' to get your own changes back from the
- server. (Note that only 'svn update' brings your local copies
- up-to-date; revert doesn't do that.)</p>
-</li>
-
-<li><p>Mixed revisions.</p>
-
- <p>When Subversion commits, the client only bumps the revision
- numbers of the nodes the commit touches, not all nodes in the
- working copy. This means that in a single working copy, the
- files and subdirectories might be at different revisions,
- depending on when you last committed them. In certain operations
- (for example, directory property modifications), if the
- repository has a more recent version of the node, the commit will
- be rejected, to prevent data loss. See <a
- href="http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.limits"
- >Mixed revisions have limitations</a> in the <a
- href="http://svnbook.red-bean.com/">Version Control with
- Subversion</a> book for details.</p>
-
- <p>You can fix the problem by running 'svn update' in the working
- copy.</p>
-</li>
-
-<li><p>You might be genuinely out of date — that is,
- you're trying to commit a change to a file that has been changed
- by someone else since you last updated your copy of that file.
- Again, 'svn update' is the way to fix this.</p>
-</li>
-</ol>
-</div>
+<li><p>You might be genuinely out of date — that is,
+ you're trying to commit a change to a file that has been changed
+ by someone else since you last updated your copy of that file.
+ Again, 'svn update' is the way to fix this.</p>
+</li>
+</ol>
+</div>
<div class="h3" id="obstructed-add">
@@ -3038,70 +2740,6 @@ forever.</p>
-<div class="h3" id="db3db4">
-<h3>When I start Apache, mod_dav_svn complains about
- a "bad database version", that it found db-3.X, rather than
- db-4.X.
- <a class="sectionlink" href="#db3db4"
- title="Link to this section">¶</a>
-</h3>
-
-<p>Your apr-util linked against DB-3, and svn linked against DB-4.
-Unfortunately, the DB symbols aren't different. When mod_dav_svn is
-loaded into Apache's process-space, it ends up resolving the
-symbol names against apr-util's DB-3 library.</p>
-
-<p>The solution is to make sure apr-util compiles against DB-4. You
-can do this by passing specific switches to either apr-util's or
-apache's configure: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".</p>
-
-</div>
-
-
-
-<div class="h3" id="redhat-db">
-<h3>I'm getting "Function not implemented" errors on Red Hat
-9, and nothing works. How do I fix this?
- <a class="sectionlink" href="#redhat-db"
- title="Link to this section">¶</a>
-</h3>
-
-<p>This is not really a problem with Subversion, but it often affects
-Subversion users.</p>
-
-<p>Red Hat 9 and Fedora ship with a Berkeley DB library that relies on
-the kernel support for NPTL (the Native Posix Threads Library).</p>
-
-<p>The kernels that Red Hat provides have this support built in, but if you
-compile your own kernel, then you may well not have the NPTL support. If that
-is the case, then you will see errors like this:</p>
-<blockquote><pre>
-svn: Berkeley DB error
-svn: Berkeley DB error while creating environment for filesystem tester/db:
-Function not implemented
-</pre></blockquote>
-<p>This can be fixed in one of several ways:</p>
-<ul>
-<li>Rebuild Berkeley DB for the kernel you're using.</li>
-<li>Use a Red Hat 9 kernel.</li>
-<li>Apply the NPTL patches to the kernel you're using.</li>
-<li>Use a recent (2.5.x) kernel with the NPTL support included.</li>
-<li>Check if environment variable <code>LD_ASSUME_KERNEL</code> is set
- to <code>2.2.5</code>, and if so, unset it before starting
- Subversion (Apache). (You usually would set this variable to run
- Wine or Winex on Red Hat 9)</li>
-</ul>
-<p>To use the NPTL version of Berkeley DB you also need to use a glibc
-library with NPTL support, which probably means the i686 version. See
-<a
-href="http://svn.haxx.se/users/archive-2004-03/0488.shtml">
-http://svn.haxx.se/users/archive-2004-03/0488.shtml
-</a> for details.
-</p>
-
-</div>
-
-
<div class="h3" id="no-author">
<h3>Why does SVN log say "(no author)" for files
committed or imported via Apache (ra_dav)?
@@ -3429,64 +3067,21 @@ patches to the dev@ list.</p>
</div>
-<div class="h3" id="bdb41-tabletype-bug">
-<h3>I'm getting the error "svn: bdb: call
- implies an access method which is inconsistent with previous
- calls". How do I fix this?
- <a class="sectionlink" href="#bdb41-tabletype-bug"
+<div class="h3" id="hotcopy-large-repos">
+<h3>I can't hotbackup my repository,
+ svnadmin fails on files larger than 2Gb!
+ <a class="sectionlink" href="#hotcopy-large-repos"
title="Link to this section">¶</a>
</h3>
-<p>Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0
-and 4.2 are better. This error message is a symptom of one unique way
-in which 4.1 will sometimes break.</p>
+<p>Early versions of APR on its 0.9 branch, which Apache 2.0.x and
+Subversion 1.x use, have no support for copying large files (2Gb+).
+A fix which solves the 'svnadmin hotcopy' problem has been applied and
+is included in APR 0.9.5+ and Apache 2.0.50+. The fix doesn't work
+on all platforms, but works on Linux.
+</p>
-<p>The problem is that the database format field for one of the tables
-that make up a Subversion repository using the Berkeley DB backend has
-become corrupted. For unknown reasons, this is almost always the
-'copies' table, which switches from the 'btree' type to the 'recno'
-type. Simple recovery procedures are outlined below - if they do not
-succeed, you should contact the Subversion Users <a
- href="mailto:users@subversion.apache.org">mailing list</a>.</p>
-
-<ul>
- <li>Ensure that no other processes will attempt to access your
- repository.</li>
- <li>Now, <b>back up your repository</b> to a tar or zip file or
- similar.</li>
- <li>Change to the <tt>db</tt> subdirectory of your repository.</li>
- <li><tt>rm __db.* log.*</tt></li>
- <li><tt>db_dump -p -r copies > copies.dump</tt></li>
- <li>Now edit <tt>copies.dump</tt>. In the section near the top,
- change "<tt>type=recno</tt>" to "<tt>type=btree</tt>", and delete
- the line beginning "<tt>re_len=</tt>".</li>
- <li><tt>rm copies</tt></li>
- <li><tt>db_load copies < copies.dump</tt></li>
- <li><tt>svnadmin dump .. > ../../my-recovered.svndump</tt></li>
- <li>Now create a new repository, reload the dump file just produced,
- and copy across any custom hooks or configuration. Verify that the
- highest revision number in the new repository is what you think it
- should be.</li>
-</ul>
-
-</div>
-
-
-<div class="h3" id="hotcopy-large-repos">
-<h3>I can't hotbackup my repository,
- svnadmin fails on files larger than 2Gb!
- <a class="sectionlink" href="#hotcopy-large-repos"
- title="Link to this section">¶</a>
-</h3>
-
-<p>Early versions of APR on its 0.9 branch, which Apache 2.0.x and
-Subversion 1.x use, have no support for copying large files (2Gb+).
-A fix which solves the 'svnadmin hotcopy' problem has been applied and
-is included in APR 0.9.5+ and Apache 2.0.50+. The fix doesn't work
-on all platforms, but works on Linux.
-</p>
-
-</div>
+</div>
<div class="h3" id="hidden-log">
@@ -3546,53 +3141,6 @@ is still at r7, you do not see the log i
</div>
-<div class="h3" id="bdb43-upgrade">
-<h3>After upgrading to Berkeley DB
- 4.3 or later, I'm seeing repository errors.
- <a class="sectionlink" href="#bdb43-upgrade"
- title="Link to this section">¶</a>
-</h3>
-
-<p>Prior to Berkeley DB 4.3, <tt>svnadmin recover</tt> worked to upgrade a
-Berkeley DB repository in-place. However, due to a change in the behaviour
-of Berkeley DB in version 4.3, this now fails.</p>
-
-<p>Use this procedure to upgrade your repository in-place to Berkeley
-DB 4.3 or later:</p>
-
-<ul>
-
-<li>Make sure no process is accessing the repository (stop
-Apache, svnserve, restrict access via file://, svnlook, svnadmin,
-etc.)</li>
-
-<li>Using an <i>older</i> <tt>svnadmin</tt> binary (that is, linked to
- an older Berkeley DB):
-
- <ol>
-
- <li>Recover the
- repository: '<tt>svnadmin recover /path/to/repository</tt>'</li>
-
- <li>Make a backup of the repository.</li>
-
- <li>Delete all unused log files. You can see them by running
- '<tt>svnadmin list-unused-dblogs /path/to/repeository</tt>'</li>
-
- <li>Delete the shared-memory files. These are files in the
- repository's <tt>db/</tt> directory, of the form <tt>__db.00*</tt></li>
-
- </ol>
-</li>
-
-</ul>
-
-
-<p>The repository is now usable by Berkeley DB 4.3.</p>
-
-</div>
-
-
<div class="h3" id="tiger-apr-0.9.6">
<h3>Why do I get occasional, seemingly inconsistent errors when checking
out over http:// from a repository running on MacOS X 10.4 (Tiger)?
@@ -4675,6 +4223,31 @@ a lower score.
server sometimes seems to send out corrupted data. Can this really be
happening?</a></li>
</ul>
+
+<h4>BDB questions:</h4>
+<ul>
+<li><a href="#divining-bdb-version">How do I determine which version of
+Berkeley DB a repository is using?</a></li>
+<li><a href="#bdblogs">Why is my repository taking up so much disk space?</a></li>
+<li><a href="#stuck-bdb-repos">My repository seems to get stuck all the
+ time, giving me errors about needing recovery (DB_RUNRECOVERY).
+ What could be the cause?</a></li>
+<li><a href="#bdb-recovery">Every time I try to access
+ my repository, the process just hangs. Is my repository
+ corrupt?</a></li>
+<li><a href="#bdb-cannot-allocate-memory">My repository keeps giving
+ errors saying "Cannot allocate memory". What should I do?</a></li>
+<li><a href="#db3db4">When I start Apache, mod_dav_svn complains about
+ a "bad database version", that it found db-3.X, rather than
+ db-4.X.</a></li>
+<li><a href="#redhat-db">I'm getting "Function not implemented" errors on
+ Red Hat 9, and nothing works. How do I fix this?</a></li>
+<li><a href="#bdb41-tabletype-bug">I'm getting the error "svn: bdb: call
+ implies an access method which is inconsistent with previous
+ calls". How do I fix this?</a></li>
+<li><a href="#bdb43-upgrade">After upgrading to Berkeley DB
+ 4.3 or later, I'm seeing repository errors.</a></li>
+</ul>
</div>
<hr/>
@@ -4704,11 +4277,451 @@ sorts of information about that Service
</div>
+</div>
+
+
+<div class="h2" id="bdb-questions">
+<h2>BDB questions:
+ <a class="sectionlink" href="#bdb-questions"
+ title="Link to this section">¶</a>
+</h2>
+
+<div class="h3" id="divining-bdb-version">
+<h3>How do I determine which version of
+Berkeley DB a repository is using?
+ <a class="sectionlink" href="#divining-bdb-version"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>If it's a live repository, then the easy answer is "Whatever
+version of Berkeley DB you have installed". If, however, it is a
+repository from a backup, or some unknown source, and you have no idea
+which version of Berkeley DB it was made with, here's how you find
+out:</p>
+
+<p>Run some command to view the two 4-byte integers at offsets 12 and
+16 (decimal) in the highest-numbered db/log.* file in the repository.
+Here is an example using GNU od: "<tt>od -j12 -N8 -tx4
+log.<i><number></i></tt>". Here is an example using Mac OS X
+hexdump: "<tt>hexdump -s12 -n8 -x log.<i><number></i></tt>".
+The first integer should be the magic number 0x00040988, which
+identifies the file as a Berkeley DB logfile. The second number is
+the log format version
+- match it to a Berkeley DB version using the table below:</p>
+
+<table border="1" cellspacing="2" cellpadding="2">
+ <tr><th>Log format version</th><th>Berkeley DB version</th></tr>
+ <tr><td>5 (0x00000005)</td><td>4.0</td></tr>
+ <tr><td>7 (0x00000007)</td><td>4.1</td></tr>
+ <tr><td>8 (0x00000008)</td><td>4.2</td></tr>
+ <tr><td>10 (0x0000000a)</td><td>4.3</td></tr>
+ <tr><td>11 (0x0000000b)</td><td>4.4</td></tr>
+ <tr><td>12 (0x0000000c)</td><td>4.5</td></tr>
+ <tr><td>13 (0x0000000d)</td><td>4.6</td></tr>
+</table>
+
+</div>
+
+
+<div class="h3" id="bdblogs">
+<h3>Why is my repository taking up so much disk space?
+ <a class="sectionlink" href="#bdblogs"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>The repository stores all your data in a Berkeley DB "environment"
+in the repos/db/ subdirectory. The environment contains a collection
+of tables and bunch of logfiles (log.*). Berkeley DB journals all
+changes made to the tables, so that the tables can be recovered to a
+consistent state in case of interruptions (<a
+href="#bdb-recovery">more info</a>).</p>
+
+<p>The logfiles will grow forever, eating up disk space, unless you,
+(as the repository administrator) do something about it. At any given
+moment, Berkeley DB is only using a few logfiles actively (see <a
+href="http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=15194"
+>this post</a> and its associated thread); the rest can be safely
+deleted. If you keep all the logfiles around forever, then in theory
+Berkeley DB can replay every change to your repository from the day it
+was born. But in practice, if you're making backups, it's probably
+not worth the cost in disk space.</p>
+
+<p>Use <code>svnadmin</code> to see
+which log files can be deleted. You may want a cron job to do this.</p>
+
+<pre>
+$ svnadmin list-unused-dblogs /repos
+/repos/db/log.000003
+/repos/db/log.000004
+[...]
+
+$ svnadmin list-unused-dblogs /repos | xargs rm
+# disk space reclaimed!
+</pre>
+
+<p>You could instead use Berkeley DB's <code>db_archive</code> command:</p>
+
+<pre>
+$ db_archive -a -h /repos/db | xargs rm
+# disk space reclaimed!
+</pre>
+
+<p>See also <code>svnadmin hotcopy</code> or <code>hotbackup.py</code>.</p>
+
+<p><strong>Note:</strong> If you use Berkeley DB 4.2, Subversion will
+create new repositories with automatic log file removal enabled. You
+can change this by passing the <code>--bdb-log-keep</code> option to
+<code>svnadmin create</code>. Refer to the section about the <a
+href="http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE">
+<code>DB_LOG_AUTOREMOVE</code></a> flag in the Berkeley DB manual.</p>
</div>
+
+<div id="permissions"></div>
+<div class="h3" id="stuck-bdb-repos">
+<h3>My repository seems to get stuck all the
+time, giving me errors about needing recovery (DB_RUNRECOVERY). What
+could be the cause?
+ <a class="sectionlink" href="#stuck-bdb-repos"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>The Berkeley DB database in your repository is sensitive to
+interruptions. If a process accessing the database exits without
+"cleanly" closing the environment, then the database is left in an
+inconsistent state. Common causes of this include:</p>
+
+<ul>
+ <li>the process exiting when it hits a permission problem</li>
+ <li>the process crashing/segfaulting</li>
+ <li>the process being forcibly killed</li>
+ <li>running out of disk space</li>
+</ul>
+
+<p>For most of these cases, you should run "svnadmin recover", which
+rewinds the repository back to a consistent state; see <a
+href="#bdb-recovery">this question</a> for details. Note that running
+out of disk space, combined with frequent checkouts or updates, can
+cause the repository to crash in a way where recovery is not possible
+(so keep backups).</p>
+
+<p>Segfaults, forced killings, and running out of disk space are
+pretty rare. Permission problems are far more common: one process
+accesses the repository and accidentally changes ownership or
+permissions, then another process tries to access and chokes on the
+permissions.</p>
+
+<p>The best way to prevent this is to get your repository permissions
+and ownership set up correctly. See <a href="#reposperms">here</a>
+for our recommendations.</p>
+
</div>
+
+<div id="wedged-repos"></div>
+<div class="h3" id="bdb-recovery">
+<h3>Every time I try to access my repository, the
+process just hangs. Is my repository corrupt?
+ <a class="sectionlink" href="#bdb-recovery"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>
+Your repository is not corrupt, nor is your data lost. If your process
+accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or
+if you access a `file://' URL), then it's using Berkeley DB to access
+your data. Berkeley DB is a journaling system, meaning that it logs
+everything it is about to do before it does so. If your process is
+interrupted (Control-C, or segfault), then a lockfile is left behind,
+along with a logfile describing unfinished business. Any other
+process that attempts to access the database will just hang, waiting
+for the lockfile to disappear. To awaken your repository, you need to
+ask Berkeley DB to either finish the work, or rewind the database to a
+previous state that is known to be consistent.</p>
+
+<p><b><span style="color: red">WARNING:</span> you can seriously corrupt
+your repository if you run recover and another process accesses the
+repository.</b></p>
+
+<p>Make absolutely sure you disable all access to the repository before
+doing this (by shutting down Apache, removing executable permissions from
+'svn'). Make sure you run this command as the user that owns and manages
+the database, and not as root, else it will leave root-owned files in the
+db directory which cannot be opened by the non-root user that manages the
+database, which is typically either you or your Apache process. Also be
+sure to have the correct umask set when you run recover, since failing to
+do so will lock out users that are in the group allowed to access the
+repository.</p>
+
+<p>
+Simply run:</p>
+
+<pre>
+ svnadmin recover /path/to/repos
+</pre>
+
+<p>Once the command has completed, check the permissions in the
+<code>db</code> directory of the repository.</p>
+
+<p>Sometimes "svnadmin recover" doesn't work. You may see it
+give errors like this:</p>
+
+<pre>
+ Repository lock acquired.
+ Please wait; recovering the repository may take some time...
+ svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
+ svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass
+ svnadmin: bdb: PANIC: No such file or directory
+ svnadmin: bdb: PANIC: fatal region error detected; run recovery
+</pre>
+
+<p>or like this:</p>
+
+<pre>
+ Repository lock acquired.
+ Please wait; recovering the repository may take some time...
+ svn: DB_RUNRECOVERY: Fatal error, run database recovery
+ svn: bdb: DB_ENV->log_flush: LSN of 115/802071 past current end-of-log
+ of 115/731460
+ svn: bdb: Database environment corrupt; the wrong log files may have
+ been removed or incompatible database files imported from another
+ environment
+ [...]
+ svn: bdb: changes: unable to flush page: 0
+ svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument
+ svn: bdb: PANIC: Invalid argument
+ svn: bdb: PANIC: fatal region error detected; run recovery
+ svn: bdb: PANIC: fatal region error detected; run recovery
+ [...]
+</pre>
+
+<p>In that case, try Berkeley DB's native <b>db_recover</b> utility
+(see <a href="http://www.oracle.com/technology/documentation/berkeley-db/db/utility/db_recover.html"
+>db_recover documentation</a>). It
+usually lives in a "bin/" subdirectory of the Berkeley DB installation,
+for example if you installed Berkeley DB from source, it might be
+<tt>/usr/local/BerkeleyDB.4.2/bin/db_recover</tt>; or on systems where
+Berkeley DB comes prepackaged it might just be
+<tt>/usr/bin/db_recover</tt>. If you have multiple versions of
+Berkeley DB installed, make sure that the version of db_recover you
+use matches the version of Berkeley DB with which your repository was
+created.</p>
+
+<p>Run db_recover with the "-c" ("catastrophic recovery") flag. You
+can also add "-v" for verbosity, and "-h" with an argument telling it
+what db environment to recover (so you don't have to cd into that
+directory). Thus:</p>
+
+<pre>
+ db_recover -c -v -h /path/to/repos/db
+</pre>
+
+<p>Run this command as the same user that owns the repository, and
+again, make absolutely sure that no other processes are accessing the
+repository while you do this (e.g., shut down svnserve or Apache).</p>
+
+</div>
+
+
+<div class="h3" id="bdb-cannot-allocate-memory">
+<h3>My repository keeps giving errors saying "Cannot allocate memory".
+ What should I do?
+ <a class="sectionlink" href="#bdb-cannot-allocate-memory"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>If you're using http:// access, "<b>Cannot allocate memory</b>"
+errors show up in the httpd error log and look something like
+this:</p>
+
+<blockquote>
+<pre>
+[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (20014)
+Error string not specified yet: Berkeley DB error while opening
+'strings' table for filesystem /usr/local/svn/repositories/svn/db:
+Cannot allocate memory
+[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
+Could not fetch resource information. [500, #0]
+[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
+Could not open the requested SVN filesystem [500, #160029]
+[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (17)
+File exists: Could not open the requested SVN filesystem [500, #160029]
+</pre>
+</blockquote>
+
+<p>It usually means that a Berkeley DB repository has run out of
+database locks (this does not happen with FSFS repositories). It
+shouldn't happen in the course of normal operations, but if it does,
+the solution is to run database recovery as described <a
+href="#bdb-recovery">here</a>. If it happens often, you probably need
+to raise the default lock parameters (<tt>set_lk_max_locks</tt>,
+<tt>set_lk_max_lockers</tt>, and <tt>set_lk_max_objects</tt>) in the
+db/DB_CONFIG file. When changing DB_CONFIG in an existing repository,
+remember to run recovery afterwards.</p>
+
+</div>
+
+
+<div class="h3" id="db3db4">
+<h3>When I start Apache, mod_dav_svn complains about
+ a "bad database version", that it found db-3.X, rather than
+ db-4.X.
+ <a class="sectionlink" href="#db3db4"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Your apr-util linked against DB-3, and svn linked against DB-4.
+Unfortunately, the DB symbols aren't different. When mod_dav_svn is
+loaded into Apache's process-space, it ends up resolving the
+symbol names against apr-util's DB-3 library.</p>
+
+<p>The solution is to make sure apr-util compiles against DB-4. You
+can do this by passing specific switches to either apr-util's or
+apache's configure: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".</p>
+
+</div>
+
+
+
+<div class="h3" id="redhat-db">
+<h3>I'm getting "Function not implemented" errors on Red Hat
+9, and nothing works. How do I fix this?
+ <a class="sectionlink" href="#redhat-db"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>This is not really a problem with Subversion, but it often affects
+Subversion users.</p>
+
+<p>Red Hat 9 and Fedora ship with a Berkeley DB library that relies on
+the kernel support for NPTL (the Native Posix Threads Library).</p>
+
+<p>The kernels that Red Hat provides have this support built in, but if you
+compile your own kernel, then you may well not have the NPTL support. If that
+is the case, then you will see errors like this:</p>
+<blockquote><pre>
+svn: Berkeley DB error
+svn: Berkeley DB error while creating environment for filesystem tester/db:
+Function not implemented
+</pre></blockquote>
+<p>This can be fixed in one of several ways:</p>
+<ul>
+<li>Rebuild Berkeley DB for the kernel you're using.</li>
+<li>Use a Red Hat 9 kernel.</li>
+<li>Apply the NPTL patches to the kernel you're using.</li>
+<li>Use a recent (2.5.x) kernel with the NPTL support included.</li>
+<li>Check if environment variable <code>LD_ASSUME_KERNEL</code> is set
+ to <code>2.2.5</code>, and if so, unset it before starting
+ Subversion (Apache). (You usually would set this variable to run
+ Wine or Winex on Red Hat 9)</li>
+</ul>
+<p>To use the NPTL version of Berkeley DB you also need to use a glibc
+library with NPTL support, which probably means the i686 version. See
+<a
+href="http://svn.haxx.se/users/archive-2004-03/0488.shtml">
+http://svn.haxx.se/users/archive-2004-03/0488.shtml
+</a> for details.
+</p>
+
+</div>
+
+
+<div class="h3" id="bdb41-tabletype-bug">
+<h3>I'm getting the error "svn: bdb: call
+ implies an access method which is inconsistent with previous
+ calls". How do I fix this?
+ <a class="sectionlink" href="#bdb41-tabletype-bug"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0
+and 4.2 are better. This error message is a symptom of one unique way
+in which 4.1 will sometimes break.</p>
+
+<p>The problem is that the database format field for one of the tables
+that make up a Subversion repository using the Berkeley DB backend has
+become corrupted. For unknown reasons, this is almost always the
+'copies' table, which switches from the 'btree' type to the 'recno'
+type. Simple recovery procedures are outlined below - if they do not
+succeed, you should contact the Subversion Users <a
+ href="mailto:users@subversion.apache.org">mailing list</a>.</p>
+
+<ul>
+ <li>Ensure that no other processes will attempt to access your
+ repository.</li>
+ <li>Now, <b>back up your repository</b> to a tar or zip file or
+ similar.</li>
+ <li>Change to the <tt>db</tt> subdirectory of your repository.</li>
+ <li><tt>rm __db.* log.*</tt></li>
+ <li><tt>db_dump -p -r copies > copies.dump</tt></li>
+ <li>Now edit <tt>copies.dump</tt>. In the section near the top,
+ change "<tt>type=recno</tt>" to "<tt>type=btree</tt>", and delete
+ the line beginning "<tt>re_len=</tt>".</li>
+ <li><tt>rm copies</tt></li>
+ <li><tt>db_load copies < copies.dump</tt></li>
+ <li><tt>svnadmin dump .. > ../../my-recovered.svndump</tt></li>
+ <li>Now create a new repository, reload the dump file just produced,
+ and copy across any custom hooks or configuration. Verify that the
+ highest revision number in the new repository is what you think it
+ should be.</li>
+</ul>
+
+</div>
+
+
+<div class="h3" id="bdb43-upgrade">
+<h3>After upgrading to Berkeley DB
+ 4.3 or later, I'm seeing repository errors.
+ <a class="sectionlink" href="#bdb43-upgrade"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Prior to Berkeley DB 4.3, <tt>svnadmin recover</tt> worked to upgrade a
+Berkeley DB repository in-place. However, due to a change in the behaviour
+of Berkeley DB in version 4.3, this now fails.</p>
+
+<p>Use this procedure to upgrade your repository in-place to Berkeley
+DB 4.3 or later:</p>
+
+<ul>
+
+<li>Make sure no process is accessing the repository (stop
+Apache, svnserve, restrict access via file://, svnlook, svnadmin,
+etc.)</li>
+
+<li>Using an <i>older</i> <tt>svnadmin</tt> binary (that is, linked to
+ an older Berkeley DB):
+
+ <ol>
+
+ <li>Recover the
+ repository: '<tt>svnadmin recover /path/to/repository</tt>'</li>
+
+ <li>Make a backup of the repository.</li>
+
+ <li>Delete all unused log files. You can see them by running
+ '<tt>svnadmin list-unused-dblogs /path/to/repeository</tt>'</li>
+
+ <li>Delete the shared-memory files. These are files in the
+ repository's <tt>db/</tt> directory, of the form <tt>__db.00*</tt></li>
+
+ </ol>
+</li>
+
+</ul>
+
+
+<p>The repository is now usable by Berkeley DB 4.3.</p>
+
+</div>
+
+
+</div>
+
+</div>
+
+
</div>
</body>
</html>