Guarantees

This page states the behavior contract. It covers what mountOS promises, what governs each promise, and what is not supported.

POSIX semantics

A mount behaves like a local POSIX filesystem. Existing applications and tools run on it unchanged. One wire protocol drives every filesystem client. A volume behaves the same way on macOS, Linux, and Windows.

mountOS verifies compatibility with industry filesystem test suites. These suites include the pjdfstest POSIX compliance suite, the Linux Test Project (LTP) filesystem tests, the xfstests regression suite, and fsx I/O consistency runs under randomized operations. Together, they exercise file and directory operations, permissions, and read and write semantics. The IOR and mdtest workloads exercise the same surface under I/O and metadata load.

Data location

• A volume belongs to exactly one region. mountOS does not replicate data across regions.
• The region's database stores metadata durably. A metadata cluster serves it.
• File content stays durable in the storage the volume points to. It inherits that store's durability. The operator chooses the backend and can inspect it. An exclusive mount in writeback mode is an exception, as described under Exclusive mounts.

Availability

• Storage continues serving through some individual node failures. Fault tolerance is built into the parts that serve a volume. A metadata cluster keeps serving while a member is down, and a block storage copyset keeps serving while one of its pair is down.
• A HUB outage does not interrupt active sessions. Each client discovers the HUB once. After that, it talks to the owning metadata cluster for the life of the session. While the HUB is down, first-time discovery fails until the HUB returns. Previously mounted clients keep using cached topology.
• Registration self-heals. A misconfigured service starts. It refuses to register. It retries automatically until the topology is fixed. If a region or metadata cluster is mismatched or deactivated, it never registers.

History and retention

• Every file keeps a version history. The window defaults to one minute. An operator can set a shorter, sub-minute window per volume. Saves that land within the same window collapse to the last one.
• One retention window governs history. The volume's retention period sets how far back time travel reaches, how long deleted entries stay available, and when old versions age out. Within the window, every version and deleted entry stays accessible to open and copy out.
• An active fork holds its history. Data that the fork can still reach stays available until the fork ages out. After that, it ages out with the rest.

Fork isolation

• Writes on a fork stay on that fork. Shared data diverges only when it changes. The parent line never sees the fork's writes.
• Forks do not merge back. A fork is a fresh line of history.
• A temporary fork never writes file data to the backend. Its writes stay on the client's local disk. The writes disappear when the mount session ends.

Consistency across mounts

When a client makes a change, other mounts of the same volume see it. The owning metadata cluster serves metadata. File content stays immutable. As a result, mounts share one view. Workloads that want an ordered record of changes read the change-event feed. The feed is ordered per fork. It carries an explicit signal when a gap is possible. The writes of an exclusive mount in writeback mode reach other mounts when that mount ships them.

Exclusive mounts

• One writer per scope. An exclusive mount holds a file or a folder tree of a volume fork. Only that mount writes it. Other mounts of the fork read it and get EBUSY for a change in it.
• A take over keeps one writer. When a standby takes the scope over, the old holder refuses writes and unmounts. A stalled old holder cannot write after the new holder holds the scope. The new holder drops its caches before it writes, so the application runs its own crash recovery on the files.
• A standby joins only for a loss-free take over. The volume's metadata cluster must keep every acknowledged write on a take over. When the metadata cluster cannot show this, the operator can state it with --lossfree-takeover. If that statement is wrong, the last acknowledged writes can be missing after a take over.
• writethrough keeps an acknowledged write through the loss of the machine. The storage nodes hold the data, and the metadata cluster has recorded it, before the write is acknowledged. Standbys and every mount that is not exclusive use this mode.
• writeback keeps an acknowledged write through a crash, a reboot, or a power loss. The write is durable on the local disk of the holder when it is acknowledged. The holder ships it to the storage nodes afterward. A write that is still on the local disk is lost with the machine or its disk. The next mount of the same scope ships the remaining data.

What is not supported

• Cross-region serving. mountOS is region-based. One region serves each volume. mountOS does not replicate the serving path across regions.
• Sub-minute fork and time-travel points. Fork points and time-travel targets align to the minute floor. Content versions are a separate axis: their window is per volume and can go below a minute, as described above.