On Mon, Nov 24, 2014 at 11:45 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 24.11.2014 11:20, Julian Foad wrote:
>
> Branko Čibej <brane_at_wandisco.com> <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.
>
It is incorrect in a few details. Sharding basically changes
the file paths on disk and there is little extra code to that
handles linear repos explicitly.
The complication is that we represent linear repos as
"shard size 0" internally while we use the shard size as
divisor in many places. So, we must check for 0, usually
treat it as meaning granularity "1" where it is not implied
that we do have a sharded repo (everything packed is
known sharded). Chances are that we miss instances
and cause a division by 0 for linear repos. This is very
different from infinitely large shard sizes.
> 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.
>
You could always upgrade directly from format 6 to 7.
Linear repos would never use log. addressing in that case
and sharded ones would use it starting with the next shard.
r1637184 has changed that to never using log. addressing
in upgraded repos.
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.
>
Switching between linear and sharded mode is not supported
in the sense that you also have to manually move r0 data to
the respective new path. You may only change the shard size
while the first shard is not completely filled (and make damn
sure nobody has an open svn_fs_t on that repo).
> 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.
>
I'm in favour of phasing linear repos out. We still have to support
them but forgetting to check for shard size 0 is more likely to
happen for new code than existing code. I also tend to issuing
a warning or even failure when trying to upgrade a linear repos.
And read_format() should error out on the combination "linear"
and "logical addressing".
-- Stefan^2.
Received on 2014-11-24 16:02:28 CET