Contract and limits

This page says what to expect from a Mountable filesystem before you rely on it. Behaviour marked verified is shown by our automated tests, which mount filesystems on Linux. Behaviour marked not verified is how the service is built to behave, not yet covered by a test, and not a promise.

On one mount

One mount behaves like a local directory for these operations:

Across mounts

Several machines can mount the same filesystem at once. They do not share a local disk, and none of the following is verified by a test yet:

• Changes become visible eventually. A change made on one mount reaches the others after a delay we have not measured.
• No close-to-open guarantee. Opening a file right after another mount closed it can still show the old contents.
• Writers are coordinated per path, on a best-effort basis. A second mount that opens the same path for writing normally waits until the first writer closes it. Two names of a hard-linked file, a rename during an open write, or a writer that loses its lock can still produce two writers at once, and nothing stops a client that ignores the coordination.
• flock and fcntl locks are shared across Linux mounts.
• mmap with MAP_SHARED is coherent only within one mount.

Give each writer its own files, or coordinate writers outside the filesystem.

Not supported

• Changing a file's owner (chown) to another user.
• POSIX ACLs (setfacl).
• Device nodes, FIFOs and sockets. Creating a FIFO or a device fails (verified).
• Running setuid or setgid programs from a mount.
• File names that are not valid UTF-8, or longer than 255 bytes.
• Byte-level coherence between two writers of the same file, and a single order of metadata changes seen by every mount.

Durability

A file written, closed and synced is still there, byte for byte, in the next mount (verified). The rest of this section describes how the service is built; it is not yet verified by crash or fault-injection tests.

• The mount buffers writes and commits them to the service when a file is closed or fsynced. If a mount ends abnormally (its sandbox is killed or its session is revoked), writes not yet committed are lost.
• When fsync or close succeeds, the file's data has been written to disk with fsync on the server before the upload was acknowledged, and the file's entry has been committed to the database afterwards.
• The service keeps one copy of file data, on one server's disk. Backups are the only other copy: if that disk is lost, changes made since the last backup are lost.

Service stage

Mountable is in an early stage:

• One cell: the API and the storage run on one server, with their database on a second one.
• No high availability: if either server goes down, so does the service.
• Daily backups to separate cloud storage; restoring a backup has been rehearsed. To take a consistent backup, the service stops once a day until the backup is copied out. In October 2026 a whole backup run took under a minute; the pause grows with the data stored. What mounts see during the pause is not verified.
• No service-level agreement: no promised availability, recovery time or recovery point.

Quotas

Each filesystem has two quotas. By default they are 100 GiB of stored data and 1,000,000 entries (files, directories and links). The console and mountable fs usage show a filesystem's usage against them.

• Stored data. Space is reserved when an upload starts, so data not yet committed counts too. A write that would exceed the quota fails (verified); the exact error a program sees is not verified. Deleted data keeps counting for about a day. Data of a file that ever had a hard link keeps counting until the filesystem is deleted, even after every name is removed. Not verified.
• Entries are counted a few seconds behind, so the limit is soft and can be overshot slightly. At the limit, creating a new entry fails; replacing an existing one still works. Not verified.
• One file holds at most 9,999 chunks of up to 2 MiB, about 19.5 GiB. Not verified.

Known issues

• Renaming a directory that contains a hard-linked file fails. This is a bug in the underlying storage software, found by our tests.

Platforms

The mountable CLI is built for Linux and macOS on x86_64 and arm64. Mounting needs FUSE.