DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)

[Adam Vande More]

On Wed, Jul 28, 2010 at 2:13 AM, Alex Hornung <ahornung at gmail.com> wrote:
On 28/07/10 03:30, Adam Vande More wrote:
> [...] although I am
> curious to know why GEOM wasn't chosen.  It's both more powerful, and
> easier to use IMO.  Some examples of that would be gmirror, glabel,
> gstripe, HAST, etc -- all easier than the Linux equivalents.  The mdadm
> stuff is reliable, but a real PITA.  For me anyways, including more GPL
> tools is a turnoff.

This is getting hugely off-topic, but here go my reasons for preferring
to stay away from geom. Perhaps, I'll start a new thread. 
Just a side note first: mdadm and md-raid do not
use device mapper, they use their own in-kernel stuff. Now my opinion on
why geom is not the way to go but dm is can be summarized in the
following points:I know, my point for that is the geom raid modules are so much easier to setup and manage from an administration perspective.  DragonBSD software raid would benifit a great deal here. 

- geom forces all the I/O onto one (or two?) threads that transport it
across a hugely complicated system. IMO this won't scale well in the
future, when the bottleneck moves away from the disks (as already is
starting to be the case with SSDs)Well it's 3 main actually(up, down, and event threads basically), and depending on the module you can spawn other kernel threads to handle asynchronous stuff to pass off when it's ready.  The design has awfully nice performance characteristics like there is a centralized place for bio stuff, optimization would seem to be much easier to implement.  You can see evidence of this when using something like gjournal.  On gjournaled device, single threaded IO takes a big hit putting it in the Linux realm of performance, however as the threads grow, so does the ability to optimize requests being sent to physical devices.  That's why gjournal devices scale so much better as concurrency grows.  I have not observed any performance bottlenecks on my GEOM ssd devices and I have no idea what a theoretical or real-world maximum would be on the GEOM design.
 

- We don't need to reinvent the wheel. We have good MBR, disklabel and
decent but improvable GPT support already in our disk subsystem.Like I said in my first post in thread, I don't think abandoning MBR style is good, but defaulting to GPT is desirable on a number of levels including one where different OS's being installed on the disk no longer would have a easy excuse to blow away any partition it finds.
 

- geom wants to do everything in kernel-land while device mapper devices
usually rely on a userland configuration program that reads and parses
metadata. This is *much* more flexible than having to implement huge
parsers in kernel-land, such as the one required for lvm, just to name one.Are you taking about the g_linux_lvm module?  I would not consider that huge ~1200 lines.  That's tiny compared to what you had to go through to import.  Now let's see you write an io scheduler for the new devices.  See my point?
 

- Device Mapper offers compatibility with Linux, the most used
non-windows operating system afaik. And as a matter of fact we were
talking about Linux users here, so they would definitely have much more
issues with geom.Perhap they would, hard to say though.  If someone is able to learn LVM/DM stuff though, they certainly would be able to GEOM.  LVM does have a few advantages over GEOM like being able to resize on the fly, but that functionality does not work here.
 

> [...] If GEOM where to be completed, gpart should be useable too then only the
> boot bits need to be solved.

We already have GPT support in the kernel, and gpart would offer no
advantage that I know of. The support everyone else is talking about is
GPT support in the loader.
I know of the differences I guess I didn't relay my whole thought here.  gpart was brought up because it's a geom class, and it does have more functionality than the existing D_BSD support(the man page notes there is much to be done).  My point is that loader support would also be easier to import if it had the same target, the geom_part_gpt class.
-- Adam Vande More