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-unsubscr...@freebsd.org"

Reply via email to