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

Re: Issue #4588, part 1: FSFS access error

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 25 Aug 2015 06:15:20 +0000

Evgeny Kotkov wrote on Tue, Aug 25, 2015 at 02:47:16 +0300:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> 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 (53F4C92B.2010206_at_reser.org), 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] http://svn.haxx.se/dev/archive-2014-08/0239.shtml
> Regards,
> Evgeny Kotkov
Received on 2015-08-25 08:15:41 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.