DragonFly BSD
DragonFly users List (threaded) for 2010-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Is it time to dump disklabel and use GPT instead?

From: Alex Hornung <ahornung@xxxxxxxxx>
Date: Wed, 28 Jul 2010 08:13:24 +0100

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
following points:

- 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.

Alex Hornung

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]