通常，寻道时间随 inode 和文件系统布局而变化。不是文件大小。例如，如果你有两个文件，大尺寸 X 和大尺寸 Y，它们都不适合磁盘预读和缓存，也不能在单个 inode 读取中读取，那么到达 X 中位置 x 的时间大约等于到达 Y 中位置 y 的时间，其中 x < y 。在某些情况下，它可能看起来有所不同，但这些是由于其他不受控制的因素造成的，例如旋转盘上的旋转位置。或者文件 X 和 Y 被打开并作为流读取。然后必须读取直到 pos x 的所有 X，对于 Y 也是如此。但这不是文件系统的功能。直接进入不同文件位置的 fseek() 命令将显示相似的查找时间。（再次取决于盘片的位置）。
互联网上有很多关于 FS 压缩的错误信息，这里是 Stackoverflow。文件系统压缩是在块级别（或块级别，取决于设备）完成的，而不是在文件抽象级别，所以表面上寻找是相同的——文件寻找是根据块完成的，而不是根据压缩位。这意味着压缩本身不会暴露给用户级程序。所以你不必考虑它或担心它。
一种“超级简单”的可视化方式：x/0 是块，文件中的块组。未压缩文件和块：[xxx][xxx][xxx][xxx] 压缩文件和块：[xx]0[xx]0[xx]0[xx]000文件 inode 将指向压缩块并透明地留出文件不需要的空间。
原则上，目前没有理由不启用 fs 压缩。除了少数异常情况外，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 仍然如此，但由于重写/擦除块循环，而不是因为线性移动的读头）。如果这是一个巨大的生物信息流，那么中间写入可能不是问题。
通常，寻道时间随 inode 和文件系统布局而变化。不是文件大小。例如，如果你有两个文件，大尺寸 X 和大尺寸 Y，它们都不适合磁盘预读和缓存，也不能在单个 inode 读取中读取，那么到达 X 中位置 x 的时间大约等于到达 Y 中位置 y 的时间，其中 x < y 。在某些情况下，它可能看起来有所不同，但这些是由于其他不受控制的因素造成的，例如旋转盘上的旋转位置。或者文件 X 和 Y 被打开并作为流读取。然后必须读取直到 pos x 的所有 X，对于 Y 也是如此。但这不是文件系统的功能。直接进入不同文件位置的 fseek() 命令将显示相似的查找时间。（再次取决于盘片的位置）。
HTH。
与未压缩文件系统一样，随机查找时间也大致为 O(1)，但需要注意的是，多达 128 KiB 的数据被压缩在一起，因此仅读取一个字节，该 128 KiB 块中的所有数据都必须被读取和解压。根据访问模式，这可能会对性能产生较大的影响，但您需要使用特定的应用程序和数据集对此进行基准测试。
（来源）