"Jeff Quast" writes: > On 10/3/06, Joerg Zinke <[EMAIL PROTECTED]> wrote: > > On Mon, 02 Oct 2006 20:11:36 +0200 > > nothingness <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > > > I've been using RAIDFrame on OpenBSD since 3.1 and in 4 years I've > > > never seen any performance improvement in getting the system to work > > > any faster at rebuilding parity after a hard shutdown. I've tried > > > RAID1, RAID5, SCSI drives, IDE drives, processors from PentiumII 400s > > > to Athlon64 3200+ and it has *always* been ridiculously slow at > > > rebuilding. Just a 9G RAID5 partition takes over 2 hours. A 60G RAID1 > > > takes 11 hours. 11!!! Before flaming me to say, just go and edit the > > > code, it's never been out of beta or whatever, explain why compared > > > to other OSes it's always so slow, even to build the first time > > > around. Linux's code in particular comes to mind. > > > > maybe this is one of the reasons why raidframe is not officially > > supported and not enabled in stable kernel. i think another reason is > > or that it doubles the size of a kernel for a function <5% of openbsd users > use.
RAIDframe on i386 archs used to be about 500K, which is ~10% of the current size of /bsd. In a certain other BSD, RAIDframe now weighs in at about 148K for i386. [snip] > Raidframe was originaly a simulator. A simulator. It was never meant > to be a kernel driver. It is not meant to ensure speed. It is not > meant to actualy be used to store real data. RAIDframe was developed as a framework. It wasn't just a simulator. It wasn't just a user-land RAID driver. It wasn't just a kernel driver. It was built with all three to allow rapid prototyping of new types of RAID. Yes, there is some overhead to this, but it's not as large as the code size might suggest... (e.g. compare the performance difference between CCD vs RAID0..) Later... Greg Oster
