subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: fs-test 44 XPASS
Date Mon, 18 May 2015 04:02:25 GMT
On Wed, May 6, 2015 at 11:07 AM, Philip Martin <philip.martin@wandisco.com>
wrote:

> Stefan Fuhrmann <stefan.fuhrmann@wandisco.com> writes:
>
> > Here is what I believe causes the different behaviour between
> > test runs. To support read function that may block, e.g. wait for
> > network buffers to flush, writes have been made non-blocking
> > if they don't update existing cache entries. If the write lock can
> > not be acquired immediately in that case, the new item will simply
> > not be added to the cache.
> >
> > This behaviour is optional and can be disabled via flag:
> >
> > [[[
> > Index: subversion/libsvn_subr/cache_config.c
> > ===================================================================
> > --- subversion/libsvn_subr/cache_config.c    (revision 1675401)
> > +++ subversion/libsvn_subr/cache_config.c    (working copy)
> > @@ -126,7 +126,7 @@
> >            (apr_size_t)(cache_size / 5),
> >            0,
> >            ! svn_cache_config_get()->single_threaded,
> > -          FALSE,
> > +          TRUE,
> >            pool);
> >
> >        /* Some error occurred. Most likely it's an OOM error but we don't
>
> > Does the above patch fix the non-deterministic behaviour?
>
> Yes, I now see 3,2,1,0 and XFAIL all the time.  So in order to make this
> test reliable I have to move it to a different executable with
>
> static int max_threads = 1;
>
> so that other test cannot interfere with the use of the cache by this
> test.
>

I finally got the fix for the underlying problem committed
as a series of patches to /trunk (r1679920-r1679926).

The core idea is simple: in-txn directory representations
are append-only. Even entry deletions are realized by
appending the corresponding deletion record. Hence,
we only need to cache that filesize alongside the actual
contents. If the cached value matches the actual filesize,
the cache is up-to-date. Otherwise, some 3rd party wrote
to the txn (or we have some unknown bug).

-- Stefan^2.

Mime
View raw message