estimated visitors
Introduction · 2 MIN READ
A Working Set Before a Storage Service
Qualifying the boundary between local durability and object-backed storage.
A server can run short of useful local storage long before its data stops growing. Moving everything to remote storage creates a different problem: applications still need predictable filesystem behavior, and frequently used data benefits from staying close. Accretion Disk File System explores the boundary between a durable local working set and a larger object-backed namespace.
A storage fabric with explicit boundaries
The prototype combines an upstream filesystem engine with a qualification lab and a Python access-heat controller. JuiceFS supplies filesystem and metadata behavior, PostgreSQL holds metadata, and an S3-compatible fixture supplies object storage. The controller observes approximate local access and manages clean cache residency through the engine's own operations.
Local staging retains writes awaiting upload. Clean cache holds data that can be fetched again. Treating both as disposable would erase the distinction on which recovery depends. The selected prototype adds staging durability barriers and structured cache telemetry to a pinned JuiceFS build.
What the prototype has demonstrated
Qualification on Pyrophone exercised filesystem semantics, bounded local capacity, delayed uploads, process restart, guest power loss, range reads, cache controls and restoration into a separate database and object bucket. A patched client retained acknowledged staging through the tested guest crash and replayed it after reconnection. The unmodified client failed that specific experiment.
These findings belong to the tested versions and configurations. They do not establish that every upstream configuration behaves the same way, or that the prototype is production ready. Cache warming also has a cost: in the synthetic comparison it improved hot reread behavior while increasing total backend traffic.
From one-host experiment to infrastructure component
The prototype manages one writable client. Its fixture, metadata and recovery copies remain on one physical host. It has not established independent backups, multi-host fault tolerance, offline mutation or multi-writer coherence. Losing staging before upload can still lose pending data.
The immediate step is development infrastructure: a private central repository, protected pull requests, reproducible Python checks and visible project progress. Storage deployment across servers comes later, with its own durability, recovery, capacity and operational acceptance. Accretion Disk is an experiment in making those boundaries measurable before applications depend on them.
PROJECT