raid5各位老大 還有的救嗎~

kkjerry

本來c0t8d0s2  還是okay\r\n作了metareplace  -e d1 c0t10d0s2 之後resync不成功\r\n#metastat\r\nd1: RAID\r\n    State: Needs Maintenance\r\n    Invoke: metareplace -f d1 c0t10d0s2 <new device>\r\n    Interlace: 32 blocks\r\n    Size: 286715604 blocks\r\nOriginal device:\r\n    Size: 286718848 blocks\r\n        Device              Start Block  Dbase State        Hot Spare\r\n        c0t8d0s2                4278     Yes   Last Erred\r\n        c0t10d0s2               3210     Yes   Maintenance\r\n        c0t11d0s2               4278     Yes   Okay\n\n[ 本帖最后由 kkjerry 于 2006-10-17 08:51 编辑 ]

jsc_flying

Maintenance vs. Last Erred States\r\nWhen a slice in a mirror or RAID5 metadevice device experiences errors, DiskSuite\r\nputs the slice in the “Maintenance” state. No further reads or writes are performed to\r\na slice in the “Maintenance” state. Subsequent errors on other slices in the same\r\nmetadevice are handled differently, depending on the type of metadevice. A mirror\r\nmay be able to tolerate many slices in the “Maintenance” state and still be read from\r\nand written to. A RAID5 metadevice, by definition, can only tolerate a single slice in\r\nthe “Maintenance” state. When either a mirror or RAID5 metadevice has a slice in\r\nthe “Last Erred” state, I/O is still attempted to the slice marked “Last Erred.” This is\r\nbecause a “Last Erred” slice contains the last good copy of data from DiskSuite’s\r\npoint of view. With a slice in the “Last Erred” state, the metadevice behaves like a\r\nnormal device (disk) and returns I/O errors to an application. Usually, at this point\r\nsome data has been lost.\r\nAlways replace slices in the “Maintenance” state first, followed by those in the “Last\r\nErred” state. After a slice is replaced and resynced, use the metastat(1M)\r\ncommand to verify its state, then validate the data to make sure it is good.

kkjerry

第一個ＨＤＤ有許多ＢＡＤ　ＳＥＣＴＯＲ\r\nＯＳ重啟\r\nＲＡＩＤ第一。三的ＨＤＤ為ＯＫＡＹ\r\n第二個為維護\r\nＦＳＣＫ有很多ＲＥＡＤ／ＷＲＩＴＥ　ＦＡＩＬ的\r\n但先以唯讀卦上來作資料的ＢＡＣＫＵＰ了\r\n請參考\r\n３Ｑ～