subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Issue #4588, part 1: FSFS access error
Date Tue, 25 Aug 2015 06:15:20 GMT
Evgeny Kotkov wrote on Tue, Aug 25, 2015 at 02:47:16 +0300:
> Stefan Fuhrmann <> writes:
> > My current hypothesis is that the server did not get restarted after
> > replacing the repository.  Because we decided not to make the instance ID
> > part of the cache key, we could easily have picked up cached format 6 data
> > for the format 7 repository.
> [...]
> > That said, are we still happy with the decision to not make the instance
> > ID part of the cache key? The rationale has basically been "fail early"
> > because failure to restart or reconfigure the server after the repo files
> > got modified might lead to any kind of unknown problems (much) further down
> > the road.
> As I see it, there are two separate problems:

I see it the same way.

> 1) First of all, I am thinking that we should indeed revisit the decision of
>    not making instance IDs a part of the cache keys.  As far as I recall, this
>    part of the change was reverted after we agreed that failing fast is better
>    than narrowing the window when the cache issues exist [1] (there are still
>    scenarios like backing up and restoring the repository with cp -a).
>    Now I am almost sure that we should redo this change.  The experience of
>    receiving errors related to stale cache entries isn't exactly educating,
>    but rather than that, it's frustrating, and the procedures describing dump,
>    load and hotcopy rarely say something about a server restart.  As we have
>    the mechanism to make a huge set of cases work without the necessity of
>    performing additional actions, I think that we should do it, leaving the
>    edge cases as they are.  In other words, people who are used to svnadmin
>    dump/load/hotcopy shouldn't struggle, because we think that they also could
>    be doing something like the aforementioned cp -a.

What are the downsides to having instance IDs as part of the cache key?
I haven't been able to understand that from your post or from Ben's post
you link to (, which only mentions a "failure
to clear the cache race that was discussed offlist".

Is this the problem scenario? ---

1. Open an svn_fs_t handle

2. Replace the repository with another repository having the same UUID
   but different contents

3. Make a commit from the svn_fs_t opened in (1)

4. The commit creates a corrupted revision due to stale (false positive)
   cache hits




> [1]
> Regards,
> Evgeny Kotkov

View raw message