Date: Fri, 27 Mar 2009 09:44:41 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-geom@freebsd.org Subject: Re: gpart on top of eli inside a slice is not working Message-ID: <5BDA79FB-5678-4FF2-9BD1-D5915DDFC3C3@mac.com> In-Reply-To: <20090327092226.K67075@maildrop.int.zabbadoz.net> 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> <20090327092226.K67075@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 27, 2009, at 5:26 AM, Bjoern A. Zeeb wrote: >>> 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. I see. Yes, of course. This shows the downside of having a flat partitioning. While it does the job, it may not be the most aesthetically pleasing in some cases... > >>> 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. Sounds good. With gpart you can create BSD disklabels with up to 20 partitions, so it can still be used when you want to carve up in more than 7 (usable) partitions. >>> 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, ;-) Ah :-) With at least 128 partition entries the need for nesting was eliminated. It's explicitly allowed to sub-partition a GPT partition with a MBR, but this was not so much done for the sake of nesting I think, but rather virtualization. Also: GPT was designed as part of EFI. You don't want to add unnecessary complications to firmware and nested GPTs surely do that. > What is the EBR scheme? The EBR scheme is used to create logical partitions: http://en.wikipedia.org/wiki/Extended_boot_record > Are the > schemes somewhere documented in more detail? They're as well documented as they were before :-) In other words no. > 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. I think the visibility has increased from before. Previously partitioning was thought of in terms of utilities. There was a 1-to-1 mapping between scheme and tool. Now there's a single tool and users need to select a scheme when they create a partitioning. It definitely makes sense to elaborate more in the manpage for gpart(8), or even create gpart(9) pages. I'll keep it in mind. > 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. Yes on both accounts. We'll get that fleshed out and implemented in time. It's just "syntactic sugaring"; UI padding... Thanks for the feedback. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5BDA79FB-5678-4FF2-9BD1-D5915DDFC3C3>