Storage and runtime
Before taking over a data disk
Seeing an existing disk does not establish that its data can be written again. FoundationDB and Yaostore illustrate which ownership records to retain, how to settle prior writers and when writing may resume.
What remains unknown after contact is lost
A database or object-storage process can continue while its controller cannot reach the node. A new node association, an expired report or a timed-out call changes management observations. None proves that the previous process exited or stopped writing through another device alias.
Takeover requires three independent premises: device and member ownership match retained expectations, previous writers have ended, and the current owner maintains exclusion. Only when all three hold may the existing data be reopened for writing; a separate readback then checks its contents. One management status cannot establish all these facts.
FoundationDB preserves logical volumes and native state
Every FoundationDB volume carries cluster, logical-machine and volume ownership fields. Ordinary restart preserves them together with each process’s data and log directories. The node first inspects ownership on the exact device through a read-only view, then reopens the owned XFS volume for writing only after admission.
The native cluster connection file is persistent state maintained by FoundationDB itself. The controller’s bootstrap seed for new clients does not overwrite an existing file. A damaged marker or connection file blocks normal startup and requires explicit repair; apparently empty process directories provide no initialization authority.
Yaostore compares old disks with independent expectations
Adopting an existing member of the RustFS object-storage engine requires independently retained expectations: physical identity, disk and partition UUIDs, filesystem UUID, pool, deployment, drive identity, set and position within that set. The node Agent compares those values before custody is committed. Adoption performs no formatting.
This differs from an ordinary restart under existing custody. Taking over with a fresh controller also requires the original credentials and ordered pool layout, with old management and writer responsibilities settled before explicit adoption and recovery. Recovery applies a stopped configuration; a separate Start authorizes serving.
| Question | FoundationDB | Yaostore |
|---|---|---|
| Who owns the volume? | Cluster, logical-machine and volume marker | Physical, partition, filesystem and native-member expectations |
| What is preserved? | Process directories and native connection file | Disk identities, member layout and object content |
| What does control state establish? | Current declaration and node reports | Registration, custody and configuration application |
| Who supplies exclusion? | Volume owner and actual host owner | Node owner and actual host owner |
A new controller needs three separate decisions
For an explicit Yaostore takeover, retain independent member expectations and a known object, then settle former management and actual writers. Adopting the disks establishes custody without formatting. Topology recovery first applies a complete stopped configuration; starting service requires separate authority.
This separates recognition of the original disks, configuration application and readable original content. Missing observations remain unresolved at their own stage. A new process, an arbitrary successful S3 response or a saved-configuration status cannot replace comparison with the independently retained object bytes.
Recognize the original members
Compare current devices with retained identities, sets, positions and original credentials.
Apply the complete configuration
After prior writers settle, recover the original layout while retaining stopped intent.
Start and read back
After explicit startup, read the known version through the object interface and compare exact bytes.
Correct readback supports preservation
An independently retained object version and bytes supply the expectation after takeover.
Control records do not establish writer exclusion
Configuration, heartbeats and reports alone cannot prove that previous writers ended.
Initialization requires a different grant
Both designs distinguish initialization from reuse. FoundationDB explicitly formats a selected volume on a disabled node, establishes a control connection file when applicable, then persists its ownership marker last. Yaostore fixes new identifiers for the authorized whole disk before partitioning, formatting and observing the result.
A timeout does not revoke effects that may already have happened. FoundationDB does not automatically redeliver initialization after result loss; Yaostore retains the original work or result for a repeated action identity. Both retain ownership of unfinished tools, IO and mounts, and require conflicting work to settle before a new destructive decision.
Make preservation an independent observation
For FoundationDB, the specified checks reopen owned volumes containing known data and compare retained process directories and a native-updated connection file. Incorrect markers or insufficient read-only ownership evidence should prevent premature writable mounting.
For Yaostore, keep a known object version and complete member expectations, then read back the exact bytes through the S3 object interface after restart, controller reopen and explicit takeover. Delaying a former writer or supplying an incorrect expectation checks waiting and rejection separately. Configuration commitment, process startup and correct data readback remain three independent pieces of evidence.