GitHub 上的 philipl/pifs 项目近日重新被开发者讨论。这个名为 πfs 的项目自称“把数据存进 π”，以 FUSE 文件系统形式挂载使用，口号是再也不用担心硬盘空间，因为圆周率里包含所有可能文件。

这不是存储革命，而是一个认真写出来的技术玩笑。πfs 的价值不在于能省硬盘，而在于它用一个荒诞但可运行的原型，把“100% 压缩”“数据天然存在”“元数据比数据更重要”等说法推到极端，让人看清其中的逻辑漏洞。

πfs 解决的不是容量问题，而是拿容量问题开刀

πfs 的 README 写得像一份夸张的产品发布稿：既然 π 可能包含所有有限数字序列，那么文件也可以被视为 π 中的一段数字；只要记录位置和长度，就能在需要时把文件取回来。项目页面还提示，更新的“data-free filesystems”实验可看 philipl/inferencefs。

从使用方式看，它确实不是纯段子。πfs 通过 FUSE 挂载成本地文件系统，构建前需要 autoconf、automake、libfuse 等依赖；运行时需要指定 metadata directory 和 mountpoint。这个 metadata directory 才是关键，它保存文件名、长度和字节位置等信息。

说法πfs 的实际做法判断
数据存进 π按字节在 π 中查找位置数据没有被写入 π，只是被索引化
100% compression保存大量元数据不是严肃压缩成果
文件永不丢失丢了位置仍无法恢复原文件可恢复性依赖元数据
无限空间查找代价极高容量叙事掩盖了计算成本

这里的讽刺很锋利：很多系统设计讨论里，“数据”和“元数据”会被人为切开，好像元数据天然轻盈、便宜、可靠。πfs 正好反过来，它把数据变成位置描述，最后得到的却是一堆必须妥善保存的元数据。

核心假设卡在数学和工程之间

πfs 的数学前提是：π 可能是 normal number，即在某种进制下各类数字序列均匀出现；如果它还是 disjunctive sequence，所有有限序列都能在其中出现。问题在于，π 是否正规数至今没有被证明。

即便暂且接受这个猜想，工程问题也没有消失。README 提到可用 Bailey–Borwein–Plouffe 公式提取 π 的指定位置数字，也承认寻找长序列会很慢，所以实现里干脆按单个字节查找。这样做降低了查找片段的难度，却把元数据规模推高。

这和现实世界里的压缩、去重、内容寻址存储形成了清楚对照。gzip、Zstandard 这类压缩工具利用数据规律减少表示长度；Git、IPFS 这类系统用哈希定位内容，但内容本身仍要被保存或由网络节点提供。πfs 则把“内容存在于某个数学对象中”当成前提，工程上只保存索引。它有形式上的文件系统接口，却没有现实存储系统最在意的吞吐、可靠性和恢复路径。

开发者该把它当成反例教材，而不是新型文件系统

受影响最多的不是普通用户，而是会阅读 README、会尝试 FUSE、会被“极限压缩”概念吸引的开发者。对他们来说，πfs 值得跑一遍，但不值得拿来保存任何需要负责的数据。README 自己也承认性能很慢，甚至用“还有摩尔定律”来玩笑式回应；其中还提到“cloud based π lookup”“πfs for Hadoop”等未来方向，语气本身已经说明它不是商业路线图。

真正该观察的也不是 πfs 会不会成熟，而是类似叙事在技术行业里为何总能复活。AI、存储、区块链和数据库领域都曾出现过“只保存索引”“数据天然可推断”“去中心化后存储近乎免费”的乐观表述。πfs 把这些说法浓缩成一个荒诞样本：只要忽略查找成本、证明缺口和元数据负担，任何系统都可以看起来像魔法。

对开发团队而言，这个项目的现实提醒很简单：评估存储方案时，不要只问“数据放在哪里”，还要问“索引有多大、重建要多久、丢失后谁负责”。πfs 的答案几乎都不合格，所以它才是好玩且有用的反面案例。