DragonFly BSD
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?)

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 28 Jul 2010 11:02:10 -0700 (PDT)

    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

    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.


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