我计划在 50 TB RAID6 阵列上使用 btrfs，并且我想启用 lzo 压缩。
这是针对生物信息学设置的，其中会在大型（1 TB - 20 TB）文件中进行大量搜索。（软件仅获取分散在文件中的小块数据）。
让我担心的是，我不明白在 btrfs 等压缩文件系统上如何执行寻道。是否需要先将文件从头解压到所需位置？这会对我的设置产生巨大的负面影响。
或者更普遍的问题是：寻道时间是否与文件大小成比例，与非压缩文件系统相同，还是会变得更糟，例如 O（file_length）
答案1
随机寻道时间与未压缩的文件系统一样，大约为 O(1)，但需要注意的是，最多 128 KiB 的数据被压缩在一起，因此要读取单个字节，必须读取并解压缩该 128 KiB 块中的所有数据。根据访问模式，这可能会对性能产生相当大的影响，但您需要使用特定应用程序和数据集对此进行基准测试。
（来源）
答案2
互联网上以及 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 级压缩，您可以保留查找，但会损失一些压缩性。
另外，块级/文件系统压缩通常（并且历史上）被禁用的原因是它会增加文件内的碎片，尤其是在文件写入中间。对于旧驱动器或带有数据库文件的驱动器，碎片本身可能会导致性能下降（对于 ssd 来说仍然如此，但这是因为它重写/擦除块周期，而不是因为线性移动的读取头）。如果这是一个巨大的生物信息流，那么中间写入可能不是问题。
一般来说，寻道时间与 inode 和文件系统布局有关。而不是文件大小。例如，如果您有两个文件，较大的 X 和较大的 Y，它们都不适合磁盘预读和缓存，也无法在单个 inode 读取中读取，则到达 X 中的位置 x 的时间大约等于到达 Y 中的位置 y 的时间，其中 x < y 。有些情况下它们可能看起来不同，但那些是由于其他不受控制的因素，比如旋转盘片上的旋转位置。或者文件 X 和 Y 被打开并作为流读取。然后必须读取直到位置 x 的所有内容 X，Y 也是如此。但这不是文件系统的功能。直接对不同文件位置执行 fseek() 命令将显示相似的寻道时间。（再次依赖于盘片上的位置）。
嗨嗨。