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, so existing applications and tools run unchanged. One wire protocol drives every filesystem client, and a volume behaves the same on macOS, Linux, and Windows.

Compatibility is verified with the industry filesystem suites. 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 exercise the filesystem surface, covering 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.

Where data lives

• A volume lives in exactly one region. No cross-region replication.
• Metadata is durable in the region's database and served by a Raft-replicated dataserv cluster.
• File content is durable in the storage the volume points at, and inherits that store's durability. The backend is infrastructure the operator chooses and can inspect.

Availability

• Metadata serving tolerates node loss by quorum. A three-node dataserv cluster tolerates one concurrent node loss. A five-node cluster tolerates two.
• A HUB outage does not interrupt active sessions. Clients discover at the HUB once, then talk to the owning cluster for the life of the session. While the HUB is down, first-time discovery fails until it returns, and previously mounted clients continue on cached topology.
• Registration self-heals. A misconfigured service starts but refuses to register, and retries until the topology is fixed. A mismatched or deactivated region and cluster pair never registers.

History and retention

• Every file keeps a version history at one-minute granularity. Saves that land within the same minute 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 the fork can still reach stays available until the fork ages out, then ages out with the rest.

Fork isolation

• Writes on a fork stay on that fork. Shared data diverges only when it changes, and 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 live on the client's local disk and vanish with the mount session.

Consistency across mounts

A change made through one client is visible to other mounts of the same volume. Metadata is served from the owning cluster and file content is immutable, so mounts share one view. Workloads that want an ordered record of changes read the change-event feed, which is ordered per fork and carries an explicit signal when a gap is possible.

What is not supported

• Cross-region serving. mountOS is region-based. A volume is served from one region, and its serving path is not replicated across regions.
• Sub-minute version granularity. Intermediate saves within a minute are not retained.