On 21 November 2014 at 19:34, Branko Čibej <brane_at_wandisco.com> wrote:
> On 21.11.2014 17:07, Ivan Zhakov wrote:
>> On 21 November 2014 17:15, Branko Čibej <brane_at_wandisco.com> wrote:
>>> On 21.11.2014 14:41, ivan_at_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
Received on 2014-11-24 14:30:36 CET