On Wed, Nov 27, 2013 at 12:19 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 25 November 2013 17:44, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > On Mon, Nov 25, 2013 at 1:29 PM, Philip Martin <philip_at_codematters.co.uk
> >
> > wrote:
> >>
> >> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> >>
> >> > On Tue, Sep 24, 2013 at 6:51 PM, Ivan Zhakov <ivan_at_visualsvn.com>
> wrote:
> >> >
> >> >> On 23 August 2013 03:21, Stefan Fuhrmann <
> stefan.fuhrmann_at_wandisco.com>
> >> >> wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > As of r1516665, work on this branch has been completed.
> >> >> > Please review. See the BRANCH-README for the list of
> >> >> > major changes.
> >> >> >
> >> >> > If there are no objections, I will merge the code in the week
> >> >> > of Sep 23th.
> >> >> >
> >> >> Hi Stefan,
> >> >>
> >> >> I have looked through the code but I'm not ready to put my +1 on it.
> I
> >> >> think this branch is a good candidate for the "three +1" policy
> >> >> discused some time ago.
> >> >>
> >> >
> >> > Would you vote +1 under the 3-vote policy ("seems o.k. but more
> >> > independent review should take place")?
> >>
> >> I've been reviewing this branch and I am now happy for it to be merged
> >> to trunk.
> >
> >
> > Thanks a lot, Philip!
> > I plan on merging the branch later this week (Friday-ish).
> >
> Well, I still think that log-addressing branch should *NOT* be merged
> and all FS _performance_ and format changes should be implemented in
> FSX.
>
Format 7 is not simply an enabler for more speed. It adds
significant security features like a *complete* checksum
coverage of all repository content. This is based on the
new indexing infrastructure.
Ask people that had to fix corrupted repositories in the
past how hard it is to identify the source of a corruption.
Sticking with format 6 also means that we will not be able
to detect certain tree modifications / corruptions.
My primary concern is that currently FSFS supports reading and writing
> all FSFS formats. And there are more than 6 formats now, because they
> can differ of how repositories were upgraded. This makes code very
> complicated, because it should handle all different combinations of
> formats/upgrades.
>
That is a valid concern and one of many reasons for FSX
not being backward compatible. But I think the added cost
for supporting another format is not as high as you think.
In recent Subversion 1.8 release we got several critical data
> corruption errors due this complexity and handling older formats:
> * hotcopy: fix hotcopy losing revprop files in packed repos (issue #4448)
> * hotcopy: cleanup unpacked revprops with '--incremental' (r1512300 et al)
>
These two are strictly related to the new 1.8 feature
"incremental hotcopy".
> * fsfs: resolve endless loop problem when repos/db/uuid has \r\n (r1492145)
>
This is was a bug in io.c that happened to manifest
in fsfs and is not related to recent format changes.
> * fsfs: remove revision property buffer limit (r1491770)
>
That one is debatable. Since revprops are not handled
streamingly, there is always an upper limit to the size
of props (and revprops). In fact, not limiting the length
is potentially more risky.
In this case, we simply decided in favour of backward
compatibility over security.
> * fsfs: fixed manifest file growth with revprop changes (r1513874)
> * fsfs: fix packed revprops causing loss of revprops (r1513879 et al)
> * svnadmin upgrade: fix error of non-sharded fsfs repositories (r1494287)
> * svnadmin upgrade: fix data loss when cancelling in last stage (r1494298)
>
All these problems were found shortly after format 6
had been released. Compare that to problems like
"newlines in file names" that lingered in our code for
almost a decade.
> >> BTW, why we are not going to implement this in the FSX only?
> > Because FSX is not going to be recommended for general before
> > 2017 or so.
> This doesn't make sense for me: if FSX code is not ready for general
> use before 2017 then we should not push FSX-like features to stable
> and time proven FSFS.
>
That is a non-sequitur: not everything that takes a
single *idea* from FSX is as unstable as the complete
FS rewrite that FSX will ultimately be.
-- Stefan^2.
Received on 2013-11-27 17:18:54 CET