On 21 November 2014 at 19:34, Branko Čibej <br...@wandisco.com> wrote: > On 21.11.2014 17:07, Ivan Zhakov wrote: >> On 21 November 2014 17:15, Branko Čibej <br...@wandisco.com> wrote: >>> On 21.11.2014 14:41, i...@apache.org wrote: >>> Why do you want to be able to turn off log addressing, when you can just >>> not use FSFSv7 in the first place? >>> >> This is just a small addition to existing API like >> SVN_FS_CONFIG_FSFS_SHARD_SIZE, SVN_FS_CONFIG_FSFS_BLOCK_READ, >> SVN_FS_CONFIG_BDB_TXN_NOSYNC etc. It doesn't change user-visible >> behavior and I'm planning to use this in the test suite. >> >> If you have any concerns regarding this change, please let me know. > > The parameters you mention are all performance-related knobs, so not > quite comparable to the change you made. Perhaps a better comparison is > the FS layout option (sharded vs. non-sharded, packed vs. unpacked). > That's not quite true. This API option is similar to the following: 1) create a FSFSv6 repository 2) upgrade it to the FSFSv7 format.
In other words, this option does not create new repository layout combination. Maybe my log message was not clear about that. But to avoid further developers confusion I could revert my commit and then implement the tests through the creation of FSFSv6 repositories and upgrading them to FSFSv7. While I prefer to have an explicit option for different already supported layouts than remember what happens during the upgrade, but it's not a big deal for me. What do you think? > As a counter-example, I'd much prefer to drop the ability to create > non-sharded, non-packed FSFSv7 repositories; that would change the > number of possible v7 layouts from 4 (or 8, with r1640915 in place) to > just one, not counting shard sizes etc. Generally, I like the idea to reduce the number of possible repository layouts. This is exactly what I'm saying for the last few months. Note that number of layouts is greater than number of format versions, because they got multiplied due to different upgrade paths. The problem is that all the possible combinations are already exist in the wild. For example: 1. Repository is created using Subversion 1.1 (format 1). At this point only non-sharded repositories exists. 2. Then upgraded using Subversion 1.5 to format 5. Sharding cannot be changed during upgrade, so it still remain as non-sharded. 3. Then it's upgraded Subversion 1.9 to format 7. And it is still non-sharded and log-addressing disabled. IMHO the best way to keep it simple - implement the significant format changes in new FS-backends (i.e. FSX), but this is a different story. -- Ivan Zhakov
