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.

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.

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.