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/
--
有趣的是. 我們結論都不太一樣.
先討論傳統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/
--
All Comments