資料壓縮/壓縮檔案系統

檔案壓縮與壓縮檔案系統

待辦事項：這本書中是否有更好的地方來討論壓縮檔案系統和快閃記憶體？

許多資料壓縮演算法是面向整個檔案的。他們假設整個原始檔案可以從一開始就獲得，並且人們將希望從頭到尾解壓縮整個檔案。

壓縮檔案系統（尤其是快閃記憶體檔案系統）打破了這種假設。ZFS 檔案系統使用 LZJB 壓縮演算法。許多網際網路路由器和網際網路防火牆使用壓縮快閃記憶體檔案系統，通常是 cramfs 檔案系統。（參見 逆向工程/檔案格式#壓縮、加密和混淆 的示例）。一些“固態硬碟”（SSD）在內部使用壓縮演算法來減少檔案佔用快閃記憶體的“使用量”——這實際上不會給使用者帶來更多儲存空間，但更大的空閒儲存空間可以在內部由 SSD 以延長驅動器壽命的方式使用。

這些系統需要相對快速地隨機訪問儲存在檔案系統中的資料——從頭開始解壓縮會太慢。

一種方法是使用一個索引，給定我們想要查詢的某個檔名（或“邏輯塊號”），它會告訴我們確切地在磁碟上的哪個位置（或在批次快閃記憶體中）開始解壓縮，以及一個流壓縮演算法——這樣解壓縮器可以跳到壓縮資料的中間並從那裡開始解壓縮。

這些系統的一個更難的要求是允許編輯檔案。（這太難了，以至於一些壓縮檔案系統，比如 cramfs，比如 python 可執行 zip 檔案，不允許這樣做——它們必須從未壓縮檔案的目錄一次性建立。建立 cramfs 系統後，它只能以只讀方式掛載）。

壓縮檔案系統的最早應用是為了讓人們能夠將更多資料儲存在當時可用的相對較小、昂貴的儲存系統中。

正如我們在 資料壓縮/評估壓縮效果 部分提到的，有些人即使在有足夠的 RAM 和磁碟空間，不需要真正縮小檔案的情況下，也會使用資料壓縮技術。例如，設計影片遊戲的人員通常希望在載入下一個關卡時，能夠快速從儲存器中載入大量資料。如果我們使用一些簡單的資料壓縮技術來稍微減小磁碟上的位元組數，我們可以將節省的時間的一部分用於解壓縮，並且仍然會得到好處。

許多人已經構建了一個實際上是虛擬檔案系統的東西，它可以讀取和寫入標準的“.tgz”或“.zip”檔案：TrueZIP， Java Zip 檔案系統提供程式，等等。

待辦事項：更詳細地說明為什麼未修改的面向檔案的壓縮演算法不適用於壓縮檔案系統，以及使用哪些技術來 (a) 修改這些演算法以使其適用，或者 (b) 其他對壓縮快閃記憶體檔案系統有用的演算法，或者 (c) 兩者的結合。

待辦事項：說幾句關於 w: SquashFS 的。

待辦事項：說幾句關於 w: initramfs/w: initrd 的。

虛擬記憶體壓縮

待辦事項：說幾句關於 zswap 和 zRAM 以及與虛擬記憶體壓縮相關的類似想法的。

… 使用 lz4（lzo 的變體）…