[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS F7: Combining rev data and indexes

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 30 Jun 2014 20:08:20 +0400

On 22 June 2014 12:03, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> On Fri, Jun 20, 2014 at 12:55 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On 20 June 2014 01:41, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
>> wrote:
>> > I just completed a patch that does exactly that.
>> >
>> > There is only one svnadmin test failing (trying to
>> > read the l2p index in order to corrupt change lists
>> > in a "controlled" way) and the svnfsfs tool can't
>> > (re-)write index data atm. So it seems we get a
>> > fix for the non-packed performance regression
>> > before the end of this week.
>> >
>> > I just completed a patch that does exactly that.
>> That sounds like a feasible idea but if we want to release 1.9 this
>> year, we should revert the log adressing feature from the trunk and
>> continue to redesign it in the feature branch.
[reordering to reply to both]

> The fixes are in /trunk now and release testing has not even started.
> So, I don't see a reason for f7 to delay a 1.9.0 unless new, severe
> issues will be found.
> As to the complexity of the fixes, their total number of added and
> changed lines is less than 450 and the logic is actually simpler now
> as we don't have to make sure we can access 3 files that may get
> deleted at any time anymore.
> Every once in a while we port fixes larger than that into our *stable*
> releases. For comparison, even your removal patch has 160 added
> or modified lines.
Log addressing feature was merged to trunk in December 2013 and it
took more than half a year to identify wrong decision to put indexes
in separate files. Even other committers who work in the same company
as you have learned this a week ago.

So I assume that we need another 3-6 months to find the next problem
in fsfs7 format (or make sure that there are no more problems).

>> So it's not a good
>> idea to perform significant rework and repository format change right
>> before the release. I expect that this may delay the release for
>> another 3-6 months at least.
> What kind of rework are you thinking about? What would the
> goal be?
I consider every repository format change as very significant
modification of how code works.

>> The log adressing feature is about 250kb of relatively complex code.
>> It's about 20% of all FSFS codebase.
> Yes, log addressing is a significant addition to the code base.
> Considering that roughly 3x as much has been added between
> 1.1 and 1.8, this addition does not seem to be out of proportion.
These releases added a lot of FSFS features such as locking, merge
tracking, packing, incremental hotcopy, rep caching, sharding etc. The
log addressing feature doesn't bring anything for the majority of
users besides the possible (and still questionable) performance
improvement for the very particular installations with enormous cache

Ivan Zhakov
Received on 2014-06-30 18:09:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.