This should not happen at all.
During several millions of operations hour, it occurs however when
hardware is defective. Try self-healing as far as possible.
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.
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 ;)
This is important for namespace systematics of primitive macros.
First name the object, then name its property. Like in OO.
Exception: when _finding_ the object itself needs an operation, or
additional information, e.g. %get-disk{} (this is the "lookup operation"
for the object itself, at least by concept).
For compatibility, the old forms will be accepted also
(silently, undocumented).
Originally a trivial silly bug (boolean value was wrong), leading to an
endless loop when a local versionlink was missing, which can happen
only after a primary crash at the wrong moment shortly after a logrotate
(not even during ordinary operations), followed by a hard reboot.
As documented in mars-manual.pdf, you simply need "modprobe mars"
to recover after such a crash reboot. MARS remembers the primary state
persistently for you and restores everything _automatically_.
Using "marsadm primary" in such a case to switch the current primary
to primary again (after an unnecessary "marsadm secondary" which is
strongly discouraged by mars-manual.pdf), although the host is / was
already in primary state after the reboot, is at least as silly as
the mentioned bug. Doing this in an /etc/init.d/ startup script
where it really doesn't belong into, is even more silly.
The latter is even an OPERATIONAL RISK, because "marsadm secondary"
works _globally_ in the whole cluster (as documented in mars-manual.pdf).
Such an improper startup script _can_ (potentially) disturb another
cluster member which had become primary in the _meantime_ during reboot.
Global cluster operations don't belong into startup scripts, because
reboots may happen unintentionally at any time.
At an actual primary, "Inconsistent" would be the correct description
for the state of the _disk_.
However most sysadmins will confuse this with the state of the
_replication_ (which is of course never inconsistent during
writeback from the memory buffer).
Although documented correctly, misunderstandings continue
to survive, because humans are automatically abstracting away
from detail components such as a "disk", and are automatically
assuming that "marsadm view" would relate to the replication
as a whole.
Avoid misunderstandings by more detailed message distinctions
aiming to address all of these in parallel.
Only relevant for non-storage servers where customers have access to.
Notice that /mars is a _reserved_ filesystem for MARS-internal purposes.
It has mothing to do with an ordinary filesystem.
Users have generally to be kept out.
