使用 LZO 壓縮尋求 BTRFS 下的文件內部性能
我計劃在 50 TB RAID6 陣列上使用 btrfs，並且我想啟用 lzo 壓縮。
這適用於在大型（1 TB - 20 TB）文件中進行大量搜尋的生物資訊學設置。（該軟體只獲取分散在文件中的小塊數據）。
讓我擔心的是，我不明白如何在 btrfs 等壓縮文件系統上執行搜尋。文件是否需要從頭開始解壓到搶手位置？這將對我的設置產生巨大的負面影響。
或者更一般的問題：文件大小的尋軌時間尺度是否與非壓縮文件系統相同還是變得更糟，例如 O(file_length)
與未壓縮文件系統一樣，隨機查找時間也大致為 O(1)，但需要注意的是，多達 128 KiB 的數據被壓縮在一起，因此僅讀取一個字節，該 128 KiB 塊中的所有數據都必須被讀取和解壓。根據訪問模式，這可能會對性能產生較大的影響，但您需要使用特定的應用程序和數據集對此進行基準測試。
（來源）
網際網路上有很多關於 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。