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

Re: [PATCH & RFC] svn load --bdb-txn-nosync

From: Max Bowsher <maxb_at_ukf.net>
Date: 2004-03-31 22:47:09 CEST

Philip Martin wrote:
> "Max Bowsher" <maxb@ukf.net> writes:
>
>> This patch is mainly a load of boring updating of callers to new argument
>> specs, in order to be able to conditionally call
>> DB_ENV->set_flags(DB_TXN_NOSYNC).
>>
>> What I need comments on is: I've modified 2 public interfaces, creating
>> svn_repos_open2 and svn_fs_open_berkeley2. I'm wondering whether anyone
has
>> any other pending modifications that could be combined into the same API
>> change.
>>
>> Some statistics: This makes svnadmin load 5 times faster for me.
>
> No log message.
>
> The repository administrator can achive the same thing by setting
> DB_TXN_NOSYNC in the DB_CONFIG file. Your change makes it more
> convenient but I'm not sure that's enough to put this BDB specific
> flag in the libsvn_repos interface.

The alternative is quite messy and not easily automatable:
Edit DB_CONFIG, svnadmin recover, svnadmin load, Edit DB_CONFIG, svnadmin
recover.

Additionally, cvs2svn could really make use of this.
I think it is worth it.

Perhaps we should define some opaque pass through mechanism for
backend-specific options. Perhaps an APR hash?

> How well does your change work if
> another process, one not using DB_TXN_NOSYNC, is accessing the
> database at the same time?

The bdb docs are not entirely clear, I believe the other process will cause
log flushes and disk syncs.

Perhaps load should be acquiring an exclusive lock? I doubt the loader would
be particularly happy if someone managed to fit in a commit in the middle of
a load.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 22:47:38 2004

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.