SMP

2010-07-28 Thread Przemysław Pawełczyk
I workd with NetBSD and OpenBSD for some time a few years ago. I used mostly NetBSD on my PC. My question is. I have read that DragonFly is targeted to SMP but I was unable to find out any information concerning the subject. How it runs on up-to-date MoBos (e.g. AMD), how it compares to NetBSD, Re

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

2010-07-28 Thread Alex Hornung
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

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

2010-07-28 Thread Adam Vande More
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

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

2010-07-28 Thread Matthew Dillon
: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

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

2010-07-28 Thread Adam Vande More
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

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

2010-07-28 Thread Matthew Dillon
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

Re: Is it time to dump disklabel and use GPT instead?

2010-07-28 Thread Chris Turner
elekktrett...@exemail.com.au wrote: that is incompatible with everything else on the market. You're not going to get Linux to change because of BSD, it's the other way around. At least man socket()

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

2010-07-28 Thread Alex Hornung
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

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

2010-07-28 Thread Adam Vande More
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

Re: Is it time to dump disklabel and use GPT instead?

2010-07-28 Thread Alex Hornung
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 easier than the Linux equivalents. The mdadm > stuff is reliable