Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded?

Ivan Voras ivoras at freebsd.org
Mon Jan 17 13:47:02 UTC 2011


On 17/01/2011 14:39, Lev Serebryakov wrote:
> Hello, Ivan.
> You wrote 17 января 2011 г., 16:30:43:
>
>>>>     I have mirrored PARTITION (/dev/ad4s1d + /dev/ad6s1d) with UFS with
>>>> label on it. This label is shown in /dev/ufs when geom_mirror is
>>>> loaded.
>>>
>>>>     When geom_mirror is NOT loaded both ad4s1d and ad6s1d are valid,
>>>> complete, clean filesystems, but here is no /dev/ufs entries for them,
>>>> and kernel can not mount FSes at all.
>>>     And even worse: it sees ONE of all FSes and when "geom_mirror" is
>>>     loaded, it puck up one of components from "/dev/ufs/home" instead of
>>>     device node and everything hangs up due to loop (?)...
>> Yes, gmirror and glabel are known to interact badly because of such edge
>> cases - since glabel presents the whole underlying device in pretty much
>> the same way as the original device entry, gmirror cannot distinguish
>> between the two. You could use the "-h" argument to "gmirror create" to
>> get around this.
>> Since this is so common and has also bitten me in the past, I wonder if
>> some kind of avoidance detection mechanism could be created in gmirror?
>
>    I think, it will be better if geom_label will create ufs/ufsid items
> always (even if FS size is smaller that it's container (provider)
> size), but create providers only as big as FS itself. It this case
> geom_mirror will never see its metadata inside "UFS-based" providers
> and geom_label will show FS labels even it it inside mirror when
> geom_mirror is not loaded at all. Both problems are solved with one
> solution :)

Ah but you see - the UFS metadata *does* record the correct file system 
size - and this size spans the entire container, just like /dev/adXsY 
etc. - so both glabel and gmirror behave correctly.



More information about the freebsd-geom mailing list