* Remove references to Berkeley DB, including most of the

  troubleshooting section.  W00t.

4 files changed, 17 insertions, 143 deletions

diff --git a/doc/manual/conf-file.xml b/doc/manual/conf-file.xml
index acf0eb4f5448..66df3edd5fb8 100644
--- a/doc/manual/conf-file.xml
+++ b/doc/manual/conf-file.xml
@@ -60,27 +60,6 @@ env-keep-derivations = false
   </varlistentry>
 
   
-  <varlistentry xml:id="conf-gc-reserved-space"><term><literal>gc-reserved-space</literal></term>
-
-    <listitem><para>This option specifies how much space should be
-    reserved in normal use so that the garbage collector can run
-    succesfully.  Since the garbage collector must perform Berkeley DB
-    transactions, it needs some disk space for itself.  However, when
-    the disk is full, this space is not available, so the collector
-    would not be able to run precisely when it is most needed.</para>
-
-    <para>For this reason, when Nix is run, it allocates a file
-    <filename>/nix/var/nix/db/reserved</filename> of the size
-    specified by this option.  When the garbage collector is run, this
-    file is deleted before the Berkeley DB environment is opened.
-    This should give it enough room to proceed.</para>
-
-    <para>The default is <literal>1048576</literal> (1
-    MiB).</para></listitem>
-
-  </varlistentry>
-
-  
   <varlistentry><term><literal>env-keep-derivations</literal></term>
 
     <listitem><para>If <literal>false</literal> (default), derivations
diff --git a/doc/manual/installation.xml b/doc/manual/installation.xml
index bf4331d7514e..b13be1363f70 100644
--- a/doc/manual/installation.xml
+++ b/doc/manual/installation.xml
@@ -96,18 +96,23 @@ ubiquitous 2.5.4a won't.  Note that these are only required if you
 modify the parser or when you are building from the Subversion
 repository.</para>
 
-<para>Nix uses Sleepycat's Berkeley DB, CWI's ATerm library and the
-bzip2 compressor (including the bzip2 library).  These are included in
-the Nix source distribution.  If you build from the Subversion
-repository, you must download them yourself and place them in the
+<para>Nix uses CWI's ATerm library and the bzip2 compressor (including
+the bzip2 library).  These are included in the Nix source
+distribution.  If you build from the Subversion repository, you must
+download them yourself and place them in the
 <filename>externals/</filename> directory.  See
 <filename>externals/Makefile.am</filename> for the precise URLs of
 these packages.  Alternatively, if you already have them installed,
 you can use <command>configure</command>'s
-<option>--with-bdb</option>, <option>--with-aterm</option> and
-<option>--with-bzip2</option> options to point to their respective
-locations.  Note that Berkeley DB <emphasis>must</emphasis> be version
-4.5; other versions may not have compatible database formats.</para>
+<option>--with-aterm</option> and <option>--with-bzip2</option>
+options to point to their respective locations.</para>
+
+<para>If you want to be able to upgrade Nix stores from before version
+0.12pre12020, you need Sleepycat's Berkeley DB version version 4.5.
+(Other versions may not have compatible database formats.).  Berkeley
+DB 4.5 is included in the Nix source distribution.  If you do not need
+this ability, you can build Nix with the
+<option>--disable-old-db-compat</option> configure option.</para>
 
 </section>
 
diff --git a/doc/manual/release-notes.xml b/doc/manual/release-notes.xml
index c2eaa28bc244..eec4ab6ba9b3 100644
--- a/doc/manual/release-notes.xml
+++ b/doc/manual/release-notes.xml
@@ -87,7 +87,7 @@ $ rm __db* log.* derivers references referrers reserved validpaths DB_CONFIG</sc
   upgrading, instead of setting an exclusive lock on the profile.
   This allows multiple <command>nix-env -i / -u / -e</command>
   operations on the same profile in parallel.  If a
-  <command>nix-env</command> operation sees at th end that the profile
+  <command>nix-env</command> operation sees at the end that the profile
   was changed in the meantime by another process, it will just
   restart.  This is generally cheap because the build results are
   still in the Nix store.</para></listitem>
@@ -171,7 +171,7 @@ the following paths will be downloaded/copied (30.02 MiB):
   <literal>nix-store --import &lt;
   closure</literal>.</para></listitem>
 
-  <listitem><para>Lots of bugfixes, including a big performance bug in
+  <listitem><para>Lots of bug fixes, including a big performance bug in
   the handling of <literal>with</literal>-expressions.</para></listitem>
 
 </itemizedlist>
diff --git a/doc/manual/troubleshooting.xml b/doc/manual/troubleshooting.xml
index 0d3a892cc9ba..7403200e0326 100644
--- a/doc/manual/troubleshooting.xml
+++ b/doc/manual/troubleshooting.xml
@@ -9,117 +9,6 @@ the <link xlink:href="http://bugs.strategoxt.org/browse/NIX">Nix
 bug tracker</link> for a list of currently known issues.</para>
 
 
-<section><title>Berkeley DB: <quote>Cannot allocate memory</quote></title>
-
-<para>Symptom: Nix operations (in particular the
-<command>nix-store</command> operations <option>--gc</option>,
-<option>--verify</option>, and <option>--clear-substitutes</option> —
-the latter being called by <command>nix-channel --update</command>)
-failing:
-
-<screen>
-$ nix-store --verify
-error: Db::del: Cannot allocate memory</screen>
-
-</para>
-
-<para>Possible solution: make sure that no Nix processes are running,
-then do:
-
-<screen>
-$ cd /nix/var/nix/db
-$ rm __db.00*</screen>
-
-</para>
-
-</section>
-
-
-<section><title>Berkeley DB gives weird error messages</title>
-
-<para>Symptom: you get error messages such as
-
-<screen>
-Berkeley DB message: Finding last valid log LSN: file: 1 offset 28
-Berkeley DB error: file validpaths (meta pgno = 0) has LSN [483][34721].
-Berkeley DB error: end of log is [1][28]
-Berkeley DB error: /nix/var/nix/db/validpaths: unexpected file type or format</screen>
-
-or other weird Berkeley DB errors, and they don’t go away (i.e.,
-automatic recovery doesn’t work).  This may be the case after a system
-crash.</para>
-
-<para>Solution: first try to run <command>db_recover</command> and
-then <link linkend='refsec-nix-store-verify'><command>nix-store
---verify</command></link>:
-
-<screen>
-$ db_recover -h /nix/var/nix/db
-$ nix-store --verify</screen>
-
-(Make sure that you have the right version of
-<command>db_recover</command>, namely, Berkeley DB 4.4 for Nix 0.10,
-and 4.5 for Nix 0.11.)</para>
-
-<para>If that doesn’t work, it’s time to bring out the big guns:
-
-<screen>
-$ cd /nix/var/nix
-$ cp -pr db db-backup  <lineannotation>(making a backup just in case)</lineannotation>
-$ cd db
-$ rm __db.* log*  <lineannotation>(removing the Berkeley DB environment)</lineannotation>
-$ mkdir tmp
-$ for i in *; do db_dump $i | (cd tmp &amp;&amp; db_load $i); done 
-<lineannotation>(ignore error messages about non-database files like “reserved”)</lineannotation>
-$ mv tmp/* .
-$ nix-store --verify</screen>
-
-</para>
-
-</section>
-
-
-<section><title>Berkeley DB out of locks</title>
-
-<para>It is possible, especially in <command>nix-store
---verify</command> or when running the garbage collector, to run out
-of Berkeley DB locks, like this:
-
-<screen>
-$ nix-store --verify
-checking path existence
-checking path realisability
-checking the derivers table
-checking the references table
-Berkeley DB error: Lock table is out of available object entries
-error: Db::get: Cannot allocate memory</screen>
-
-</para>
-
-<para>A workaround is to increase the number of locks that Berkeley DB
-allocates.  (The real solution would be for Nix to not use so many
-locks.)  This can be done by putting the following in the file
-<filename>/nix/var/nix/db/<link
-xlink:href="http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html">DB_CONFIG</link></filename>:
-
-<programlisting>
-set_lk_max_locks   100000
-set_lk_max_lockers 100000
-set_lk_max_objects 100000
-</programlisting>
-
-(Increase these numbers if necessary.)  Then make sure that there are
-no running Nix processes and delete the Berkeley DB environment:
-
-<screen>
-$ rm /nix/var/nix/db/__db.*</screen>
-
-The Berkeley DB environment is automatically recreated with the new
-limits when you run any Nix command.</para>
-
-</section>
-
-
 <section><title>Collisions in <command>nix-env</command></title>
 
 <para>Symptom: when installing or upgrading, you get an error message such as
@@ -187,7 +76,8 @@ Furthermore, the <literal>st_nlink</literal> field of the
 <para>This only happens on very large Nix installations (such as build
 machines).</para>
 
-<para>Quick solution: run the garbage collector.</para>
+<para>Quick solution: run the garbage collector.  You may want to use
+the <option>--max-links</option> option.</para>
 
 <para>Real solution: put the Nix store on a file system that supports
 more than 32,000 subdirectories per directory, such as ReiserFS.