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).
Only a secondary is allowed to do this, because we assume that
logfile replay has the property of "anytime consistency"
only there.
When a primary cannot recover after a crash due to a defective
logfile, this is not true. The primary is simply lost in such a
(rare) case. Observed 2 times during almost 8 millions of
operating hours.
In such a case, hardware is truly defective, and you have only
the following options:
1) switchover to a secondary via "primary --force", OR
2) deconstruct the resource everywhere, run fsck or similar on
whatever replica seems to be the best version,
and reconstruct the resource from scratch, OR
3) restore your backup.
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.