:> 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.
:
:Can you give me some pointers as for w
> 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.
Can you give me some pointers as for where to
On 28/07/10 21:58, Adam Vande More wrote:
> [...]
> It's not just that combination though. HammerFS could be used on other
> modules like gvinum, gconcat, etc, etc.
>
> I'm interested in using Dragonfly for some embedded system, but having
> more GPL stuff is essentially a non-starter for me as w
On Wed, Jul 28, 2010 at 3:31 PM, Matthew Dillon wrote:
>
>
> 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
: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 sof
On Wed, Jul 28, 2010 at 11:39 AM, Alex Hornung wrote:
> I absolutely don't see how forcing the I/O from N different threads
> onto 2 (events are not I/O effectively) is better than having each I/O
> maintain (mostly) it's own context. Your particular case may not
> suffer from any performance imp
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
On 28 July 2010 17:14, Adam Vande More wrote:
> [...]
> Well it's 3 main actually(up, down, and event threads basically), and
> depending on the module you can spawn other kernel threads to handle
> asynchronous stuff to pass off when it's ready. The design has awfully nice
> performance characte
On Wed, Jul 28, 2010 at 2:13 AM, Alex Hornung wrote:
> 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
