Date: Wed, 05 Nov 2008 09:28:19 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: vadim_nuclight@mail.ru Cc: freebsd-geom@freebsd.org Subject: Re: gpart oddity Message-ID: <0244407E-F10C-4374-9D68-557C1DA31EB3@mac.com> In-Reply-To: <slrngh30s2.1o13.vadim_nuclight@server.filona.x88.info> References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> <slrngh30s2.1o13.vadim_nuclight@server.filona.x88.info>
next in thread | previous in thread | raw e-mail | index | archive | help
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, >>> somehow. >>> 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 > system > with different sizes of disks. I have had edit their labels that > partition > '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 > slices > 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, > while > on ad0s1 it will not, so I need to hack a lot if I need to resize > partitions. > > 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 round hole. 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. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0244407E-F10C-4374-9D68-557C1DA31EB3>