首先要提出來的，是嵌入式系統上面重視的幾個特點，像是：
斷電可靠度
耗損平衡
資料壓縮
垃圾收集
就地執行
斷電可靠度，在唯讀的情況下，應該都可以過關，但是 rw 的時候，不知道其它的 fs 能不能過關，意即，如果今天執行寫入動作的時候斷電了， fs 能不能在下次開機讀取的時候，仍然維持正常運作，在日誌檔、inode、目錄等結構都不用擔心會有破碎的情況。
耗損平衡則是因為 NOR/NAND flash 的特性，在寫入 0 區的時候，需要 erase block ，然而這會造成寫入壽命提早完結，固定區塊寫入次數過多的情況，所以說，需要依靠軟體的部份加以處理。(垃圾收集也是跟這個物理特性有關)
資料壓縮，主要是在 SDRAM 價格比 flash 便宜﹑及寫入更新的動作在嵌入式裝置上面其實遠遠低於讀取的情況下構成的解決方案。所以我們可以使用資料壓縮來讓嵌入式裝置在運行期間才真的解開來運作。
就地執行(XIP)的特性在 squashfs 及 jfs 上面都還沒有看到，所以這個特點我就跳過了.... (其實我還不知道什麼情況下可以 XIP)
這些功能除了就地執行之外，其它的 jffs2 都有達成目標，這應該也是 jffs2 之所以可以歷久彌新的原因之一(參考zylix666 的文章)。
再來是 squashfs 官網提到的， squashfs 只是一個 fs structure ，真正讓它可以壓的比別人小的是背後的演算法。但是在演算法的部份，因為 LZMA 在 Linux kernel 的支援還不存在，所以 squashfs 想要包進 kernel 就只好改預設演算法為 gzip ，僅管如此， squashfs + LZMA 的部份還是很多人在用。 (目前似乎是最小的組合)
另外翻到 ramfs 跟 tmpfs 的比較的部份，這兩種檔案系統的用法幾乎一樣，我只看到在使用的對象上面， ramfs 使用的是 physical ram ，而 tmpfs 則使用的是 logical 的 memory address ，所以 tmpfs 也有可能會使用到 swap (這點之前沒有意識到，換句話說， tmpfs 不見得可以「很快」。
----
參考連結：
* LZMA
* jffs2
* squashfs
* ramfs 和 tmpfs 的使用
* cramfs
* 快閃記憶體
沒有留言:
張貼留言