Date: Fri, 27 Mar 2009 12:26:11 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-geom@freebsd.org Subject: Re: gpart on top of eli inside a slice is not working Message-ID: <20090327092226.K67075@maildrop.int.zabbadoz.net> In-Reply-To: <1FA0EF30-7FCC-4384-8151-36843EFBE01D@mac.com> References: <20090325214318.Q67075@maildrop.int.zabbadoz.net> <FEA6DFB1-1E0A-4AF3-897C-6E1031BDA9B0@mac.com> <20090326062604.X67075@maildrop.int.zabbadoz.net> <1FA0EF30-7FCC-4384-8151-36843EFBE01D@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Mar 2009, Marcel Moolenaar wrote: Hi, >>> The bug is in the create method: GPT cannot be created inside a >>> MBR slice (or any other partioning for that matter). I'll fix >>> that shortly. >> >> Well technically it is created inside some random garbage from eli and >> not directly inside the MBR slice. > > When I refer to nesting, I mean the on-disk layout. It's almost > meaningless to talk in terms of GEOM nesting, because you can't > assume anything. > > Thus: the fact that geli is in between the two gpart instances is > irrelevant. ok. >> So the only possible solutions for those would be: >> 1) Somehow convert the entire disk to part and then exposing the 3 >> freebsd-* partitions and have a dedicated eli inside each. > > I don't understand what you're trying to say. Can you > elaborate? Well if you convert the entire thing to GPT (not part; still wrongly using it as a synonym 'cause of the old gpt(8) name and being confuse;-) ) you'd have md0p1 Compaq Recovery (however this would work) md0p2 NTFS (however this would work) md0p3 freebsd-ufs md0p4 freebsd-swap md0p5 freebsd-ufs and then you would do md0p3.eli md0p4.eli md0p5.eli In this case the "freebsd-*" is publicly exposed in GPT. But in contrast, with the fdisk version, where slice 3 is "DOS" md0s1 "Compaq Recovery" md0s2 "NTFS" md0s3 "DOS" md0s3.eli random garbage md0s3.elia equivalent to md0p3 md0s3.elib equivalent to md0p4 md0s3.elid equivalent to md0p5 the freebsd parts are not publicly visible. >> 2) try (and stick with) bsdlabel on top of the eli inside the mbr >> slice? > > A different scheme, one that is allowed to be nested (again, from > an on-disk layout PoV), is the right thing to do. I went with gpart + BSD for now. >> So can you explain why there is the restriction that part cannot be >> used inside a MBR slice or rather somewhere on top of such? > > There's no such restriction in gpart. If there was, then gpart > would not be able to implement the BSD scheme or the EBR scheme. So again here, s,part,GPT, ;-) What is the EBR scheme? Are the schemes somewhere documented in more detail? Well they are someway but perhaps gpart(8)[?] could talk a bit more what a "scheme" is and what the affiliation to the geom classes and options. So I have to say I much more liked gpart to create the traditional BSD disklabels than the old bsdlabel. Things can be scripted more eassily etc. Two things would significantly improve usability though are 1 ability to give -s size in human readable way instead of having to do all the math. 2 be able to give -b start to just say "start at next free offset" w/o looking it up or doing the math. Example: gpart add -b next -s 64G -t freebsd-ufs da3 /bz -- Bjoern A. Zeeb The greatest risk is not taking one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090327092226.K67075>