hi there,
i have a mission critical system with an unsuported
raid controller (4 sata channels, sil 3114). so, i set
up a software raid... now, the problem is at pick
hours, when nics hardware interrupts compete with the
software raid kernel thingie... i know you avoid
spawning threads but regarless the scheduller's
preeptivenes, the two kernel tasks are scheduller-wise
competing and this is killing my server (slowing it
down, cpu is at 100% user and 40-60% kernel). another
issue is that not being able to "see" the "bios"
partition (controller is totally unsuported) i cannot
boot (unless i go like raid 1 on /boot). so what about
performance? what about scalability? if case of 1
array (hardware raid) versus n distinct sata
connectors, you big o notation goes like O(n) instead
of O(1), no matter how smart the scheduller _is_
implemented, for the simple reason that hardware
interrupts are hardware interrupts... preemptive or
not, you have to serve them sooner or later and it's
one thing to sever 1 instead of n... another issue is
reliability. if you use software raid, and the kernel
goes down (for unrelated reasons) your parity
calculations and the raid cache go down as well, huh?
and the other way around... the raid goes down, taking
the sata driver with him... that takes the whole
system down, huh? well, maybe i am too pesimistic but
still, the scalability concern remains! nics are huge
scheduller enamies... they have to do so much with
cpu, and transfers to system memory, in order to
actually server thier purpose (protocols) it seams to
me that there isn't much left for user-land and
software raid... (especially when many nics and many
satas are involved...)
in short, could you recommend me a peformant (sata
connectors) raid controller, which is fully supported?
please don't go like "make gconfig" cause i've been
there... thanks!
regards,
daniel
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]