Wei-Hao Syu's Blog 徐偉浩的部落格

[華語, cmn-Hant-TW]

在六月中左右 FreeBSD 8.2-STABLE 的 zfs 升級到了 v28

這版最主要的特色是 dedup，也就是 block level 的 deduplication，傳說中的 virtual machine disk image 備份救星 (誤)。 因為是 block level，所以檔案位置怎麼放，檔案是不是只修改一點點這些通通不用管了，反正 zfs 覺得這兩個 block 是長得一樣的話，就自動會處理，如果硬碟裡面有一堆彼此間差異不大的大檔案，那效果就會非常好，遠比 lzma 或是 gzip 壓縮更有快感 (事實上 dedup 跟壓縮是可以併存的，歡迎挑戰硬體極限) 。

要開 dedup 很簡單，在有 zfsv28 的系統下 zfs set dedup=on filesystem 指令就可以打開，要注意的是 dedup 是從整個 pool 來看的，同一個 pool 下可以有些 filesystem 有開，有些沒有，算是相當有彈性。dedup 的效果可以簡單的用 zpool list 看出，v28 多了一格 DEDUP，那個的倍率就是 dedup 的效果。

NAME         SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
backup       696G   445G   251G    63%  1.80x  ONLINE  -

在有開 dedup 的地方，每一個 block 的 checksum 會存在一個叫 DDT 的表裡面，根據 dedup FAQ 的講法，一般 record size  128K 的情況下，20TB 的資料會需要 32 GB 的實體記憶體來放 DDT，如果沒那麼大的記譩體那就會吃到硬碟，那就會非常非常慢。折衷方案就是找一顆 SSD 當 L2ARC，DDT 主要是讀取 (因為要比對)，SSD 的讀取效能遠比硬碟來得好，這個工作還算扛得起來。

記憶體不足硬上 dedup 會對效能有什麼衝擊呢，簡單的測試

( 2G 記憶體，640G 的硬碟空間，zfs compression = gzip; atime = off)
測試檔案為 boost_1_45_0.tar.bz2 大小約 38MB，解壓縮後約275MB，用 FreeBSD 內建的 tar 來解壓，然後用 rm 刪掉，同樣用系統的 time 來測時間

DEDUP on:

tar 19.063u 6.914s 1:03:02.62  0.6%   88+1735k 0+0io 0pf+0w
rm   0.171u 8.741s 1:12:41.98  0.2%   26+2530k 0+0io 0pf+0w

DEDUP off:

tar 19.372u 6.963s    1:05.41 40.2%   74+1464k 0+0io 0pf+0w
rm   0.029u 3.826s    0:08.04 47.7%   16+1528k 0+0io 0pf+0w

這是最慘烈的情況 (八成是整個DDT都在硬碟上了)，DEDUP on 一般情況其實沒那麼慢，大約數十分鐘吧，如果硬碟裡面已經有相同的資料的話那還會再更快些，不過再快也是被 DEDUP off  時的速度慘電就是。從實際應用來看，解壓縮一個數十MB 的檔案要花數十分鐘到一小時，砍掉解壓縮出來的東西還要再花數十分鐘到一個小時是什麼情況？ 只能說硬體不夠力的話，還是不要亂開 DEDUP 吧。 (不過一想到 DEDUP 的快感… 再加上 RAM 現在便宜的跟●●一樣，好像升級一下再來開也是不錯的選擇)