Re: RFC: Project geom-events

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?

I am mostly using geom_mirror.

> If GEOM class drops underlying provider due to errors,
> it doesn't have chances to update metadata for it.

I understand this, but if there are (stale) metadata on provider, system 
can read this metadata and should disallow normal operations (for 
example propagating slices, partitions and labels)

>    But most of classes, if dropped provider attached again, will
> rebuild itself, as they track which components are actual and which
> ones are old.

I see many times dropped provider (for example ada1) because of some DMA 
timeout (bad cables and so on), sometimes provider (disk ada1) detached 
from ATA channel and reattached after reboot. In both cases, provider 
has stale metadata and is marked as "broken" by geom_mirror and auto 
rebuild did not start.

In this case, I see gm0 with all of its slices, partitions and labels 
and ada1 with the same slices, partitions and labels - this is the 
problem. Because there are two devices providing same labels and the 
winner is the first tasted... Even if the system (geom_mirror) knows, 
that ada1 is "broken disk".

I think that GEOM should be more robust in this case and if metadata is 
found, do not publish slices, partitions, labels and so on...

>    Do you want GEOM classes to track droppen components somewhere else
> and din't even try to attach them automaticaly when they re-appear?

If some disk is removed, reinserted and synchronisation starts, then 
everything is OK. But situation where component is marked as "broken" 
and system and user can operate on it like on normal "good and clean" 
drive is wrong.

The drive's content should be inacessible until operator do some action 
(for example gmirror clear on broken disk device).

Miroslav Lachman
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"