[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