ZFS結構塊分析
 

OSSLab 實驗室最近投入幾位下海研究 ZFS 與Opensolaris 整合應用
有趣的是. 我們結論都不太一樣.
先討論傳統Raid 5 結構如下
(詳細請看
http://www.osslab.org.tw/Storage/Da...y/Raid_Recovery )

LBA DiskA DiskB DiskC DiskD
1 P D1 D2 D3
2 D4 P D5 D6
3 D7 D8 P D9


這邊簡單再說明一下恢復Raid 數據 ,關鍵點在於算出固定Strip Size ,順序.


經過分析

ZFS Raid-Z (接近5 可損壞一顆) 結構 如下
以下每塊D同於Raid D 大小都相同

LBA DiskA Disk B DiskC DISKD
1 D1 D4 D6 P
2 D2 D5 P D8
3 D3 P D7 D9
4. P D11 D13 D15
5. D10 D12 D14 P

(註 P塊位置還不太確定 但D塊走法是已確定的)

D1-D9 為一塊Stripe Size.
D10-D15 為一塊Stripe Size

數據順序明顯不同 ZFS 採用單盤連續資料寫入..但是動態分配Stripe Size塊 "多寡"


一.用手工可以算出D Block Size 大小. 不過算的很辛苦..因為有時抓不到P塊

二.可辨識狀況 可算出資料可變長度 (資料是走D1~D9 或D10~D15 ) 也只能做手工計算恢復

三.不可辨識狀況 因為資料可變長度 　所以數據很容易錯亂.　因為不易確定Stripe Size跟P塊位置

四.D塊內應該都有Metadata 標明D有幾塊 .但是我們還未抓出此參數,可能還要觀看ZFS Source Code

不過ZFS 的數據恢復　本身就不是這方向
數據塊本身很難組了. ZFS 就是規畫用一般指令再去Mount 他會幫組建

再根據的MetaData 資料還原可恢復數據資料 導入Storage Pool

細部Tip 為
- disable ZIL
- enable readonly mode
- disable zil_replay during mount
- change function that chooses uberblock

有人認為 ZFS Production 風險高. 主要關鍵在於ZFS 數據塊恢復問題 經驗與資料都不足
(我們實驗室已多次接UFS ,EXT3,EXT2 ,NTFS 各種Raid System (FC ,NAS ,SAN ,DAS) Recovery )


我個人是認為ZFS Production ok .但還要做多次做惡搞性測試 再用指令或"GUI"處理
本身實驗室10TB SAN+ NAS Storage 也將採用ZFS

其實現在有簡單GUI管理 (要不然ZFS管理指南 有2xx Pages) +SSD 加速Cache+ HA+ 高性能+ 多功能 +Snapshot
Storage Soultion .

只能說Opensources 無奇不有.

(實驗室有10萬多的Storage OS 軟體,最後選擇　卻是考慮FREE)