pctine wrote:
我想E兄把 zfs arc, l2arc auto-tiering 和 Q-tier 兩者的比較是不對等的, 具體來說. zfs zrc, l2arc 應該就是一般我們指的 caching 的機置, 而你指的 qtier 排程去做 cold & hot data 在 storage 裡面的 move, 跟 zfs arc & l2arc是兩碼子事.
小弟對 zfs 完全不了解. 但一個從 file system 內部去做自我的管理, 另一個從 os 層級去做管理, 我想各有其優缺點, 可以想見的, zfs 要做到那麼多事, 它的自主性很高, 相對的它必定就比較耗費資源, 一個好的 file system, 並不是放到所有平台它都是絕對優勢的. 或許它有它的舞台.
你指的 algorithm 只是指內建在 file system, 難道在 OS 層級做不到嗎? file system caching 在 RAM or SSD 不也是能如此設計? 或許早就是如此的設計了． (qnap caching)
zfs arc 是 cache, 畢竟 RAM Disk 的資料是暫時性的, zfs l2arc 是 auto-tier, ssd 的資料有持久性的. 什麼東西放到 ssd, 什麼東西放到 ram 是由 zfs 決定而不是 OS. 由於 zfs 要求很高, 它絕對不能在 hardware raid 上面運行, 它是使用 cpu 當成它的 raid controller 來計算的. 大部分的 ZFS storage 的 RAM 都是 64GB以上最好. 我的 idc 的 zfs server 是跑 256gb 的RAM (zfs 就是用了 128 gb). 我自己家的是跑 16GB (zfs 就馬上不客氣使用了 8GB) ZFS 是非常消耗資源. 我有手動限定我家裡的 zfs server 使用 4gb 的 ram 過 (效能像是使用 usb 2.0 外接hd), 最後我還是乖乖的給它 8GB (馬上就有 ssd 的感覺). zfs 的存在就是為了達到最高的 iops 最高的 read/write 吞吐量. 現在記憶體真的越來越便宜了, 所以我覺得丟個 8GB 給 nas 使用不為過吧
OS 層級做不做的到這個問題, 應該是說, 這部分的精華還是存在 solaris 的 kernel 裡面, 至少 linus torvalds 他的 kernel 寫不出來這部分. ZFS 運行在 kernel space 的程式/library, 是 OS 最底層最接近硬體的區塊. 而比較普通 OS 層級的程式市都是在 user space 運行如 apache/samba/java/perl/pyton, 這部分沒有太多用到硬體加速功能, 需要透過 kernel space 的library 才能有硬體的支援.
zfs 不是一般我們熟悉的 file journal system/ b-tree. 它完全是把資料當作一個格子一個格子在使用, 如果它發現 3~8 的格子的資料常常被讀取而且不改變, 它就會把那邊資料複製到 ram disk 上, 而其他檔案格式或是 OS 記錄 yuihatano.html & yuihatano.mp4 常常被讀取, 需要被丟到 ram disk 上. 但是這個時候會碰到一個情況, yuihanato.mp4 是 10分鐘的 video, 但是大部分的人只看前面 30秒就把頁面關掉了, 以一般的 OS 跟檔案格式是兩個檔案都移到 ram disk, 但是 zfs 只會移 yuihatano.html + yuihatano.mp4 的前30秒的資料而已, 這樣子反而保留更多ram disk 空間給其它需要讀取加速的檔案. 它有太多很神奇的功能 它寫入加速的那塊, 由於是搭配上 lz4 壓縮, 它寫入的 data 反而都是128kb大區塊 而不是一個破碎的 4k 小區塊, 因為這樣子的方式, 它讀取反而更加快速. zfs 它有太多深奧的東西 nimble storage 常常有發表技術性/學術性文章在討論這部分, 但是都已經超出我的理解能力了, 這些是把 storage 當作一門專門的科學, 他們是博士級, 而我只是小學生, 我完全看不懂, 就算是圖文並茂的也一樣.
