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/ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 112.105.99.25