vytenau

### This file controls the configuration of the FSFS filesystem.

[memcached-servers]

### These options name memcached servers used to cache internal FSFS

### data.  See http://www.danga.com/memcached/ for more information on

### memcached.  To use memcached with FSFS, run one or more memcached

### servers, and specify each of them as an option like so:

# first-server = 127.0.0.1:11211

# remote-memcached = mymemcached.corp.example.com:11212

### The option name is ignored; the value is of the form HOST:PORT.

### memcached servers can be shared between multiple repositories;

### however, if you do this, you *must* ensure that repositories have

### distinct UUIDs and paths, or else cached data from one repository

### might be used by another accidentally.  Note also that memcached has

### no authentication for reads or writes, so you must ensure that your

### memcached servers are only accessible by trusted users.

[caches]

### When a cache-related error occurs, normally Subversion ignores it

### and continues, logging an error if the server is appropriately

### configured (and ignoring it with file:// access).  To make

### Subversion never ignore cache errors, uncomment this line.

# fail-stop = true

[rep-sharing]

### To conserve space, the filesystem can optionally avoid storing

### duplicate representations.  This comes at a slight cost in

### performance, as maintaining a database of shared representations can

### increase commit times.  The space savings are dependent upon the size

### of the repository, the number of objects it contains and the amount of

### duplication between them, usually a function of the branching and

### merging process.

###

### The following parameter enables rep-sharing in the repository.  It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the life of the repository.

### 'svnadmin verify' will check the rep-cache regardless of this setting.

### rep-sharing is enabled by default.

# enable-rep-sharing = true

[deltification]

### To conserve space, the filesystem stores data as differences against

### existing representations.  This comes at a slight cost in performance,

### as calculating differences can increase commit times.  Reading data

### will also create higher CPU load and the data will be fragmented.

### Since deltification tends to save significant amounts of disk space,

### the overall I/O load can actually be lower.

###

### The options in this section allow for tuning the deltification

### strategy.  Their effects on data size and server performance may vary

### from one repository to another.  Versions prior to 1.8 will ignore

### this section.

###

### The following parameter enables deltification for directories. It can

### be switched on and off at will, but for best space-saving results

### should be enabled consistently over the lifetime of the repository.

### Repositories containing large directories will benefit greatly.

### In rarely accessed repositories, the I/O overhead may be significant

### as caches will most likely be low.

### directory deltification is enabled by default.

# enable-dir-deltification = true

###

### The following parameter enables deltification for properties on files

### and directories.  Overall, this is a minor tuning option but can save

### some disk space if you merge frequently or frequently change node

### properties.  You should not activate this if rep-sharing has been

### disabled because this may result in a net increase in repository size.

### property deltification is enabled by default.

# enable-props-deltification = true

###

### During commit, the server may need to walk the whole change history of

### of a given node to find a suitable deltification base.  This linear

### process can impact commit times, svnadmin load and similar operations.

### This setting limits the depth of the deltification history.  If the

### threshold has been reached, the node will be stored as fulltext and a

### new deltification history begins.

### Note, this is unrelated to svn log.

### Very large values rarely provide significant additional savings but

### can impact performance greatly - in particular if directory

### deltification has been activated.  Very small values may be useful in

### repositories that are dominated by large, changing binaries.

### Should be a power of two minus 1.  A value of 0 will effectively

### disable deltification.

### For 1.8, the default value is 1023; earlier versions have no limit.

# max-deltification-walk = 1023

###

### The skip-delta scheme used by FSFS tends to repeatably store redundant

### delta information where a simple delta against the latest version is

### often smaller.  By default, 1.8+ will therefore use skip deltas only

### after the linear chain of deltas has grown beyond the threshold

### specified by this setting.

### Values up to 64 can result in some reduction in repository size for

### the cost of quickly increasing I/O and CPU costs. Similarly, smaller

### numbers can reduce those costs at the cost of more disk space.  For

### rarely read repositories or those containing larger binaries, this may

### present a better trade-off.

### Should be a power of two.  A value of 1 or smaller will cause the

### exclusive use of skip-deltas (as in pre-1.8).

### For 1.8, the default value is 16; earlier versions use 1.

# max-linear-deltification = 16

###

### After deltification, we compress the data to minimize on-disk size.

### This setting controls the compression algorithm, which will be used in

### future revisions.  It can be used to either disable compression or to

### select between available algorithms (zlib, lz4).  zlib is a general-

### purpose compression algorithm.  lz4 is a fast compression algorithm

### which should be preferred for repositories with large and, possibly,

### incompressible files.  Note that the compression ratio of lz4 is

### usually lower than the one provided by zlib, but using it can

### significantly speed up commits as well as reading the data.

### lz4 compression algorithm is supported, starting from format 8

### repositories, available in Subversion 1.10 and higher.

### The syntax of this option is:

###   compression = none | lz4 | zlib | zlib-1 ... zlib-9

### Versions prior to Subversion 1.10 will ignore this option.

### The default value is 'lz4' if supported by the repository format and

### 'zlib' otherwise.  'zlib' is currently equivalent to 'zlib-5'.

# compression = lz4

###

### DEPRECATED: The new 'compression' option deprecates previously used

### 'compression-level' option, which was used to configure zlib compression.

### For compatibility with previous versions of Subversion, this option can

### still be used (and it will result in zlib compression with the

### corresponding compression level).

###   compression-level = 0 ... 9 (default is 5)

[packed-revprops]

### This parameter controls the size (in kBytes) of packed revprop files.

### Revprops of consecutive revisions will be concatenated into a single

### file up to but not exceeding the threshold given here.  However, each

### pack file may be much smaller and revprops of a single revision may be

### much larger than the limit set here.  The threshold will be applied

### before optional compression takes place.

### Large values will reduce disk space usage at the expense of increased

### latency and CPU usage reading and changing individual revprops.

### Values smaller than 4 kByte will not improve latency any further and 

### quickly render revprop packing ineffective.

### revprop-pack-size is 16 kBytes by default for non-compressed revprop

### pack files and 64 kBytes when compression has been enabled.

# revprop-pack-size = 16

###

### To save disk space, packed revprop files may be compressed.  Standard

### revprops tend to allow for very effective compression.  Reading and

### even more so writing, become significantly more CPU intensive.

### Compressing packed revprops is disabled by default.

# compress-packed-revprops = false

[io]

### Parameters in this section control the data access granularity in

### format 7 repositories and later.  The defaults should translate into

### decent performance over a wide range of setups.

###

### When a specific piece of information needs to be read from disk,  a

### data block is being read at once and its contents are being cached.

### If the repository is being stored on a RAID, the block size should be

### either 50% or 100% of RAID block size / granularity.  Also, your file

### system blocks/clusters should be properly aligned and sized.  In that

### setup, each access will hit only one disk (minimizes I/O load) but

### uses all the data provided by the disk in a single access.

### For SSD-based storage systems, slightly lower values around 16 kB

### may improve latency while still maximizing throughput.  If block-read

### has not been enabled, this will be capped to 4 kBytes.

### Can be changed at any time but must be a power of 2.

### block-size is given in kBytes and with a default of 64 kBytes.

# block-size = 64

###

### The log-to-phys index maps data item numbers to offsets within the

### rev or pack file.  This index is organized in pages of a fixed maximum

### capacity.  To access an item, the page table and the respective page

### must be read.

### This parameter only affects revisions with thousands of changed paths.

### If you have several extremely large revisions (~1 mio changes), think

### about increasing this setting.  Reducing the value will rarely result

### in a net speedup.

### This is an expert setting.  Must be a power of 2.

### l2p-page-size is 8192 entries by default.

# l2p-page-size = 8192

###

### The phys-to-log index maps positions within the rev or pack file to

### to data items,  i.e. describes what piece of information is being

### stored at any particular offset.  The index describes the rev file

### in chunks (pages) and keeps a global list of all those pages.  Large

### pages mean a shorter page table but a larger per-page description of

### data items in it.  The latency sweetspot depends on the change size

### distribution but covers a relatively wide range.

### If the repository contains very large files,  i.e. individual changes

### of tens of MB each,  increasing the page size will shorten the index

### file at the expense of a slightly increased latency in sections with

### smaller changes.

### For source code repositories, this should be about 16x the block-size.

### Must be a power of 2.

### p2l-page-size is given in kBytes and with a default of 1024 kBytes.

# p2l-page-size = 1024

[debug]

###

### Whether to verify each new revision immediately before finalizing

### the commit.  This is disabled by default except in maintainer-mode

### builds.

# verify-before-commit = false