Re: repository conversion success story

Ben Collins-Sussman <sussman@collab.net> writes:

> 3. run phillip's concurrent access repos slammer(tm) script on
> the new filesystem.

It's a while since I ran this script, but the bad news is that I have
done a few tests and I can provoke deadlock over ra_local :-(

I normally run the script on a tmpfs (RAM based) filesystem as this
makes the repository access much faster. Today I got deadlock with
ten instances of the script (that's ten working copies accessing one
repository) once after after several hundred revisions, and once after
141 revisions. I also got a deadlock after 21 revisions with five
instances.

I don't know if there are any problems using Berkeley DB on tmpfs, so
I have just tried a run on a disk-based filesystem. I ran two
instances of the script for a hundred revisions, then added a third
instance, and later four more to make seven. I got a deadlock at
revision 226. So the problem does not appear to be a tmpfs artifact.

The script prints to stdout and I have noticed an oddity in the
output. Normally a successful commit produces something like

  Sending wcstress.4248/foo2
  Transmitting file data ....
  Committed revision 226.

and a failed commit produces an error message such as

  Sending wcstress.4244/foo2
  Transmitting file data ....
  ../svn/subversion/libsvn_client/commit.c:585
  svn_error: #21078 : <Merge conflict during commit>
    Commit failed (details follow):

  ../svn/subversion/libsvn_fs/tree.c:1664
  svn_error: #21078 : <Merge conflict during commit>
    conflict at "/foo1"

However, the deadlocks appear to involve at least one script instance
that displays something like

  Sending wcstress.4114/foo2
  Transmitting file data ....Status:

which I don't understand. The "Status:" text comes from an 'svn st'
command that gets run after the 'svn ci' command, but the commit
command does not appear to have produced all its output.

I've never really known how to debug these deadlocks :-( I can examine
the stack trace, but I don't know what to look for.

The machine is a dual processor x86 machine running Linux. I am using
Subversion rev 2109, built with APR_POOL_DEBUG=1. I'll try to
reproduce it without pool debugging.

-- 
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org