### 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 through zlib to minimize on- ### disk size. That can be an expensive and ineffective process. This ### setting controls the usage of zlib in future revisions. ### Revisions with highly compressible data in them may shrink in size ### if the setting is increased but may take much longer to commit. The ### time taken to uncompress that data again is widely independent of the ### compression level. ### Compression will be ineffective if the incoming content is already ### highly compressed. In that case, disabling the compression entirely ### will speed up commits as well as reading the data. Repositories with ### many small compressible files (source code) but also a high percentage ### of large incompressible ones (artwork) may benefit from compression ### levels lowered to e.g. 1. ### Valid values are 0 to 9 with 9 providing the highest compression ratio ### and 0 disabling it altogether. ### The default value is 5. # compression-level = 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 4 kBytes by default for non-compressed revprop ### pack files and 16 kBytes when compression has been enabled. # revprop-pack-size = 4 ### ### 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