On 8/19/14 12:07 AM, Branko Čibej wrote:
> I think it's not that simple.
>
> Consider the case where an administrator decides to not use 'svnadmin hotcopy'
> to back up a repository, but instead creates a (LVM) snapshot of the volume and
> uses 'tar' (or 'cp -a') to create the backup.
>
> When such a backup is restored and made active, everything will just work ...
> except that stale caches in svnserve or mor_dav_svn will not be automatically
> invalidated. In other words, the mere introduction of the instance ID does not
> solve "all" problems. There are several possible resolutions to this particular
> problem:
>
> * Tell the users "don't do that". That won't help; they'll do it anyway.
> * Require a restart of all servers when restoring such backups; been there,
> people forget.
> * Require that the users run 'svnadmin recover' before bringing the
> repository online; this might work if 'svnadmin recover' tweaks the
> instance ID, since presumably they're already using it per our existing
> recommendation.
> * Invent 'svnadmin restore' or 'svnadmin activate' or whatnot to make such
> backups viable; see above, people forget.
> * Require 'svnadmin setuuid' on the restored backups; this breaks existing
> working copies.
>
> So, even though the existence of the instance ID is an implementation detail,
> it does cause visible change in the behaviour of the repository: server
> restarts due to fiddling with the repository instance are needed far less
> often; but we still have to document when and why they are needed.
I think part of the problem here has been we (as in WANdisco folks) have
discussed the idea of an instance ID for repositories in the past to solve the
range of replacing the repository without clearing the cache issues. But this
change is being added for a very different reason.
Evgeny has implemented the instance ID for the purpose of solving the problem
of two different repositories not being able to be locked if they happen to
have the same UUID. This happens because we use a mutex to handle locking
between threads and that mutex can't distinguish between different repositories
with identical UUIDs.
Currently the code on trunk adds the instance ID to the cache keys. I'm not
sure we should be doing that (though both brane and stefan2 requested that be
done). As per the discussion today at the SHF hackathon the instance ID can't
resolve the failure to clear the cache issues. The best it can do is narrow
the window for these issues to exist. That would seem like a good thing but I
think it creates a huge false sense of security. We will ultimately have
someone that comes along with a corrupted repository, we're going to say you
replaced the repo while the server was running and the user is going to say
"But I've been doing this for years without any problem."
Without the instance ID in the cache keys users are unlikely to actually
corrupt their repository (just like they would be with them, it's a pretty hard
race to hit). But they are likely to get errors related to the cache being
stale. This gives them a giant hint that what they're doing is wrong and gives
us an opportunity to educate them.
Received on 2014-08-20 18:14:07 CEST