Introduction
LoonFS is an open-source cloud filesystem built on object storage, with transactional, globally consistent namespaces.
LoonFS is an open-source cloud filesystem built on object storage. LoonFS namespaces are transactional and globally consistent, using object storage as both durable storage and the coordinating authority.
Use LoonFS via the CLI, the embedded Rust engine, the remote Rust client, or the API. Common filesystem operations are supported for files and folders — create, move, copy, and delete — along with stat, list, attributes, revision history, trash recovery, point-in-time snapshots, a changefeed, and content search (grep).
Changes to files and folders in a namespace are recorded as atomic commits in an append-only write-ahead log, and clients can batch operations within a commit for atomic transactions in advanced use cases. Commits are acknowledged only once durable, and filesystem operations support flexible preconditions for greater consistency.
LoonFS is not, and does not attempt to be, POSIX compliant. LoonFS is focused on exceptional performance and scalability as a cloud filesystem.
LoonFS stores both content and metadata on object storage. Metadata is indexed for scalable performance of all filesystem operations, even as a namespace grows to millions of files and revisions.
LoonFS can be embedded or hosted on a server. This makes LoonFS particularly well suited for developers who need to embed a native cloud filesystem as part of their platform.
Advanced permissions (ACLs) and open sharing are not part of the current release.
Features
Section titled “Features”- Embedded or server hosting – LoonFS can run in-process against object storage, even among concurrent readers, or a single host can serve many readers and concurrent writers.
- Object-store durability – object storage is the only durable dependency. Server memory and the optional SSD cache can always be rebuilt from this durable state.
- Transactions – all operations are serialized as commits to a WAL with optional preconditions, supporting flexible transactions and replay.
- Stable identity, snapshots, and history – opaque inode IDs remain intact across moves, leased snapshots provide point-in-time reads, content revisions preserve file history, and trash entries can be restored.
- Read acceleration and search – derived metadata and optional grep indexes accelerate reads without sacrificing correctness.