Date: Mon, 17 Jan 2011 14:46:46 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: Broken gmirror: why /dev/ufs is empty when geom_mirror is not loaded? Message-ID: <ih1h86$1t3$1@dough.gmane.org> In-Reply-To: <234432652.20110117163922@serebryakov.spb.ru> References: <1686083494.20110113182418@serebryakov.spb.ru> <1811347380.20110113213700@serebryakov.spb.ru> <ih1ga3$tdv$1@dough.gmane.org> <234432652.20110117163922@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ih1h86$1t3$1>