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

Re: Tracebacks in svnadmin tests (fs->uuid issues)

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Sun, 29 Apr 2012 09:51:13 +0300

Daniel Shahaf wrote on Sat, Apr 28, 2012 at 11:27:37 +0300:
> Greg Stein wrote on Fri, Apr 27, 2012 at 23:45:12 -0400:
> > Hey Daniel,
> >
> > I had four svnadmin tests dump core due to an assertion: 8, 21, 26,
> > 27. These are all marked XFail(), so my test run "passed".
>
> AFAIK all of those are due to the same issue: dst_fs->uuid not being
> initialized. Philip noted that there are probably worse problems here,
> since fs_fs_shared_data_t (ffd->ffsd) holds various locks and caches that
> are indexed by UUID only.

We store the following data for use by >1 svn_fs_t object, where today
the sharing is keyed on UUID only:

    typedef struct fs_fs_shared_data_t {
      fs_fs_shared_txn_data_t *txns;
      fs_fs_shared_txn_data_t *free_txn;
      svn_mutex__t *txn_list_lock;
      svn_mutex__t *fs_write_lock;
      svn_mutex__t *txn_current_lock;
      apr_pool_t *common_pool;
    } fs_fs_shared_data_t;

Hotcopy needs to support ≥2 filesystem instances which have the same
contents and UUID. (Keeping the UUID is part of the API.) However,
everything above except common_pool needs to be per-instance. So, we
need some sort of per-instance identifier to use as the cache key.

So, for example, one way to proceed would be to maintain
a ${REPOS}/db/uuid2 file, which is not exposed to fs-loader.h, and which
is used as part of the key to ffd->ffsd structures.

Assuming we agree on the course, I should be able to get this
implemented this week.
Received on 2012-04-29 08:52:02 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.