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:
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?
[1] http://svn.haxx.se/dev/archive-2014-08/0239.shtml
Regards,
Evgeny Kotkov
Received on 2015-08-25 01:47:46 CEST