Date: Mon, 10 Nov 2008 11:41:15 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-geom@freebsd.org Subject: Re: gpart oddity Message-ID: <slrnghg7eq.omk.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> <0244407E-F10C-4374-9D68-557C1DA31EB3@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marcel Moolenaar! On Wed, 05 Nov 2008 09:28:19 -0800; Marcel Moolenaar wrote about 'Re: gpart oddity': >> 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. But the question is, what I will have to do with my setup? Will it still work in future versions? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnghg7eq.omk.vadim_nuclight>