DragonflyBSD GEOM? (Re: Is it time to dump disklabel and use GPT instead?)
dillon at apollo.backplane.com
Wed Jul 28 13:35:30 PDT 2010
: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.
More information about the Users