Generative File Systems

• Generative File Systems are systems that automatically implement file systems from high-level, machine-readable specifications using LLMs and algorithmic synthesis.
• The SYSSPEC framework and SimFS model showcase applications where formal specifications drive module synthesis and dynamic simulation, ensuring correctness and scalability.
• These approaches reduce developer effort, enable modular evolution through patch mechanisms, and provide measurable improvements in performance and maintenance efficiency.

A generative file system is defined as a system whose implementation and ongoing evolution are produced automatically from high-level, machine-readable specifications rather than through manual programming. The term encompasses two principal paradigms: (1) synthesizing file system code using LLMs directed by formal specifications, and (2) virtualizing persistent data by generating file content on-demand, either through deterministic simulation (re-simulation) or algorithmic synthesis. These approaches address the growing complexity and scalability requirements of file systems, offer improved evolvability, and leverage advances in both AI and data virtualization (Liu et al., 15 Dec 2025, Girolamo et al., 2019).

1. Formal Specification–Driven Generative File Systems

A generative file system, as articulated in "Sharpen the Spec, Cut the Code: A Case for Generative File System with SYSSPEC" (Liu et al., 15 Dec 2025), utilizes LLMs to synthesize the entire file system implementation from a high-level formal specification. Unlike traditional, hand-coded file systems, this paradigm re-centers developer effort on writing unambiguous specifications that encode correctness, modularity, and concurrency properties.

Motivation

File systems are subject to chronic feature evolution, maintenance, and adaptation to new hardware. Longitudinal study of the Ext4 file system reveals that over 82% of commits are for bug fixes or maintenance, not new features. Manual code maintenance becomes increasingly impractical at this scale, while modern LLMs excel at code generation, refactoring, and repetitive updates.

Main Challenges

1. Natural Language Ambiguity: Expressing intricate invariants (such as on-disk consistency and concurrency protocols) in natural language is inherently ambiguous for LLMs.
2. Modular Composition: LLM context window constraints can cause interface mismatches and integration errors across independently generated modules.
3. LLM Hallucination: LLMs may omit logic paths, mishandle locks, or violate invariants, even under precise prompting.

2. SYSSPEC Framework Architecture

SYSSPEC is a multi-part specification framework for guiding LLM-based synthesis of file system modules. Each module is defined by three distinct specification facets:

• Functionality Spec: Hoare-style preconditions, postconditions, and global invariants. For instance, the invariant $$\forall\,\mathit{fsState}\;.\;\mathit{root\_exists}(fsState)$$ is globally enforced.
• Modularity Spec: Rely/Guarantee contracts precisely delineate permissible inter-module dependencies and provided guarantees, enabling bounded module contexts and rigorous interface checks.
• Concurrency Spec: Locking protocols and ordering constraints are explicitly defined and decoupled from core logic, enabling correct and efficient automated lock insertion.

A typical SpecFS is formalized as:

$$\begin{array}{rcl} \mathit{SpecFS} & ::= & \{\; \mathit{Module}_1, \dots, \mathit{Module}_n\}\ \ \mathit{Module} &::=& \mathit{Name}\;\{\,\mathit{FuncSpec};\,\mathit{ModSpec};\,\mathit{ConSpec}\}\ \ \end{array}$$

This specification language ensures that correctness properties and contracts are universally and unambiguously enforced.

3. Safe and Modular Evolution with DAG-Patch Specification

Evolution is handled via a patch mechanism structured as a directed acyclic graph (DAG), where each node represents a local specification change (Δ-spec) and relies on the guarantees of its children. When extending functionality—such as adding extent support—new module behaviors are layered through a sequence of patches, each with clearly defined RELY/ GUARANTEE transitions.

• Locality: Each patch minimally affects the specification.
• Compositionality: Interface changes are isolated, and external module semantics are preserved.
• Invariant Preservation: Root nodes must reassert the global invariants, ensuring correctness is never retroactively compromised.

When integrating features—such as Ext4 features into SPECFS—only affected modules are regenerated, and global correctness properties are retained.

4. LLM-Driven Toolchain and Reliability Measures

The SYSSPEC toolchain comprises several specialized LLM-based agents:

• SpecCompiler: Conducts two-phase code generation. The first phase produces correct sequential code; the second phase instruments concurrency primitives per the Concurrency Spec.
• CodeGen/SpecEval Agents: A dual-agent approach separates code synthesis from formal conformance checking. Disagreements trigger iterative retries, with SpecEval providing concrete feedback (e.g., missing post-condition handling).
• SpecValidator: Subjects output to programmatic tests (such as xfstests).
• SpecAssistant: Orchestrates the developer-facing process, including auto-formatting of draft specs, invocation of SpecCompiler, and presentation of diagnostics for failed generations.

Hallucination is mitigated through agent separation, iterative feedback, and comprehensive regression testing.

5. Applications and Benchmarking

The major empirical validation is the generation and evolution of SPECFS, a FUSE file system that reimplements AtomFS (Liu et al., 15 Dec 2025). Key metrics include:

• Scale: 45 modules, ~4300 LOC of generated C, ranking mid-scale among Linux file systems.
• Correctness: Passes 690 out of 754 xfstests; failures are restricted to unsupported POSIX features.
• Generation Accuracy: State-of-the-art LLMs (e.g., Gemini-2.5) achieve 100% correct module synthesis using SYSSPEC, compared to 81.8% for baseline few-shot methods.
• Productivity: Feature additions require an order of magnitude less developer effort (e.g., rename with complex locking: 2.4h spec authoring versus 13h hand-coded).

Integration of ten production-grade Ext4 features (e.g., extents, delayed allocation, inline data, rbtree pre-allocation) into SPECFS demonstrates not only functional correctness but also measurable I/O, storage, and performance improvements.

6. Dynamic Content Generation in Simulation Data: SimFS

A complementary model of generative file systems is exemplified by SimFS (Girolamo et al., 2019). Here, files are not physically stored but generated on-the-fly by re-simulating scientific workflows. This "virtual" file system decouples logical file access from physical persistence, allowing storage-compute trade-offs.

System Design

• Middleware Layer: SimFS intercepts POSIX I/O via LD_PRELOAD, routing operations to a daemon responsible for cache management, metadata, and simulation job scheduling.
• Data Virtualization Model: Simulation data is split into timesteps, with checkpointing intervals ($\Delta d$, $\Delta r$) determining output and restart file schedules.
• On-Demand Content Generation: If a requested file is missing, SimFS identifies the nearest restart and replays the simulation forward to regenerate the needed file.
• Caching and Replacement: Policies (e.g., DCL, cost-aware LRU) balance cache hits against the computational cost of re-simulation.
• Prefetching: Agent-based clients analyze access patterns to proactively trigger re-simulation, masking queue latency and maximizing throughput.

Expected access time $T$ is modeled as: $$T = H \cdot T_\text{disk} + (1 - H) \cdot T_\text{sim}$$ where $H$ is the hit ratio, $T_\text{disk}$ disk I/O latency, $T_\text{sim}$ simulation latency.

Performance and Applicability

• SimFS yields cost reductions (30-60%) versus conventional on-disk or in-situ approaches for prolonged, multi-analyst workloads.
• Throughput increases of up to 2.4–3× are observed with advanced prefetching.
• Applicability extends to any deterministic, bitwise-reproducible simulation pipeline.

A plausible implication is that generative file systems, in the SimFS sense, provide a middle ground between compute-only and storage-only architectures, enabling scalable access to exascale scientific datasets.

7. Broader Implications, Limitations, and Outlook

Broader Implications

Generative file systems, via strong formal specifications or dynamic content synthesis, promise radically improved evolvability, correctness, and operational flexibility. The methodology described in SYSSPEC generalizes to other OS subsystems, including virtual memory and network stacks, using the same formal methods and LLM-guided synthesis (Liu et al., 15 Dec 2025).

Limitations

• Specification Overhead: Sufficiently precise specifications require significant formal-methods expertise and initial authoring effort.
• Generative LLM Constraints: Output quality and system reliability are bounded by LLM capabilities, availability, and cost.
• Operational Boundaries: Current implementations (e.g., SPECFS) are user-space only; production deployments require in-kernel adaptations.

Future Research Directions

• Extending generative synthesis and verification to kernel-space file systems, with crash-consistency and journaling.
• Integrating formal proof frameworks (SMT, Coq) for module-level correctness guarantees.
• Automatically extracting high-level specifications from legacy C codebases to bootstrap LLM-driven generative development.
• Generalizing to a “spec-driven” OS, with all critical subsystems synthesized, verified, and evolved from high-level specifications.

Generative file systems represent a reorientation from code-centric to specification-centric systems development and from persistent to recomputable data architectures, with implications for maintainability, correctness, and resource efficiency (Liu et al., 15 Dec 2025, Girolamo et al., 2019).