6. svnadmin Upgrade Procedure

Subversion 1.9 Changes

SVN MultiSite 1.9 is the next version of SVN MultiSite after 1.6. The leap to 1.9 signifies that this version of MultiSite is exclusively tied to Subversion 1.9.

SVN 1.9 FSFS changes

SVN 1.9 uses the new format-7 file system. Key changes to FSFS chiefly service the need for improved performance, as a result of the following enhancements:

Logical addressing
Improved organization of revision data storage when using svnadmin pack
Block-level reads are now cached

Features support by FSFS format:

The following table clearly indicates which FSFS formats support each of the new SVN 1.9 features:

Feature	Format 6	Format 7 Upgraded	Format 7 Native	Format 7 Native (packed)
Reduction in dynamic memory usage. Where feasible, temporary buffers have a fixed maximum size now. Other temporary containers have been reduced in memory consumption.	Yes	Yes	Yes	Yes
Saturate 10Gb networks from SVN caches. If almost all requests can be served from SVN fulltext caches etc., an 8-core server running Apache can saturate a 10Gb network with uncompressed data. It will take 20+ concurrent checkout or export requests to generate that load	Yes	Yes	Yes	Yes
Saturate 1Gb networks from OS caches. If virtually all requests can be served from the OS file cache, a 4-core server running Apache can saturate a 1Gb network with uncompressed data. It will take 2 or more concurrent checkout or export requests to generate that load.	Yes	Yes	Yes	Yes
svnadmin pack does not block commits.	No	Yes	Yes	Yes
Full checksum coverage of revision data. Not only user file contents, directories and properties are protected by checksums but also the meta-data tying them together. This only detects external corruption caused by rogue scripts, hard disk failure etc. and will not help against internal corruption caused by faulty SVN logic.	No	No	Yes	Yes
Quick verification to find external corruption. Verifies a repository at several 100MB/s and does not slow down with increasing number of revisions. This allows for a much faster health check after system failure.	No	No	Yes	Yes
Fast access to cold data on disk. Core feature of format 7. Revision data is read about twice as fast as with older formats. Assuming reading data from disk being 10x slower than from OS caches and a mere 10% OS cache misses, this translates into 30% higher overall throughput with format 7 over previous formats.	No	Yes	Yes	Yes

Get Packing

Regular packing of repository data is now recommended, since commits are now accepted during the packing, doing away with the old requirement for downtime during packing.

Packing FSFS filesystems

Subversion 1.9 FSFS-backed 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 be inefficient. Firstly, the OS has to reference many different files over a short period of time, leading 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.

A second problem is that filesystems allocate disk space, each file claims more space (from 2 to 16 kilobytes per file) on the disk than it actually uses. This gives FSFS_backed repositories a per-revision disk usage penalty, and the penalty can be noticeable on repositories that have extremely large numbers of small files

Benefits of packing

Packing was introduced in Subversion 1.6. It works by concatenating all the files of a completed shard into a single "pack" file and then removing the original per-revision files. This 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.

Subversion can pack existing sharded repositories which have been upgraded to the 1.6 filesystem format or later (see svnadmin upgrade).

Example packing operation

To do so, just run svnadmin pack on the repository:

$ svnadmin pack /opt/Subversion/repo1
Packing shard 0...done.
Packing shard 1...done.
Packing shard 2...done.
...
Packing shard 34...done.
Packing shard 35...done.
Packing shard 36...done.
$

Running under FSFS format, you can run svnadmin pack on repositories that are in use, 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.

svnadmin upgrade

MSP 1.9.0 introduces support for svnadmin upgrade for the first time.

This operation is done via a proposal, in other words, it is a coordinated action. While the operation is usually very fast (it can appear to happen instantly), there are some scenarios where an svnadmin upgrade can take an unexpectedly long time, during which time the repository will be locked.

Potentially very slow svnadmin upgrades with Format 4

Back in Subversion 1.7 (using FSFS format 4), there was support for revision packing, but not for revprop packing and so a packed shard had unpacked revprops. In later formats expect revprops to be packed if revisions are packed. Upgrading format 4 involves packing all the revprops corresponding to the packed revisions, reading those revprops, one file per revision, and writing the revprops, a few files per shard. So if a large number of revisions are packed then the runtime is likely to be proportional to the number of revisions.

Another factor that can delay the process is repository write-lock, although upgrade is no different to commit in this respect.

Note that the upgrade of an unpacked repository is fast as no revprops need to be packed.

Upgrade changes the file db/format, with 1.9 you can use:

# svnadmin create --compatible-version 1.6 myrepo
# svnadmin info myrepo | grep 'Filesystem Format'
Filesystem Format: 4
# svnadmin upgrade myrepo
Repository lock acquired.
Please wait; upgrading the repository may take some time...
Bumped repository format to 7

Upgrade completed.
# svnadmin info myrepo | grep "Filesystem Format"
Filesystem Format: 7

One other thing that can cause upgrade to take a long time is some other process holding a write lock:

$ svnadmin freeze repo sleep 60 & # background
$ svnadmin upgrade repo # blocks for freeze to complete