xcllnt at mac.com
Wed Nov 5 09:28:27 PST 2008
On Nov 5, 2008, at 3:29 AM, Vadim Goncharov wrote:
> Hi Marcel Moolenaar!
> On Wed, 22 Oct 2008 14:03:27 -0700; Marcel Moolenaar wrote about
> 'Re: gpart oddity':
>>> Then I remembered that I labeled ad4s1 purely through sysinstall and
>>> never touched it with disklabel(8), on the other hand I used
>>> disklabel to label ad4s2.
>> That's good to know; not that there's a lot we can do about all
>> those existing installations...
>>> My personal conclusions:
>>> 1. sysinstall seems to have handled those fields incorrectly,
>>> 2. those fields do not seem to be of any particular use/importance,
>>> so g_part_bsd might be overly strict here.
>> Being strict is not a bad thing, but given that we put an
>> invalid label on all new installations I think it's better
>> gpart doesn't check it or otherwise detect and corrects it.
>> (we know the absolute sector offset of the label, so if
>> secperunit is mediasize + offset, we know the not to flag
>> the label as invalid, patch it up and move on).
> The question is, how much strict it is? Currently I have an 6.2-S
> system with
> gmirror(8)'ed slices, not disks, as it was converted from existing
> with different sizes of disks. I have had edit their labels that
> 'c' doesn't cover entire unit (and last partition was reformatted to
> be not
> truncated, too). This is needed to be sure that last sector gets not
> overwritten by gmirror(8) metadata, but bsdlabel(8) always complains
> about it
> that it doesn't cover bla-bla-bla. Moreover, labeled partitions and
> exist on their own, despite of gmirror(8). And yet more, if I try to
> do a
> bsdlabel(8) on a gm0, it will complain about 63 sectors boot offset,
> on ad0s1 it will not, so I need to hack a lot if I need to resize
> What is the cause of the trouble?
From what you tell, I think the problem is caused by
forcing the proverbial square peg into the proverbial
We made it too easy for people to create invalid labels
because we simply didn't do any real sanity checking
and/or didn't provide any real tools to help the user
achieve what they want.
The fact that gmirror puts the metadata in the last
sector and only adjusts the media size of the provider
when in use, means that we have introduced ambiguity
in how the GEOMs are stacked and while the gmirror
approach is a feature on the one hand, we have done so
without regard for the validity of disklabels. We
handwaved the problems as unimportant or aesthetic.
xcllnt at mac.com
More information about the freebsd-geom