On 10/05/2011 03:19 PM, Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 октября 2011 г., 1:27:03: > >> I am still missing one thing - dropped provider is not marked as failed >> RAID provider and is accessible for anything like normal disk device. So >> in some edge cases, the system can boot from failed RAID component >> instead of degraded RAID. This can cause data loss or demage. > What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? > Something else? If GEOM class drops underlying provider due to errors, > it doesn't have chances to update metadata for it. > But most of classes, if dropped provider attached again, will > rebuild itself, as they track which components are actual and which > ones are old. > Do you want GEOM classes to track droppen components somewhere else > and din't even try to attach them automaticaly when they re-appear? > >> Is it possible to fix it by something like your geom-events, or should >> it be done in each GEOM RAID class separately? > geom-events only process events from GEOM classes in userland. Each > class should decide what happens to him by itself, as only class > itself knows is this particular error fatal or not. > geom-events could help, if it replaces dropped component fith spare > drive, as in such case most classes prefer "latest" drive, not old > one. Without spares, everything will be exactly as it is now, plus > e-mails to administrator :)
A bit unrelated, but are there plans to integrate hardware RAID (mps/mfi/mpt/amr) failure notification in the same way as this would be done for GEOM ? As in, "one framework and way to manage both hard and soft RAIDs". -- Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo
signature.asc
Description: OpenPGP digital signature
