pi-fs: the filesystem that stores your files in the digits of pi

What pi-fs actually does with your bytes

pi-fs is a FUSE filesystem built around one observation: pi is conjectured to be normal, and if it is, its hexadecimal expansion is a disjunctive sequence, meaning every finite sequence of digits appears somewhere in it. The README states that the first record of this observation dates to 2001. From there the project takes a leap: if every possible file already exists inside pi, why store the file at all? Instead of writing your data to disk, pi-fs writes down where in pi your data lives.

The audience is narrow. This is not a storage product for people who are running out of disk. It is for readers who want to see a FUSE mount backed by a number-theoretic lookup, and for anyone who has argued about what 100% compression would even mean. The README is honest about the framing: it calls the project a prototype and points at https://github.com/philipl/inferencefs/ as the successor.

Metadata directory, byte-by-byte lookup, and the BBP formula

The architecture has two halves. The mountpoint behaves like an ordinary filesystem, and a metadata directory (given as mdd=<metadata directory>) holds the filenames and the locations of your files in pi. The README is explicit that the metadata is the part that takes real space: "you've obviously got to write them down somewhere."

Lookup is done with the Bailey-Borwein-Plouffe formula, which can extract a digit of pi without computing all the digits before it. That is the mechanism that makes the joke technically coherent: given an index and a length, you can pull the bytes back out. The README notes that finding a long sequence of digits in pi takes a while, so this implementation breaks files into smaller chunks. It goes further than you might expect: "we consider each individual byte of the file separately, and look it up in pi." One byte at a time is the design, and it is also the reason the filesystem is unusable for real workloads.

Building pi-fs on Debian and mounting it

The README gives the build dependencies and the autotools sequence. On Debian the packages are autotools-dev, automake and libfuse-dev:

sudo apt-get install autotools-dev
sudo apt-get install automake
sudo apt-get install libfuse-dev

After that, the build is the standard autogen, configure, make, make install sequence from the repository root:

./autogen.sh
./configure
make
make install

The mount command takes the metadata directory and a mountpoint. The README shows the form with a lowercase pi character as the binary name:

πfs -o mdd=<metadata directory> <mountpoint>

Replace the placeholder with a real path, for example a directory under /tmp, and point the mountpoint at an empty directory. Once mounted, reading and writing happen through the mountpoint while the metadata lands in the mdd directory. Expect the first write of a text file to take minutes, not seconds; the README's own example says five minutes for a 400 line text file. If the mount is not visible, check that fuse is installed and that the mdd path exists and is writable before mounting.

Where pi-fs falls over

The README answers its own hardest question. Asked why the thing is slow, it says this is an initial prototype and adds "there's always Moore's law." That is the whole performance story. Storing a 400 line text file took five minutes according to the README, and the byte-by-byte lookup means the cost scales with file size in the least forgiving way possible.

The second failure mode is metadata loss. The README asks what happens if you lose your file locations and answers that the locations are just metadata, so your files are "still there, sitting in π." That is true in the mathematical sense and useless in practice: without the index, you have no way to find the byte offsets again, and no recovery tool is documented. The README does not document rollback, backup, or a repair path for a corrupted mdd directory.

A third limitation is scope. This is a prototype with a list of future ideas (variable run length search, arithmetic coding, parallel lookup, cloud-based pi lookup, pi-fs for Hadoop). None of those are described as implemented. Treat the list as a wish list, not a roadmap. If you need a working FUSE filesystem to learn from, this one will teach you about lookup cost more than about storage.

inferencefs and the honest alternative

The README opens with a pointer: "Check out https://github.com/philipl/inferencefs/ for the latest in data-free filesystems!" That is the author's own recommendation, and it is the most useful line in the document. The difference in approach is not a different compression trick; it is a different source of data. Where pi-fs indexes into the digits of pi, inferencefs is the successor project the same author points readers toward. The README does not describe inferencefs's internals, so the honest statement is that the author moved on and left a link.

If what you actually want is a small FUSE filesystem to read and modify, the alternative is a conventional FUSE example that stores real bytes on disk, or a passthrough filesystem. Those give up the joke and the mathematical premise, but they keep your data. pi-fs is the right tool only when the premise itself is the point.

Licence and the cost of keeping it running

pi-fs is GPL-3.0, and the repository carries the usual files for that: COPYING, AUTHORS, ChangeLog, INSTALL, NEWS, Makefile.am, configure.ac, autogen.sh and a src directory. If you link this code into your own program or ship a modified binary, the GPL-3.0 obligations follow the derivative work. That is a description of the licence file in the repository, not legal advice; read COPYING and talk to a lawyer if the distinction matters to you.

Upgrade cost is low in the sense that there are no retrieved releases to track, so there is no version churn to manage. It is high in the sense that the build depends on autotools and libfuse, and the last push to the repository was on 2026-04-01. That is roughly six months before today's date, which puts it at the boundary where a project stops looking current. The README's own redirect to inferencefs suggests the author's attention is elsewhere. Budget for the possibility that a libfuse or autoconf change breaks the build and nobody upstream fixes it.

Editorial conclusion

pi-fs is a working joke, not a storage layer. Install it if you want to see a FUSE mount whose reads resolve through pi, or if you are teaching how disjunctive sequences and metadata-only filesystems behave. Do not put anything you care about on it: the README itself reports that storing a 400 line text file took five minutes, and losing the metadata directory does not magically recover the file. Before mounting, verify that libfuse-dev is installed, that the mdd path is on a filesystem you can inspect, and that you have time to wait for a write. The project's own pointer to inferencefs is a clearer signal than any benchmark: the README says to check out the successor for the latest in data-free filesystems.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. philipl/pifs on GitHub
4. README