Re: DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I still don't get your point. GPT support in the loader is not
:> assisted in any way by geom or any other similar mess.
:>
:
:The gpart class is a helper of the loader.  It creates the normal gpt boot
:partition unlike the hack that exists in gpt(8)
:
:
: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.
:
:
:The gmirror sync after an unclean disconnect is greatly reduced on gjournal
:volumes, I haven't timed it lately but it's something like 1 to 2 minutes
:for TB+ sized volumes.
:
:-- 
:Adam Vande More

    Urm.  What's the point of a mirror if you need a third journaling
    device which itself can fail or glitch?  Do you mirror the journal too?
    I have serious problems with this concept, and also with the complexity
    and the number of moving parts involved.

    And what about the massive assumptions being made regarding the
    survival of on-device write caches, write bandwidth constrictions,
    the lack of integration with filesystem-derived cache flushes, the
    duplication of effort when used with filesystems which have their
    own UNDO/REDO journals?  Is there any device stall management?

    I'll be frank, the FreeBSD stuff is a non-starter for me.  If we
    tried to run something like gmirror and/or gjournal with HAMMER the
    performance would be abysmal.

						-Matt