On 24.11.2014 11:20, Julian Foad wrote:
> Branko Čibej <brane_at_wandisco.com> wrote:
>> On 21.11.2014 17:34, Branko Čibej wrote:
>>> 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.
>> To clarify, dropping non-sharded, non-packed layout options for FSFSv7
>> was not an option as long as we had support for mixed-mode addressing as
>> well. Now that we agreed to remove that, restricting FSFSv7 to only
>> sharded+packed layout sounds like a good idea to me, from the point of
>> view of reducing the number of possible layouts.
> Firstly, as I understand it, sharded layout (with a given shard size) is a config option and applies to all or none of the revisions, whereas packing a shard is an asynchronous
> activity and so there is no way to enforce that all or some or even any of the repository is packed.
>
> Non-sharded layout is like a special case of sharded, with shard size = infinity and the intermediate directory level omitted. And it can't be packed, so we're talking about a much smaller impact than reducing "4 or 8" layouts to one.
>
> Nevertheless I strongly support dropping any configuration options that aren't really useful, because reducing the number of configuration options does have a significant contribution to lowering the burdens of testing and support. I presume the non-sharded option has no significant real-world benefits over sharded with shard size = <more revisions than you'll ever have>.
All of the above is how I understand these things, too.
> Secondly, what are the upgrade options and issued when a user has a format 6 repo and upgrades to f7? Is it easy and cheap to upgrade non-sharded f6 to sharded f7, for example?
When the option of having mixed-mode addressing (i.e., having part of
the repository up to some revision use physical addressing, IOW FSFSv6
mode, and the rest using logical addressing, IOW FSFSv7 mode), there was
no way to directly upgrading v6 to v7 without a dump/load cycle.
With the latest change that introduces the option of having a v7
repository that does not use logical addressing, my best guess is that
direct v6-to-v7 upgrade is again possible; but I'm not 100% sure, and
I'm also not sure if doing so gives the user enough benefit over leaving
the repo in at v6 that it's worth supporting. Logical addressing is not
the only interesting feature of v7, but it's arguably the most visible one.
> Thirdly, what do we mean by "supporting" or "dropping" an option? We don't currently have an option in "svnadmin create" to choose anything other than sharded with shard size = 1000. I believe the procedure to follow to get a different layout is to manually edit the "db/format" file after "svnadmin create" but before creating any revisions. But that's not a great system. If other layout options or shard sizes are "supported" we should allow them to be specified in "svnadmin create".
I can't quite agree with that. Other shard sizes are "supported" in the
sense that you /can/ edit db/format and get different-sized shards, or
no shards at all, etc. When I proposed to "drop" that feature for
FSFSv7, I meant the following:
* That FSFSv7 layout is always sharded, regardless of what db/format says.
* That it always supports packing, again, regardless of db/format.
* That shard sizes can still be adjusted in db/format (and/or at
creation time)
The above would imply that v7 reads the format and warns if the layout
is not supported, but other than that, just ignores the sharded/packed
options there.
> We could choose either to drop all the code for reading and writing the non-sharded layout (which probably amounts to only about ten lines of code), or just keep on omitting an option to create it but leave it supported if somebody manually creates it.
Can't really do that, because we still support FSFSv6 with the same code
base.
> The more important thing is not whether the code is there, but whether the option is included in our testing and our declared supported formats.
And/or whether a v7 repository ignores, or doesn't ignore, those
specific parameters in db/format.
-- Brane
Received on 2014-11-24 11:47:17 CET