ZFS 數據塊解密 - 儲存設備

OSSLab 實驗室最近投入幾位下海研究 ZFS 與Opensolaris 整合應用
有趣的是. 我們結論都不太一樣.

先討論傳統Raid 5 結構如下
(詳細請看
http://www.osslab.org.tw/Storage/Data_Recovery/Theory/Raid_Recovery )

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


這邊簡單再說明一下恢復Raid 數據 ,關鍵點在於算出固定Stripe 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

數據順序明顯跟raid不同
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 無奇不有.

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

--
Telecom Fabless IC designer Rank in my mind
Atheros LSI Broadcom Marvell Qualcomm
因為非強者 所以只能自嘆
http://www.osslab.org.tw/

--