do you think the archives are poo too, or do you plan to read them?
I have already read the archives. You keep saying, there is no plan to import
it. However you did created a patch for OpenBSD 3.2, so maybe you or someone
else could write (for the archives) *why* there isn't any plan to
On Mon, 29 Aug 2005, Ed White wrote:
do you think the archives are poo too, or do you plan to read them?
I have already read the archives. You keep saying, there is no plan to import
it. However you did created a patch for OpenBSD 3.2, so maybe you or someone
else could write (for the
On Sat, 27 Aug 2005, Jim Razmus wrote:
Just curious, what does the dev team think about Vinum?
the conclusion is it doesn't do anything you can't do now.
--
And that's why I started this thread.
I want a raid model that acts as if it is a regular scsi drive, ie.
sdN. Like our hardware raid controllers work. Right now what we
have in the tree is poo, and vinum is just as much poo too.
Is there any hope to see the live network backup that NetBSD's developer
der Mouse presented at
On Sun, 28 Aug 2005, Ed White wrote:
And by the way, do you think that NetBSD's cgd is poo too, or do you plan to
import it?
do you think the archives are poo too, or do you plan to read them?
--
And that's why it's so good.
Is there any hope to see the live network backup that NetBSD's developer
der Mouse presented at BSDCan 2005?
( http://www.bsdcan.org/2005/activity.php?id=54 )
I may not be a developer of OpenBSD, but I think that anything Mike Parker
says or does should be ignored, just because of the kind of
* Nick Holland [EMAIL PROTECTED] [050825 07:22]:
Edd Barrett wrote:
rather then trying more stupid band-aids and wuergarounds it would be
fantastic if someone could sit down and get us a software raid
implementation that doesn't suck and thus can be included in the regular
kernels.
I
Just curious, what does the dev team think about Vinum?
I want a raid model that acts as if it is a regular scsi drive, ie.
sdN. Like our hardware raid controllers work. Right now what we
have in the tree is poo, and vinum is just as much poo too.
I do not envision enabling this stuff in
rather then trying more stupid band-aids and wuergarounds it would be
fantastic if someone could sit down and get us a software raid
implementation that doesn't suck and thus can be included in the regular
kernels.
I havent noticed anything terribly wrong with raidframe. Why do you
think it
Edd Barrett wrote:
rather then trying more stupid band-aids and wuergarounds it would be
fantastic if someone could sit down and get us a software raid
implementation that doesn't suck and thus can be included in the regular
kernels.
I havent noticed anything terribly wrong with raidframe.
Edd Barrett wrote:
Hi there,
Is there any reason why we can not include a raid enabled kernel in
the distribution? (not as default, but in the same way bsd.mp is).
I believe this would save me (and others?) time when upgrading OpenBSD
machines.
The kernel would need static device node
For one, what if you don't want RAID_AUTOCONFIG?
It would save YOU time if we set the options you needed. If not, it
would cause more complaints about how could you chose such an option?
True
Further, it would probably need to be TWO new kernels -- bsd.raid and
bsd.raid.rd, as you would
One point in favour of a GENERIC RAID Kernel(s), consider when a user
posts the following request for help:
'I've compiled my own kernel and Xyz is broken'
Now after being on the mailing list for a quite a while I know the stock
answer always seems to be 'drop back to GENERIC and stop playing
Hi there,
Is there any reason why we can not include a raid enabled kernel in
the distribution? (not as default, but in the same way bsd.mp is).
I believe this would save me (and others?) time when upgrading OpenBSD machines.
The kernel would need static device node configuration, device raid
14 matches
Mail list logo
