数据压缩/压缩文件系统
待办事项:这本书中是否有更好的地方来讨论压缩文件系统和闪存?
许多数据压缩算法是面向整个文件的。他们假设整个原始文件可以从一开始就获得,并且人们将希望从头到尾解压缩整个文件。
压缩文件系统(尤其是闪存文件系统)打破了这种假设。ZFS 文件系统使用 LZJB 压缩算法。许多互联网路由器和互联网防火墙使用压缩闪存文件系统,通常是 cramfs 文件系统。(参见 逆向工程/文件格式#压缩、加密和混淆 的示例)。一些“固态硬盘”(SSD)在内部使用压缩算法来减少文件占用闪存的“使用量”——这实际上不会给用户带来更多存储空间,但更大的空闲存储空间可以在内部由 SSD 以延长驱动器寿命的方式使用。
这些系统需要相对快速地随机访问存储在文件系统中的数据——从头开始解压缩会太慢。
一种方法是使用一个索引,给定我们想要查找的某个文件名(或“逻辑块号”),它会告诉我们确切地在磁盘上的哪个位置(或在批量闪存中)开始解压缩,以及一个流压缩算法——这样解压缩器可以跳到压缩数据的中间并从那里开始解压缩。
这些系统的一个更难的要求是允许编辑文件。(这太难了,以至于一些压缩文件系统,比如 cramfs,比如 python 可执行 zip 文件[1],不允许这样做——它们必须从未压缩文件的目录一次性创建。创建 cramfs 系统后,它只能以只读方式挂载)。
压缩文件系统的最早应用是为了让人们能够将更多数据存储在当时可用的相对较小、昂贵的存储系统中。
正如我们在 数据压缩/评估压缩效果 部分提到的,有些人即使在有足够的 RAM 和磁盘空间,不需要真正缩小文件的情况下,也会使用数据压缩技术。例如,设计视频游戏的人员通常希望在加载下一个关卡时,能够快速从存储器中加载大量数据。如果我们使用一些简单的数据压缩技术来稍微减小磁盘上的字节数,我们可以将节省的时间的一部分用于解压缩,并且仍然会得到好处。[2]
许多人已经构建了一个实际上是虚拟文件系统的东西,它可以读取和写入标准的“.tgz”或“.zip”文件:TrueZIP,[3] Java Zip 文件系统提供程序,[4]等等。
待办事项:更详细地说明为什么未修改的面向文件的压缩算法不适用于压缩文件系统,以及使用哪些技术来 (a) 修改这些算法以使其适用,或者 (b) 其他对压缩闪存文件系统有用的算法,或者 (c) 两者的结合。
待办事项:说几句关于 w: SquashFS 的。
待办事项:说几句关于 w: initramfs/w: initrd 的。
待办事项:说几句关于 zswap 和 zRAM 以及与虚拟内存压缩相关的类似想法的。
… 使用 lz4(lzo 的变体)…
- ↑ Radomir Dopieralski. "将您的 Python 应用程序作为单个文件"
- ↑ Malte Skarupke. "从磁盘快速加载东西".
- ↑ TrueZIP https://truezip.java.net/
- ↑ Java Zip 文件系统提供程序 http://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html