Open utterances-bot opened 2 years ago
farseerfc
commented
2 years ago SPA 使用一个派生自Slab 分配器的分配器。存储空间被分为许多特定大小的元数据块。
spa 用的分配器叫 metaslab 是沒錯啦，一開始也是想基於 jeff 給 Solaris 內核寫的 slab 實現做改進來著，不過後來 metaslab 用的分配算法和內存的 slab 分配器基本沒啥關係了，現在只剩下個名字。 這個我在 https://farseerfc.me/zfs-layered-architecture-design.html#metaslab 記錄了一下，有個 YouTube 在解釋 metaslab 現在的工作方式。
farseerfc
commented
2 years ago SPA 使用一种类似轮流写入的策略，在一个包含了多个 vdev 的存储池中， SPA 倾向于将写入分散到那一组 vdev 中以增加写入带宽，读出则反之(就像一个天然的 RAID0?)。
這裡和上面講 vdev 樹狀結構的前後羅列在一起可能會比較令人困惑…我的理解是，一開始 spa 做 vdev 抽象的時候是想讓 vdev 形成類似面向對象設計裡的父類子類對象那樣的靈活性，所有 vdev 都提供一樣的接口算地址映射關係，然後像你的 vdev 那張圖中畫得那樣允許任意類型的 vdev 在樹狀結構中任意組合的。後來實現上和 cli 用戶接口上的細節其實使得 vdev 的這個設計目標並沒有真正達成。
實際上是每個 zpool 頂層都有個 concat 語義的 vdev ，頂層的 vdev 下面放的一串子 vdev 通常叫 top level vdev ，添加 mirror / raidz 的 vdev 的時候通常這些類型的 vdev 會是 top level vdev ，也可以直接把塊設備加入 top level vdev 。cli 限制了 vdev tree 不能自由組合。
這裡引用的這段說 spa 的寫入策略其實就是 top level vdev 裡面在 round robin 挑一個 vdev …
farseerfc
commented
2 years ago SPA 使用不等大的数据块大小（类似伙伴系统？）而非使，用扩展机制（使用扩展机制带来的性能提升使用基于块的文件系统也可以达到）。
這段大概能猜到原文是想說啥但是感覺把 extents 翻譯成“擴展機制”之後單看這一段就不知道啥意思了。
傳統上 ，ffs 和 ext2/3 那種，記錄文件分配狀況的時候使用塊映射（block mapping）和間接塊（indirect block）。在這種傳統設計中，塊是固定大小的（比如4K），間接塊包含指向下層塊的指針構成一棵樹。 在更現代的fs設計中，比如 ext4/xfs/btrfs ，都採用 extents 的方式記錄和表達連續的一段地址範圍。extents 長度可變，於是連續分配的時候更高效。然後把 extents 組織成某種樹狀數據結構一般是 b tree 。 zfs 的 spa 這裡採用了一個介於兩者中間的方案…首先因為可以透明壓縮所以 spa 的塊有倆大小，實際佔用大小和邏輯上的文件內範圍的大小，dma 把文件的地址拆成固定大小的塊（默認 recordsize = 128K），固定大小的塊交給 spa 壓縮，壓了之後的塊實際佔用大小是可變的，然後很多很多塊指針連在一起用間接塊來記錄。 某種程度上 zfs 還是間接塊，但是某種程度上也可以看作是 extent 大小上限定為 128K 的 extent 。zfs 的文檔經常說這種設計佔了兩邊的好處（實際是否是這樣可能得另說）
ClSlaid
commented
2 years ago 感谢您的指正...因为鄙人水平有限确实会错翻不少东西而且有些地方理解也不是特别到位。 首先是这个 round robin，它提到了增加磁盘带宽，但是没有提到这个粒度多大就和 RAID0 相比了（当然这个和 RAID0 区别应该较大，应当类比多模块存储器？） 这篇论文是在大概2002年那会发的，ZFS经过演化和现在确实是不一样的。未来工作（Future Works）中也有说到对于 CoW 需要比 Slab 更高明的分配算法。 vdev 的组织确实没怎么看懂... 伙伴系统是我个人的联想猜测，extents 也没过脑子直翻了没加注释了... 总之感谢您的补充和指正了！我会在明天把博文更新一下因为不是所有人都能看到 GitHub Issue...
ZFS 架构简介 - ClSlaid.icu | Can you save me?
ClSlaid | Can you save me?
https://clslaid.icu/zfs-model-intro/