Re: RFC: Project geom-events

On 05.10.2011 12:29, Lev Serebryakov wrote:
> You wrote 5 октября 2011 г., 13:18:34:
>> geom_raid addresses this problem in own way. As soon as RAID BIOSes
>> expect RAIDs to be built on raw physical devices and probe order is not
>> discussed, geom_raid exclusively opens underlying providers immediately
>> after detecting supported metadata. So even if volume is broken or
>   But it could be not first, who taste component of mirror, am I
> right? If geom_part will be first, will it "take away" component from
> geom_raid? Or it could not?

Most of GEOM classes are less aggressive. So geom_raid will any way
taste device finally and geom_part should be automatically spoiled as
soon as geom_raid open device.

>   If it works in any case (exclusive open spoils geom_part), it could
> be used in all other classes without any metadata infrastructure,

That works perfect for case when class (geom_raid) is known to work on
raw device. Other RAID classes can be used over partitions, so some care
should be taken to avoid false positives.

> but
> it seems, that geom_mirror, for example, could pickup metadtata from
> last parition instead of raw device...
> 
>   I'm not sure here.

In that case it is helpful to include media size into the metadata.
Comparing that value with provider size during taste allows to avoid
these false positives. geom_mirror metadata include/check provider size
since version 3. Pity that MBR and probably others don't.

>   But, in any case, maybe standard first 16 bytes of metadata in
> pure-GEOM classes and filter in GEOM infrastructure itself ("not pass
> provider for tasting to anything but class, written in first 16 bytes
> of last sector") looks good idea, IMHO.

And what if class is not loaded/supported? There should be a way to
manage/clear that label.

-- 
Alexander Motin