DragonFly users List (threaded) for 2010-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
Personally speaking I would prefer the lvm/dm infrastructure. There
are many reasons for this, some personal, some not.
First of all, we absolutely do not need the duplication. Having both
in the system makes no sense whatsoever. It just creates unnecessary
confusion.
I think that there is just too much logical indirection in geom.
I far prefer drive-serno + partition specifications, there is no room
for error and no confusion. Logical auto-probing which ignores the
serial number is a human error disaster waiting to happen.
Also I don't see any advantage to any softraid implementation which
requires a full disk sync after a minor glitch, such as someone
pulling a plug temporarily or a crash/reboot or a misprobe.
It harkens back to issues similar to the background-fsck problem.
A production system just can't afford to do 12-36 hours worth of
background *anything* after a glitch unless it's the only choice
(i.e. a drive actually physically failed and had to be replaced).
The majority of glitches are not going to be actual drive failures.
--
I don't think gpt vs disklabel really has anything to do with
lvm/dm or geom, they are separate issues.
If someone wants to write a really nice gpt partition editor that
pops you into vi or emacs or whatever then I would be more amendable
to using gpt as a default. But if all we have is command-line
list/add/remove junk, then no.
Even the compat MBR stuff GPT specifies doesn't work generically
across all BIOSes, or even most BIOSes. When I was futzing with GPT
last year I laid down a compat MBR just exactly the way GPT specified
it and my test machine refused to boot. I'll be more amendable
once the standard actually works across all new machines and not just
on so-called server-class machines.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]