Re: [RFC] Deprecate Berkelety DB filesystem backend

[Vincent Lefevre]

On 2013-01-05 10:35:52 +, Philip Martin wrote:
> Branko Čibej  writes:
> 
> >   * The BDB backend is an order of magnitude slower on trunk than FSFS
> >   o timing parallel "make check" on my 4x4-core i7+ssd mac:
> >   + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
> >   + BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
> 
> I don't see that behaviour.  On my machine with 1x2 Core2 Duo, Linux and
> SSD:
> 
> FSFS: real 12m42.383s, user 7m37.557s, sys 5m58.534s
>  BDB: real 11m30.895s, user 8m14.603s, sys 5m45.358s
> 
> I don't think either your results or mine indicate anything about the
> relative performance of the backends as all the repositories in the
> testsuite are far too small.

As a user I no longer mind about BDB. But the above timings make
me think that BDB could still be useful for testing purpose (in
particular because you have no other backends).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Mark Phippard]

On Mon, Jan 7, 2013 at 5:40 AM, Philip Martin
 wrote:
> Branko Čibej  writes:
>
>> Interesting that i's that much slower on the Mac. But considering my
>> numbers:
>>
>>   * FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>>   * BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>>
>> Notice that the sys and user times are comparable, yet real-time is an
>> order of magnitude higher with BDB. Also, in the FSFS case, real time is
>> actually lower than user or sys time, which makes sense for parallel
>> tests. I interpret that as meaning that FSFS parallelizes (across
>> different processes) better than BDB, and that BDB spends most of its
>> time twiddling its thumbs waiting for I/O.
>
> Given the Linux numbers the problem is OSX specific and not inherent to
> BDB.  Repository access in the testsuite is all single-thread and
> single-process so any BDB locking should be trivial.  If we don't drop
> BDB then we shoud attempt to find out why BDB is slow on OSX.

I also think this is specific to OSX.  I reported this problem several
years ago on the list:

http://svn.haxx.se/dev/archive-2008-04/0602.shtml

As you can see from my email, the problem I was seeing seemed to be
just in creating the repository.  There was a significant time penalty
and multiplied across the number of times the tests create
repositories it really added up.  I never figured out why this takes
so long on OSX.  I recall it was pretty easy to look at the tests.log
and see where these unnatural delays existed.  I recall it was mostly
in setting up each new test, not the test itself.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Philip Martin]

Branko Čibej  writes:

> Interesting that i's that much slower on the Mac. But considering my
> numbers:
>
>   * FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>   * BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>
> Notice that the sys and user times are comparable, yet real-time is an
> order of magnitude higher with BDB. Also, in the FSFS case, real time is
> actually lower than user or sys time, which makes sense for parallel
> tests. I interpret that as meaning that FSFS parallelizes (across
> different processes) better than BDB, and that BDB spends most of its
> time twiddling its thumbs waiting for I/O.

Given the Linux numbers the problem is OSX specific and not inherent to
BDB.  Repository access in the testsuite is all single-thread and
single-process so any BDB locking should be trivial.  If we don't drop
BDB then we shoud attempt to find out why BDB is slow on OSX.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Stefan Fuhrmann]

On Sat, Jan 5, 2013 at 9:36 PM, Ben Reser  wrote:

> On Sat, Jan 5, 2013 at 7:10 AM, Stefan Fuhrmann
>  wrote:
> > So, we can passively support it for a while from now on and even
> > properly maintain it (bug fixes) without the expectation of that
> > being too costly.
>
> I think that the costs of continuing to have it around is probably
> higher than you're thinking.  This is someone we all spend time on
> having BDB around, dealing with build system support for it, and
> ultimately running the tests before releases.  Time spent messing with
> this stuff could be spent on other things.
>

Good point. However, as along as 1.9 supports BDB at all
(with or without fixes), all 1.9.x releases need to be tested
against BDB. I've no interest in complicating builds and
releases; I simply see no way around it.


>  > 1.9 will be supported until 1.11 gets released. IOW, any user still
> > running BDB will get another 3 .. 5 years of official support for
> > those repositories. Given that people like to make changes to their
> > SW infrastructure only if they replace the machines anyway, this
> > would be just the right time frame.
>
> Unless of course 1.9 comes faster than other versions have.
>

As a German comedian recently said:
Hope dies last (German proverb) - but it dies ;)

Cheers!
-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Stefan Fuhrmann]

On Sun, Jan 6, 2013 at 1:52 AM, Daniel Shahaf wrote:

> Branko Čibej wrote on Sat, Jan 05, 2013 at 22:32:14 +0100:
> > One thing I /don't/ know is what percentage of the Subversion installed
> > base (in both number of repositories and repository size) falls to BDB.
> > Does anyone have any idea about that?
>
> I think it'd be a good idea to poll users@, although I imagine some
> people on this list will have input too.
>

I guess the key question is *why* they are using BDB.
Wouldn't be surprised if those were legacy repos at some
svn hosting sites.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Daniel Shahaf]

Branko Čibej wrote on Sat, Jan 05, 2013 at 22:32:14 +0100:
> One thing I /don't/ know is what percentage of the Subversion installed
> base (in both number of repositories and repository size) falls to BDB.
> Does anyone have any idea about that?

I think it'd be a good idea to poll users@, although I imagine some
people on this list will have input too.

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Branko Čibej]

On 05.01.2013 21:36, Ben Reser wrote:
> Unless of course 1.9 comes faster than other versions have. 

:)

I probably should've written "1 year" and "2 years" instead of "1.9" and
"1.10" then.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Branko Čibej]

On 05.01.2013 11:35, Philip Martin wrote:
> Branko Čibej  writes:
>
>>   * The BDB backend is an order of magnitude slower on trunk than FSFS
>>   o timing parallel "make check" on my 4x4-core i7+ssd mac:
>>   + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>>   + BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
> I don't see that behaviour.  On my machine with 1x2 Core2 Duo, Linux and
> SSD:
>
> FSFS: real 12m42.383s, user 7m37.557s, sys 5m58.534s
>  BDB: real 11m30.895s, user 8m14.603s, sys 5m45.358s

Interesting that i's that much slower on the Mac. But considering my
numbers:

  * FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
  * BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s

Notice that the sys and user times are comparable, yet real-time is an
order of magnitude higher with BDB. Also, in the FSFS case, real time is
actually lower than user or sys time, which makes sense for parallel
tests. I interpret that as meaning that FSFS parallelizes (across
different processes) better than BDB, and that BDB spends most of its
time twiddling its thumbs waiting for I/O.

> I don't think either your results or mine indicate anything about the
> relative performance of the backends as all the repositories in the
> testsuite are far too small.

That's true. Of course, the numbers are only one data point, personally
I think the long-term maintenance costs are much more important.

One thing I /don't/ know is what percentage of the Subversion installed
base (in both number of repositories and repository size) falls to BDB.
Does anyone have any idea about that?

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Hyrum K Wright]

+1

-Hyrum


On Sat, Jan 5, 2013 at 12:53 PM, Justin Erenkrantz wrote:

> +1!  -- justin
> On Jan 5, 2013 10:40 AM, "Greg Stein"  wrote:
>
>> Is "+1" too short of a response?
>>
>> :-)
>> On Jan 4, 2013 7:35 PM, "Branko Čibej"  wrote:
>>
>>>  For the following reasons
>>>
>>>- FSFS has been the default filesystem backend for almost 7 years,
>>>since 1.2.
>>>
>>> - Looking at commit history, I've not seen a single (functional or
>>>performance) improvement, beyond a few bug fixes, in the BDB backend in 
>>> at
>>>least two years. The last significant change that I'm aware of was 
>>> released
>>>in 1.4 (support for BDB 4.4. and DB_REGISTER) back in 2006. In effect, 
>>> BDB
>>>is in "barely maintained" mode whereas interesting things are happening 
>>> to
>>>FSFS all the time.
>>>
>>> - I cannot remember seeing a BDB-related bug report in a month of
>>>Sundays (meaning that it's either rock-solid, or not used).
>>>
>>> - The BDB backend is an order of magnitude slower on trunk than FSFS
>>>   - timing parallel "make check" on my 4x4-core i7+ssd mac:
>>>  - FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>>>  - BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>>>
>>> I propose that we:
>>>
>>>- Declare the BDB backend deprecated in 1.8, adding appropriate
>>>warnings when it's used or manipulated (to svnadmin?)
>>>
>>> - Stop supporting it (including bug fixes) in 1.9
>>>
>>> - Completely remove the BDB-related code in 1.10 (I'm making an
>>>assumption that we'll have the FSv2 API and releated refactoring of FSFS 
>>> by
>>>then, and at least a draft experimental FSv2 implementation).
>>>
>>>
>>> I realize I'm raising this question at a time when we should be focusing
>>> on branching 1.8. On the other hand, this release may be a good opportunity
>>> to deprecate the Berkeley DB filesystem.
>>>
>>>
>>> --
>>> Branko Čibej
>>> Director of Subversion | WANdisco | www.wandisco.com
>>>
>>>

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Ben Reser]

On Sat, Jan 5, 2013 at 12:36 PM, Ben Reser  wrote:
> I think that the costs of continuing to have it around is probably
> higher than you're thinking.  This is someone we all spend time on
> having BDB around, dealing with build system support for it, and
> ultimately running the tests before releases.  Time spent messing with
> this stuff could be spent on other things.

This is something...

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Ben Reser]

On Sat, Jan 5, 2013 at 7:10 AM, Stefan Fuhrmann
 wrote:
> So, we can passively support it for a while from now on and even
> properly maintain it (bug fixes) without the expectation of that
> being too costly.

I think that the costs of continuing to have it around is probably
higher than you're thinking.  This is someone we all spend time on
having BDB around, dealing with build system support for it, and
ultimately running the tests before releases.  Time spent messing with
this stuff could be spent on other things.

> 1.9 will be supported until 1.11 gets released. IOW, any user still
> running BDB will get another 3 .. 5 years of official support for
> those repositories. Given that people like to make changes to their
> SW infrastructure only if they replace the machines anyway, this
> would be just the right time frame.

Unless of course 1.9 comes faster than other versions have.

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Ben Reser]

On Fri, Jan 4, 2013 at 5:34 PM, Branko Čibej  wrote:
> Declare the BDB backend deprecated in 1.8, adding appropriate warnings when
> it's used or manipulated (to svnadmin?)
>
> Stop supporting it (including bug fixes) in 1.9
>
> Completely remove the BDB-related code in 1.10 (I'm making an assumption
> that we'll have the FSv2 API and releated refactoring of FSFS by then, and
> at least a draft experimental FSv2 implementation).

+1

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Justin Erenkrantz]

+1!  -- justin
On Jan 5, 2013 10:40 AM, "Greg Stein"  wrote:

> Is "+1" too short of a response?
>
> :-)
> On Jan 4, 2013 7:35 PM, "Branko Čibej"  wrote:
>
>>  For the following reasons
>>
>>- FSFS has been the default filesystem backend for almost 7 years,
>>since 1.2.
>>
>> - Looking at commit history, I've not seen a single (functional or
>>performance) improvement, beyond a few bug fixes, in the BDB backend in at
>>least two years. The last significant change that I'm aware of was 
>> released
>>in 1.4 (support for BDB 4.4. and DB_REGISTER) back in 2006. In effect, BDB
>>is in "barely maintained" mode whereas interesting things are happening to
>>FSFS all the time.
>>
>> - I cannot remember seeing a BDB-related bug report in a month of
>>Sundays (meaning that it's either rock-solid, or not used).
>>
>> - The BDB backend is an order of magnitude slower on trunk than FSFS
>>   - timing parallel "make check" on my 4x4-core i7+ssd mac:
>>  - FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>>  - BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>>
>> I propose that we:
>>
>>- Declare the BDB backend deprecated in 1.8, adding appropriate
>>warnings when it's used or manipulated (to svnadmin?)
>>
>> - Stop supporting it (including bug fixes) in 1.9
>>
>> - Completely remove the BDB-related code in 1.10 (I'm making an
>>assumption that we'll have the FSv2 API and releated refactoring of FSFS 
>> by
>>then, and at least a draft experimental FSv2 implementation).
>>
>>
>> I realize I'm raising this question at a time when we should be focusing
>> on branching 1.8. On the other hand, this release may be a good opportunity
>> to deprecate the Berkeley DB filesystem.
>>
>>
>> --
>> Branko Čibej
>> Director of Subversion | WANdisco | www.wandisco.com
>>
>>

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Greg Stein]

Is "+1" too short of a response?

:-)
On Jan 4, 2013 7:35 PM, "Branko Čibej"  wrote:

>  For the following reasons
>
>- FSFS has been the default filesystem backend for almost 7 years,
>since 1.2.
>
> - Looking at commit history, I've not seen a single (functional or
>performance) improvement, beyond a few bug fixes, in the BDB backend in at
>least two years. The last significant change that I'm aware of was released
>in 1.4 (support for BDB 4.4. and DB_REGISTER) back in 2006. In effect, BDB
>is in "barely maintained" mode whereas interesting things are happening to
>FSFS all the time.
>
> - I cannot remember seeing a BDB-related bug report in a month of
>Sundays (meaning that it's either rock-solid, or not used).
>
> - The BDB backend is an order of magnitude slower on trunk than FSFS
>   - timing parallel "make check" on my 4x4-core i7+ssd mac:
>  - FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>  - BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>
> I propose that we:
>
>- Declare the BDB backend deprecated in 1.8, adding appropriate
>warnings when it's used or manipulated (to svnadmin?)
>
> - Stop supporting it (including bug fixes) in 1.9
>
> - Completely remove the BDB-related code in 1.10 (I'm making an
>assumption that we'll have the FSv2 API and releated refactoring of FSFS by
>then, and at least a draft experimental FSv2 implementation).
>
>
> I realize I'm raising this question at a time when we should be focusing
> on branching 1.8. On the other hand, this release may be a good opportunity
> to deprecate the Berkeley DB filesystem.
>
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
>

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Stefan Fuhrmann]

On Sat, Jan 5, 2013 at 2:34 AM, Branko Čibej  wrote:

>  For the following reasons
>
>- FSFS has been the default filesystem backend for almost 7 years,
>since 1.2.
>
> That only makes it feasible but is not a reason in itself to
not support other backends as well.

>
>-
>- Looking at commit history, I've not seen a single (functional or
>performance) improvement, beyond a few bug fixes, in the BDB backend in at
>least two years. The last significant change that I'm aware of was released
>in 1.4 (support for BDB 4.4. and DB_REGISTER) back in 2006. In effect, BDB
>is in "barely maintained" mode whereas interesting things are happening to
>FSFS all the time.
>
> The last part is the relevant one, IMO. It implies that fundamental
changes like FSv2 will introduce unknown stability issues with
BDB and may require significant additional maintenance efforts.

>
>-
> - I cannot remember seeing a BDB-related bug report in a month of
>Sundays (meaning that it's either rock-solid, or not used).
>
> So, we can passively support it for a while from now on and even
properly maintain it (bug fixes) without the expectation of that
being too costly.

>
>-
> - The BDB backend is an order of magnitude slower on trunk than FSFS
>   - timing parallel "make check" on my 4x4-core i7+ssd mac:
>  - FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>  - BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s
>
> Not promising anything here, but I could run a few standard ops
(export, log, dump) in 1.8 with a larger repo and see what happens.
Question: What if BDB turns out to be faster?

>
>
> I propose that we:
>
>- Declare the BDB backend deprecated in 1.8, adding appropriate
>warnings when it's used or manipulated (to svnadmin?)
>
> +1.

>
>-
> - Stop supporting it (including bug fixes) in 1.9
>
> -0. We should not forbid us from making critical fixes. Given the
track record, there will be very few of them.

>
>-
> - Completely remove the BDB-related code in 1.10 (I'm making an
>assumption that we'll have the FSv2 API and releated refactoring of FSFS by
>then, and at least a draft experimental FSv2 implementation).
>
>
> 1.9 will be supported until 1.11 gets released. IOW, any user still
running BDB will get another 3 .. 5 years of official support for
those repositories. Given that people like to make changes to their
SW infrastructure only if they replace the machines anyway, this
would be just the right time frame.


> I realize I'm raising this question at a time when we should be focusing
> on branching 1.8. On the other hand, this release may be a good opportunity
> to deprecate the Berkeley DB filesystem.
>

I think it is the perfect time for such a decision: We haven't done
any coding with the expectation of deprecating BDB, yet. Also,
1.9 will probably not exclusively rely on FSv2 but it could be the
defining feature in 1.10. Your proposal is a perfect fit in that
scenario.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: [RFC] Deprecate Berkelety DB filesystem backend

[Philip Martin]

Branko Čibej  writes:

>   * The BDB backend is an order of magnitude slower on trunk than FSFS
>   o timing parallel "make check" on my 4x4-core i7+ssd mac:
>   + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
>   + BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s

I don't see that behaviour.  On my machine with 1x2 Core2 Duo, Linux and
SSD:

FSFS: real 12m42.383s, user 7m37.557s, sys 5m58.534s
 BDB: real 11m30.895s, user 8m14.603s, sys 5m45.358s

I don't think either your results or mine indicate anything about the
relative performance of the backends as all the repositories in the
testsuite are far too small.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

[RFC] Deprecate Berkelety DB filesystem backend

[Branko Čibej]

For the following reasons

  * FSFS has been the default filesystem backend for almost 7 years,
since 1.2.

  * Looking at commit history, I've not seen a single (functional or
performance) improvement, beyond a few bug fixes, in the BDB backend
in at least two years. The last significant change that I'm aware of
was released in 1.4 (support for BDB 4.4. and DB_REGISTER) back in
2006. In effect, BDB is in "barely maintained" mode whereas
interesting things are happening to FSFS all the time.

  * I cannot remember seeing a BDB-related bug report in a month of
Sundays (meaning that it's either rock-solid, or not used).

  * The BDB backend is an order of magnitude slower on trunk than FSFS
  o timing parallel "make check" on my 4x4-core i7+ssd mac:
  + FSFS: real 7m33.213s, user 19m8.075s, sys 10m54.739s
  + BDB: real 35m17.766s, user 15m28.395s, sys 11m58.824s

I propose that we:

  * Declare the BDB backend deprecated in 1.8, adding appropriate
warnings when it's used or manipulated (to svnadmin?)

  * Stop supporting it (including bug fixes) in 1.9

  * Completely remove the BDB-related code in 1.10 (I'm making an
assumption that we'll have the FSv2 API and releated refactoring of
FSFS by then, and at least a draft experimental FSv2 implementation).


I realize I'm raising this question at a time when we should be focusing
on branching 1.8. On the other hand, this release may be a good
opportunity to deprecate the Berkeley DB filesystem.


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com