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:
>>> Author: ivan
>>> Date: Fri Nov 21 13:41:34 2014
>>> New Revision: 1640915
>>>
>>> URL: http://svn.apache.org/r1640915
>>> Log:
>>> Add FS config option to control log-addressing feature for created
>>> repository.
>> Can we *please* have some discussion about such changes on the dev@
>> list?
> What particular kind of changes you're talking about?
Changes that significantly affect some existing feature in trunk. In
other words, things that are not bug fixes, robustness fixes or similar.
>> 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).
Specifically, I'm looking for an explanation why you think it makes
sense to turn off log addressing in v7, as opposed to just using v6 if
one doesn't want log addressing. Certainly log addressing does change
user-visible behaviour; cold-cache performance is user-visible.
You said you're planning to use this parameter in the test suite ...
however, it since it doesn't make any sense to test something that we're
not planning to release, I have to assume that you intend this to be a
feature of FSFSv7 in 1.9 (and, consequently forever).
It's the "forever" without prior discussion here that I find
problematic. And so is yet another parameter that changes behaviour,
because: (a) we have to maintain it, and (b) it adds another dimension
to the already-too-large number of possible option combinations that we
need to test.
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.
-- Brane
Received on 2014-11-21 17:34:53 CET