MoobFS

Native Linux kernel module · Experimental · Pre-release tag only

Agent memory
as plain files.

A stacked filesystem layer over ext4, btrfs or XFS that validates typed attributes on files, indexes them in RAM and answers attribute queries from the kernel, returning only what the caller is allowed to read. Research project; nothing here is production-ready.

Try it in a disposable VM →Explore the code ↗
The MoobFS layer between clients and a mature lower filesystemClients write files and typed user.moob.* attributes or issue a QUERY ioctl. The Linux VFS passes the operations to the moobfs layer, which validates attributes, keeps an in-memory index, authorizes each QUERY result with the caller's credentials and delegates I/O to the lower filesystem: ext4, btrfs or XFS on disk. Client writes a memoryfile + user.moob.* xattrs Client asks QUERYkind = decision AND score ≥ 40 Linux VFS MOOBFS LAYER · moobfs_layer.koValidate, index, authorize, delegatetyped attributes checked on write · in-RAM index rebuilt at mounteach QUERY result checked with the caller's POSIX credentials Lower filesystem: ext4, btrfs or XFSreal files, real xattrs, journal, reflink · readable without the layer One kernel series tested, in a VM. No performance numbers yet.
What exists today: M2 phases 2a–2e and M3 phase 3b, tested over ext4, btrfs and XFS in a QEMU VM.

The goal: persistent memory for agents.

Keep observations, decisions and task records available beyond a single conversation, as files any program can read.

MoobFS stores memories as ordinary files with typed extended attributes and lets a program ask, through one kernel call, which files match a set of attribute predicates. The operating system's permissions and ACLs decide what each caller sees, per result.

See what is done and what is planned →

Storage and context have distinct roles

The filesystem stores, validates and queries. The agent application selects what is relevant and assembles the context sent to the LLM.

There is no semantic or vector search in the kernel and no daemon. MoobFS does not assemble prompts or extend a model's context window; frameworks such as mem0, Letta or ai-memory are potential clients, not competitors.

For anything beyond a disposable VM today, SQLite or plain files remain the recommendation. Comparison and when not to use MoobFS ↗

Plain files.
Kernel-side queries.

Nothing is trapped: unmount the layer and the lower directory is a plain tree that grep, getfattr, git and rsync read without the module.

Attributes are real user.moob.* xattrs on the lower filesystem, one type byte plus a payload (string, int64, double, bool, time, raw). The layer refuses invalid encodings on write and keeps an index in RAM. QUERY takes up to four predicates joined by AND; GET_INFO reports the index state and the lower filesystem's capabilities.

Read the architecture overview ↗

Evidence, with its limits

Kernel answers are compared with a user-space oracle; two users on the same mount never see each other's memories, not even in counts; git and WAL-mode SQLite run unchanged on the mount; power-loss replay keeps every synced memory.

3lower filesystems validated
1kernel series tested
0performance numbers

Three kernel-side defects were found and fixed by the project's own tests. No external audit, no syzkaller, no full xfstests run. Nothing has been released.

Run it.
Inspect the evidence.

One command builds the tools and the modules and boots a disposable QEMU VM with the pinned Linux kernel. Docker supplies the toolchain; the host kernel stays outside the experiment. Never load the modules on a machine you care about.

Native test instructions →
git clone https://github.com/studiomoob/llmoobfs.git
cd llmoobfs
make vm-test

Requires Docker. Runs Debian kernel 6.12.111+deb13-amd64. A passing run ends with MOOBFS_VM_PASS, LAYER_LOWER_PASS for ext4, btrfs and xfs, MOOBFS_ACCEPTANCE_PASS and MOOBFS_LAYER_PASS; logs and environment details are written to build/vm/.

View CI runs ↗

Follow the construction.

Code explains what changed. Decisions and experiments explain why. Documents in Portuguese are marked.

Reproduce the tests →Build the tools, run the VM suite and read the markers.Architecture overview ↗Stacking, typed attributes, index, QUERY authorization, with source citations.FAQ →Twenty short answers, each naming its source file.Comparison and when not to use ↗Plain files, SQLite, FUSE systems and memory frameworks; what M4 must show.M2 specification ↗The stacked memory layer, in Portuguese.Architecture decisions ↗Native module, stacked layer over a mature filesystem, memory model. Portuguese.Engineering journal ↗Requests, changes, failed attempts, corrections and evidence. Portuguese.M1 on-disk format ↗The frozen read-only experiment kept as a regression.

Done with evidence.
Planned without dates.

  1. DONE · M1

    Native shared reads

    Read-only image, two inodes sharing one payload, 15 malformed images rejected; frozen, runs as a regression.

  2. DONE · M2 2a–2e

    Stacked layer, typed attributes, index, QUERY

    Pass-through over ext4, btrfs and XFS with fsx; typed user.moob.* validated in the kernel; in-memory index; QUERY and GET_INFO equal to the oracle; acceptance with git, SQLite WAL, dm-log-writes and dm-flakey.

  3. DONE · KASAN

    Instrumented kernel harness

    Upstream 6.12.112 with KASAN, UBSAN and lockdep runs the same suite weekly and on pull requests touching the layer.

  4. DONE · M3 3b

    POSIX authorization in QUERY

    Each result resolved with the caller's credentials; two users, ACLs, remount, idmapped and user-namespace mounts refused, race test; passed in the VM and under KASAN.

  5. PLANNED

    Remaining M3, M4 benchmark

    Identity convention end to end; benchmark harness with SQLite baselines and real clients. No number is published before a VM run with evidence.

  6. DEPENDS ON VALIDATION

    Persistence, batch calls, release

    Index persistence, QUERY_BATCH and READ_BATCH, a change cursor and any public release are conditioned on M4 results and the security roadmap.

Interactive plan: inputs, processing and outputs → · Full roadmap with journal links ↗

Help test the idea.

Bring a reproducible bug, a kernel or format review, or an independent reproduction of the VM suite. Contributions use English for code, commits and issues; documents may be in Portuguese or English. AI assistance is welcome with human review and honest test evidence.

Contribution guide →