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. Cheers, Alex Hornung
