subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgeny Kotkov <>
Subject Re: Issue #4588, part 1: FSFS access error
Date Mon, 24 Aug 2015 23:47:16 GMT
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:

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.

2) The second part of the problem, to my mind, is the offset and item-based
   addressing.  Irrespectively of whether we use instance IDs in the cache
   keys, or not, I find it rather questionable that the same entry in the
   cache can mean two different things, depending on how you look at it.

   What happens if we're unlucky enough, and the offset in the revision file
   also is a valid index in the l2p lookup table?  Is there something we can
   do about it — say, associate the addressing type with the corresponding
   cache entry?


Evgeny Kotkov

View raw message