Plan 0021
The filesystem as a queryable database
Query all files or folders carrying a given xattr without traversing the tree: an incrementally maintained index makes attributes queryable the way a database queries columns. Prior art: flecs, files as entities, xattrs as components.
- Status
- Input wanted RFC
- Ambition
- 7 treats a core OS surface as an indexed store rather than a tree to walk
- Impact
- 6 every tool that currently walks the tree to find tagged things gets O(query)
- Effort
- 6 an incrementally maintained xattr index plus a query surface
- Risk
- 4 the index is derived state; worst case it is stale and rebuilt
- Maturity
- 1 idea stage
- Leverage
- 7 a query primitive other tools compose, not a feature
- Taste
- 7 the query model and what counts as a component is the design work
- Authors
andrewgazelka- Created
- Updated
- Tracking issue
- -
- Supersedes
- -
- Superseded by
- -
Summary
Finding every file or folder tagged with an xattr today means walking the whole tree and asking each entry, which is why nobody builds on xattrs. Make the filesystem answer like a database instead: an index, maintained incrementally from filesystem events, that answers “everything with attribute X” in query time rather than traversal time.
Example
A systemd service that keeps every repo on a machine fresh: query “every
folder containing .git” (or every folder deliberately tagged with a git xattr) and git pull each one every 30 seconds. Today that is a full
filesystem scan per tick or a hand-maintained list; with the index it is
one query, and newly cloned repos join automatically.
Prior art
flecs: entities with components, queried by component. Files are entities, xattrs are components; the same query model applies.
Drafted by Claude Code (Fable); comments wanted, hence the RFC flag.