DragonFly users List (threaded) for 2010-07
Re: Is it time to dump disklabel and use GPT instead?
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. 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
- geom is NOT easier to use from a developer's perspective. Device
Mapper targets are, imo, much easier to write.
- 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)
- We don't need to reinvent the wheel. We have good MBR, disklabel and
decent but improvable GPT support already in our disk subsystem.
- 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.
- 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.
> [...] 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.