Use the new knowledge about old primary.
This is only relevant for people who are consistently ignoring
mars-manual.pdf which clearly states that intermediate
"marsadm secondary" should not be used at all, except for the
last step in final destruction of a resource.
After a primary --force, the error couldn't go away in case of
a defective logfile. Months later, sysadmins were needlessly alarmed
when looking at the primary.
In some rare cases (e.g. damaged /mars or crashed primaries),
the versionlink belonging to a logfile may be missing.
Don't insist on the existence of a versionlink if the logfile is
stemming from myself (automatic self-repair).
This is important for even more hardening of MARS.
Simulate crashes at the "wrong moment", typically with
IO requests flying, or just before a symlink update.
Only for debugging. Never use for production.
Feature request by Tilmann Steinberg.
It greatly eases debugging when searching for a source of wrong
permissions.
Some admin tools like Puppet seem to have their own default notion
of "secure permissions" and try to "fix" them ;)
Found by code inspection, neither in practice nor by testing.
Should not occur in practice, because it could only occur after
marsadm pause-fetch, which is an exceptional state only to be entered
for maintenance or for emergency failover.
Skipping over an incorrect logfile at a secondary may produce an
unnecessary split brain.
Fix the potential problem by doing it only after "primary --force",
and by never creating a new logfile, always by re-using existing
logfiles.
This has been found by testing.
In extremely rare cases, such after crashes at the "wrong moment"
or after defective /mars filesystems, the replay link could show a
different length than the corresponding versionlink.
The versionlink wouldn't be updated anymore when additionally the
logfile has the same length than the replay link.
The incorrect versionlink will then lead to a lock.
Fix the problem by using the _minimum_ of all length indicators.
For safty, or when in doubt, replay more data, which will in turn
update the versionlink again to its correct value.
