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