philipl/pifs
GitHub: philipl/pifs
πfs 是一个趣味性 FUSE 文件系统，将文件内容「存储」在圆周率 π 的数字序列中，仅保留位置索引作为元数据。
Stars: 7486 | Forks: 299
## 查看
```
其中 _元数据目录_ 是 πfs 存储其元数据（例如文件名或你的文件在 π 中的位置）的地方，而 _挂载点_ 是你常用的文件系统挂载点。
## π 和我的数据有什么关系？
π（或 pi）是数学中最重要的常数之一，具有各种有趣的特性（你可以在 [维基百科](http://en.wikipedia.org/wiki/Pi) 上阅读相关内容）。
π 被推测具有的其中一个特性是它是 _正规数_，也就是说它的数字分布是均匀的，这意味着它是一个 _双蕴含序列_（disjunctive sequence），即所有可能的有限数字序列都会出现在它的某个位置。如果我们考虑 16 进制（hexadecimal）下的 π，很容易看出如果这个猜想成立，那么所有可能的有限文件必然都存在于 π 中。关于这一观察的最早记录可以追溯到 [2001 年](http://www.netfunny.com/rhf/jokes/01/Jun/pi.html)。
由此，我们很容易得出一个结论：如果 π 包含了所有可能的文件，那我们为什么还要浪费 EB 级的空间去存储这些文件呢？我们完全可以直接在 π 中查找它们！
## 所有可能存在的文件？
没错！你曾经创建的、或者任何人已经创建或将要创建的每一个文件！版权侵权？它只不过是 π 的几位数字而已！它们一直都在那里！
## 但是我该如何在 π 中查找我的数据呢？
只要你了解你的文件在 π 中的索引及其长度，使用 [Bailey–Borwein–Plouffe 公式](http://en.wikipedia.org/wiki/BBP-type_formula) 提取文件就是一项简单的任务。
同样，你也可以使用该公式来初步找到你文件的索引。
现在，我们都知道在 π 中寻找一长串数字可能需要一段时间，所以出于实用原因，我们应该把文件分解成更容易找到的、更小的数据块。
在这个实现中，为了实现性能最大化，我们分别单独考虑文件中的每一个字节，并在 π 中进行查找。
## 那么我已经在 π 中查找到了我的字节，但我该如何记住它们的位置呢？
很明显，你得把它们记在某个地方；你可以用一张纸，但还记得我们通过将数据移入 π 而节省的所有存储空间吗？我们为什么不把文件位置也存储在那里！？！更好的是，我们的文件在 π 中的位置就是元数据，而且正如 [我们都知道的](http://datatechnologytoday.wordpress.com/2010/09/07/on-the-importance-of-metadata/)
元数据在我们所做的每一件事中都变得越来越重要。生成了这么多元数据，感觉是不是很棒？既然你可以只处理元数据（而且是大量的元数据），为什么还要把时间浪费在老式的数据上呢！
## 是的，但如果我弄丢了文件位置会怎样？
没问题，位置仅仅是元数据！你的文件还在那里，安然无恙地待在 π 中——它们永远不会消失，不是吗？
## 为什么这东西这么慢？我花了五分钟才存了一个 400 行的文本文件！
嗯，这只是一个最初的原型，别担心，还有摩尔定律呢！
## 我们接下来会走向何方？
未来充满了潜力！
* 可变游程长度搜索与查找！
* 算术编码！
* 可并行化查找！
* 基于云端的 π 查找！
* 用于 Hadoop 的 πfs！
标签：FUSE, 客户端加密, 文件系统, 虚拟文件系统, 趣味项目