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

Re: svnadmin load to fsfs 9 times faster than bdb!?

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 30 May 2010 20:52:28 -0400

You just need to specify --bdb-txn-nosync when running svnadmin
create. although it is possible that svnadmin load also accepts this
option. This should make the load times about the same.

There is something you are supposed to change after loading the
dumpfile to turn this back on.

On Sun, May 30, 2010 at 3:48 PM, B Smith-Mannschott
<bsmith.occs_at_gmail.com> wrote:
> I've never really been much of a user of the BDB back end.  I started
> with Subversion in the 1.3 time-frame and have always used FSFS.
> Nevertheless, I recently was playing around with BDB and found that it
> takes a *lot* longer to load from a dump file than FSFS.
>
> * repository of 41818 revisions
> * dump file (--deltas) is 2.6 GB
>
> I'm running subversion on my (pretty ancient) home server:
>
> * PowerPC G4 @ 1GHz (Titanium Powerbook)
> * 2.5" 120GB Notebook hard drive
> * 1GB RAM
> * Subversion 1.6.0 (yea, I know, ancient)
>
> I loaded the dump file into into FSFS and BDB repositories:
>
> * FSFS took 5 hours and consumed 1.9 GB (1.8 GB after packing) of disk.
> * BDB took 44 hours and consumed 2.5 GB of disk.
>
> BDB does require far fewer "inodes", though I don't think that's
> relevant on HFS+, which stores everything in one giant B-Tree. BDB
> data isn't portable across architectures and BDB versions. It seems
> slower. It's trickier to back up. I'm sure there are operations where
> it performs faster than FSFS (svn log, for example). But, I guess I
> know now why I've always preferred FSFS. Does anyone actually use the
> BDB Subversion backend?
>
> // Ben
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-05-31 02:53:09 CEST

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

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