The aim is to provide a kernel-style filesystem storage subsystem in user space, built around an asynchronous native API rather than a synchronous one. Where a kernel exposes a synchronous POSIX interface and keeps the rest internal, Chimera’s foundation is the async VFS, and the POSIX-style surfaces are thin wrappers over it.
That VFS, at the center of the diagram, is the operation set every other component uses. It is modeled on what the NAS protocols request — file handles, dispositions, leases, compound sequences, server-side copy — rather than a POSIX subset, so POSIX is one consumer of the VFS rather than the interface everything is reduced to. Everything else in the diagram plugs into that core.
A shared set of caches — attribute, open-file, and name — sits on the VFS and is common to every protocol surface. Because all protocols go through the same VFS, coherency and metadata state are kept in one place rather than per-protocol. A unified data cache is planned.
The server surfaces are the NAS protocols Chimera serves on the network:
nfs, smb, and s3. Each is a frontend that
translates wire requests into VFS operations.
The client surfaces let an application use storage through the same VFS,
in-process. A posix C API and an async C API exist today;
virtiofs, fuse, and GPU Direct Storage are planned. These
let an application link a NAS client as it would any other library.
The storage backends implement the VFS against real storage. memfs,
demofs, cairnfs, posix, io_uring,
and an nfs re-export backend exist today; smb,
virtiofs, and fuse re-export backends are planned. A
backend advertises which operations it serves natively, and the VFS supplies the
rest.
The modules in the tree are reference implementations, not the limit of the system. The hub-and-spoke shape exists so that the client surfaces and storage backends are plug-in points: your distributed filesystem, object engine, or in-house client attaches at the back-end or client API and then speaks NFS, SMB, and S3 through the same VFS.
Chimera is licensed LGPL-2.1 to make this practical. You can link your own components, including proprietary or differently licensed ones, against Chimera without that linkage placing Chimera’s license on your code. The protocol core stays open; the engine you attach to it stays yours.