Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> That makes we wonder how we prevent packing in old format repositories.
> We know that hotcopying while packing can corrupt the destination repo.

[...]

> I'm -1 on reverting: Not being able to use hotcopy on an r/o repo is less
> problematic than ending up with a corrupted copy.

[...]

> Once we are at it, let's detect pack operations during hotcopy (compare
> pack status before & after the hotcopy). Then we can at least warn the
> user of older format repos that their hotcopy is possibly corrupt now.

[...]

Could you please elaborate on this? What are the exact circumstances under
which a concurrent 'svnadmin pack' for a hotcopy source makes a corrupted
hotcopy destination feasible?

A concurrent pack can result in the 'svnadmin hotcopy' erroring out with an
ENOENT — in a situation when we attempt to copy a revision file that moved
into a pack and was blown away in the cleanup happening in synced_pack_shard().
But even in this case the hotcopy destination is not *corrupt*, it is just
incomplete due to how hotcopy currently checkpoints changes in db/current and
in db/min-unpacked-rev (checkpointing occurs once per shard). The end user
is going to have a quite visible error in this case, and calling 'svnadmin
hotcopy --incremental' after receiving an error is going to copy the remaining
part of the source repository and bring the target up-to-date — just as if
nothing happened.

I believe that if there are known circumstances that can provoke a corruption
of the target repository during hotcopy, we should fix them, but I am currently
unaware of these conditions. What are they?

Regards,
Evgeny Kotkov
Received on 2015-06-16 23:56:28 CEST