1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 | ### 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 |