Met*_*Met 4 performance compression btrfs
我计划在 50 TB RAID6 阵列上使用 btrfs，并且我想启用 lzo 压缩。
这适用于生物信息学设置，其中会在大型 (1 TB - 20 TB) 文件中进行大量搜索。（该软件仅获取分散在文件中的小块数据）。
让我担心的是，我不明白如何在像 btrfs 这样的压缩文件系统上执行搜索。文件需要从头解压到抢手的位置吗？这将对我的设置产生巨大的负面影响。
或者一个更普遍的问题：文件大小的搜索时间比例是否与非压缩文件系统相同，还是变得更糟，例如 O(file_length)
互联网上和 Stackoverflow 上有很多关于 FS 压缩的错误信息。文件系统压缩是在块级别（或块级别，取决于设备）完成的，而不是在文件抽象级别完成的，因此表面上的查找是相同的——文件查找是根据块完成的，而不是根据压缩位完成的。这意味着压缩本身不会暴露给用户级程序。因此，您不必考虑或担心。
一种“超级简单”的可视化方法：x/0 是块，文件中的块组。未压缩的文件和块：[xxx][xxx][xxx][xxx] 压缩文件和块：[xx]0[xx]0[xx]0[xx]000 事实上它不是那样的，但是文件 inode 将指向压缩块并透明地忽略文件不需要的空间。
原则上，目前没有理由不启用 fs-compression。除了少数例外情况外，fs-compression 的性能严格优于未压缩的读取。对于我也使用过的生物信息数据，您有时希望最大化读取带宽，而压缩将实现这一点——即未压缩的数据读取速度将超过控制器+接口的限制。（在 sata III/raid 的 N 个压缩位变为 N * 压缩比位）。不要理会人们所说的关于延迟、降低处理器速度等的任何废话。CPU 比磁盘读取快 1000 倍。
对于一些性能基准，这里：http : //www.phoronix.com/scan.php? page=article&item=btrfs_lzo_2638& num=2
如果我们将文件级压缩（即 gzip 或 xz 等）与文件系统级压缩混合使用，则会出现另一个混淆。在这些情况下，是的，文件搜索是不确定的，如果不解压缩先前的字节流只是为了定位文件中的字典定义偏移，则文件中的绝对数据位置不是严格可用的。因此，使用 fs 级压缩，您将继续寻求损失一些可压缩性。
顺便说一句，通常（和历史上）禁用块级/fs 压缩的原因是因为它会增加文件内的碎片，尤其是中间文件写入。对于旧驱动器或带有数据库文件的驱动器，碎片本身会导致性能损失（对于 ssd 仍然如此，但由于重写/擦除块循环，而不是因为线性移动读头）。如果这是一个巨大的生物信息流，那么midwrites 可能不是问题。
通常，查找时间尺度是 inode 和文件系统布局的函数。不是文件大小。例如，如果您有两个文件，大尺寸 X 和更大尺寸 Y，它们都不适合磁盘预读和缓存，也不能在单个 inode 读取中读取，那么到达 X 中位置 x 的时间大约等于到达 Y 中位置 y 的时间，其中 x < y 。在某些情况下它可能看起来不同，但这些都是由于其他不受控制的因素，例如旋转盘上的旋转位置。或者文件 X 和 Y 被打开并作为流读取。然后所有 X 到 pos x 都必须被读取，Y 也是如此。但这不是文件系统的功能。直接进入不同文件位置的 fseek() 命令将显示相似的查找时间。（再次取决于盘片的位置）。
哈。