[svnbook] r4564 committed - Inserted missing section.

svnbook at googlecode.com svnbook at googlecode.com
Wed Dec 18 14:36:02 CST 2013


Revision: 4564
Author:   jmfelderhoff at gmx.eu
Date:     Wed Dec 18 20:12:11 2013 UTC
Log:      Inserted missing section.

http://code.google.com/p/svnbook/source/detail?r=4564

Modified:
  /branches/1.6/de/book/ch05-repository-admin.xml

=======================================
--- /branches/1.6/de/book/ch05-repository-admin.xml	Thu Nov 28 09:30:07  
2013 UTC
+++ /branches/1.6/de/book/ch05-repository-admin.xml	Wed Dec 18 20:12:11  
2013 UTC
@@ -3426,6 +3426,78 @@

        </sect3>

+      <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
-->
+      <sect3 id="svn.reposadmin.maint.diskspace.fsfspacking">
+        <title>Packing FSFS filesystems</title>
+
+        <para>As described in the sidebar
+          <xref linkend="svn.reposadmin.basics.backends.fsfs.revfiles"/>,
+          FSFS-backed Subversion repositories create, by default, a
+          new on-disk file for each revision added to the repository.
+          Having thousands of these files present on your Subversion
+          server—even when housed in separate shard
+          directories—can lead to inefficiencies.</para>
+
+        <para>The first problem is that the operating system has to
+          reference many different files over a short period of time.
+          This leads to inefficient use of disk caches and, as a
+          result, more time spent seeking across large disks.  Because
+          of this, Subversion pays a performance penalty when
+          accessing your versioned data.</para>
+
+        <para>The second problem is a bit more subtle.  Because of the
+          ways that most filesystems allocate disk space, each file
+          claims more space on the disk than it actually uses.  The
+          amount of extra space required to house a single file can
+          average anywhere from 2 to 16 kilobytes <emphasis>per
+          file</emphasis>, depending on the underlying
+          filesystem in use.  This translates directly
+          into a per-revision disk usage penalty for FSFS-backed
+          repositories.  The effect is most pronounced in repositories
+          which have many small revisions, since the overhead involved
+          in storing the revision file quickly outgrows the size of
+          the actual data being stored.</para>
+
+        <para>To solve these problems, Subversion 1.6 introduced the
+          <command>svnadmin pack</command> command.  By concatenating
+          all the files of a completed shard into a single  
<quote>pack</quote> file
+          and then removing the original per-revision
+          files, <command>svnadmin pack</command> reduces the file
+          count within a given shard down to just a single file.  In
+          doing so, it aids filesystem caches and reduces (to one) the
+          number of times a file storage overhead penalty is
+          paid.</para>
+
+        <para>Subversion can pack existing sharded repositories which
+          have been upgraded to the 1.6 filesystem format (see
+          <xref linkend="svn.ref.svnadmin.c.upgrade"/>).  To do so,
+          just run <command>svnadmin pack</command> on the
+          repository:</para>
+
+        <informalexample>
+          <screen>
+$ svnadmin pack /var/svn/repos
+Packing shard 0...done.
+Packing shard 1...done.
+Packing shard 2...done.
+…
+Packing shard 34...done.
+Packing shard 35...done.
+Packing shard 36...done.
+$
+</screen>
+        </informalexample>
+
+        <para>Because the packing process obtains the required locks
+          before doing its work, you can run it on live repositories,
+          or even as part of a post-commit hook.  Repacking packed
+          shards is legal, but will have no effect on the disk usage
+          of the repository.</para>
+
+        <para><command>svnadmin pack</command> has no effect on
+          BDB-backed Subversion repositories.</para>
+
+      </sect3>
      </sect2>

      <!-- ===============================================================  
-->



More information about the svnbook-dev mailing list