The boot check that a log data directory and the control plane this node is about to start describe the same data.

ra keeps a node's control plane under the node's name: its log lives under MALACHI_RA_DATA_DIR/<node>, and every member is recorded as {cluster, node()}. What a node acknowledged survives a restart only while the segments on disk and that control plane come back together, and when they do not, the orphan sweep used to settle it by deleting the segments (#273). Two things are checked before the broker starts, after a first one on the directory's own record:

• a log directory of another control plane. A start that passes records the control plane's name at the root of the log directory (malachi.cluster), just before it writes a seed or once every check has passed, and a later start under another name refuses, before the ring store is touched. A start refused before its seed is written records nothing; one that fails after the seed check passed (the seed write, or a later membership check) keeps the name it seeded under, since the seed's vnodes carry that name and whether the write landed may not be known. Every other check reads ra by node name, and the ring store is one per ra directory and node name whatever the cluster is called, so a renamed control plane over the same directories would read the old one's state as its own; a member that held no segment would pass every other check and could seed the ring its peers then trust.

• segments nobody knows. The log directory already holds segment directories, and the control plane that would describe them is about to be formed rather than resumed: the ring store (Malachi.LogRing, which every clustered node runs, sharded or not) was never started on this node; or, for an unsharded control plane, its metadata member was never started here; or a sharded ring is about to be seeded, forming every vnode now (check_seed/3); or, for a sharded node configured alone, one of its vnodes was never started here. A cluster is not held to that, since a rebalance moves vnodes off a node without republishing the ring, and a vnode with other replicas keeps its history on them; a vnode whose only replica is this node (MALACHI_LOG_VNODE_REPLICATION_FACTOR=1 on a cluster) has no such protection. The node name changed (a container recreated without a fixed hostname, iex --name with another name), the ra directory was lost, the cluster was renamed, or the segments were written by a release that kept a single node's metadata in memory. On a single node a control plane formed now is empty, every one of those directories would read as an orphan, and a topic created again under an old name would read the old bytes as its own. A cluster member is refused too, though its peers may still hold the control plane: it would come back an amnesiac voter, and adopting is then the operator's way back, the sweep removing only what no owner lists. A node that joins a cluster for the first time has nothing on disk to refuse.

• a single node told it has peers. The control plane was started here as a cluster of one, and the configuration now lists other nodes. Growing a one-member cluster in place is not supported: this node would resume its ring store (and its metadata, sharded or not) alone while the others formed clusters of their own over the same names. The ring store member, which every clustered node runs and which was formed over the same nodes as the metadata, is asked for its recorded membership; a member that does not answer within the ring boot timeout refuses the start too, since a check that cannot be made must not read as passed.

Each refuses the start through Malachi.StartupRefusal (exit 78) with a line that names the causes and the way out. Segments nobody knows can be adopted with MALACHI_ADOPT_ORPHANED_LOG_DIR=true, which is the operator saying the directories are not wanted: the start goes on, the adopted names are logged, and the orphan sweep removes them on its own schedule. The others cannot.

A third refusal guards the switch to sharding: a node whose unsharded metadata member ran here never starts sharded. A sharded ring is durable and outranks MALACHI_LOG_VNODES once written, while the topics stay described by the unsharded metadata nobody would read again, so the sweep would take their segments. Converting a control plane in place is not supported. The refusal is made twice, each with its own way out: before this node writes a seed (check_seed/3), when nothing was written and removing MALACHI_LOG_VNODES boots it unsharded again; and once the topology is known (check/4), for a sharded ring already recorded (seeded by another node, or by an earlier release that converted control planes in place, or by an earlier release on this node under another cluster name over the same ra directory), which no setting undoes and which only forming the cluster again gets past.

The checks run in steps, because the boot starts the ring store before it can tell whether the control plane is sharded. check_ring/4 runs before the boot touches the ring store, so its refusal leaves nothing behind: had the ring store been formed and the start then refused, a later attempt could find it registered and pass, depending only on whether ra's directory reached the disk before the halt. check_seed/3 runs once the ring store is started but before a seed is written, so its refusal leaves an empty ring store and no seed. check/4 runs once the topology is known, after the ring store was resumed or seeded, for everything that needs the topology.

decide_ring/1, decide_seed/1 and decide/1 are the decisions over plain facts; check_ring/4, check_seed/3 and check/4 gather them and act.