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.
that the actual raidframe implementation is not the best - citation of a
developer: "the code is crap"... but hey its open source, go, go, go:
You really shouldn't speak hearsay when it comes to source code. Its
open source, look yourself and make a judgement. It should only take
about two minutes to make a basic judement call
rewrite it :)
i use a 250 gb raid 1 and tooks 3h to rebuild parity on an athlon 2600
(32-bit).
regards,
joerg
If you really hate it so much, ^c it. Its just ensuring your parity.
Skip it if you don't like it. I occasionaly do. If you want speed, and
not reliability, then skip it and use stripe. This is like complaining
fsck_ffs is too slow. Don't complain when data is lost during a power
failure because you never bothered to ensure parity (or do not use
backups, use battery backups, or just keep trying to use emulated
opera with macromedia flash player)
I find tests with iozone to prove that a stripe of two 55MB/s disks
perform at 110MB/s almost to do the decimal, showing that raidframe
does a fantastic job.
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. You're lucky you have it.
You should thank the author for making it a kernel driver.
rough parity consitancy check estimates of my own:
4-disk + spare raid5. U160 scsi, 15k rpm drives @ 20GB: ~3 minutes
2-disk raid0. U160 scsi, 15k rpm drives @ 8gb: ~2 minutes or less
3-disk raid5. 1 sata, 2 ide, (desktop-class disks) @ 260GB: ~50 minutes
raidframe is a theorm in action. It is old. I'm sure alot of functions
(including parity check) could be rewritten to perform much better
with modern processor designs in mind. That is your job. If you can't
handle it, then spend money on a true hardware raid card.
* (Don't get an adaptec onboard like me, or you'll still be using raidframe :) *
PS: You're post included no dmesg or patch.
You are just complaining. WHAaaaaaa :(
