Quentin, spot on! One point I failed to digress to is power -- beware, when taking your first stabs at raid arrays, not to overload your system power supply. When a normal PC powers up, all its drives spin up in sequence, and the load is a sudden high power draw, which can blow out commonly-available supplies with ...enough drives. Anyway, another keen benefit of dedicated controllers is that many will sequence the spin-up to avoid overload. You'll prolly notice that many also have battery-backup on their own cache. If you're using a dedicated controller, this is still critical during failure even if you're using resier, ext4, etc journaled filesystems.
And if you're having some fun running some basic tests with the mobo(s) you have laying around, check out the built-in chipsets: your built-in controller might not be fast enough to keep up with two drives per channel (pata stuff, yeah) but I think occasional devices like a CD-rom won't interfere. YMMV as always, and figuring it out for yourself is purrfect if you have enough guidance on what to look for :) Well have fun, morph single drives into new array-creatures, and I think you'll find software raid to be very suitable and convenient once you get the hang. Did we not even mention LVM in this thread?? heh heh ben On Nov 16, 2007 2:49 PM, Quentin Hartman <[EMAIL PROTECTED]> wrote: > On Nov 16, 2007 2:07 PM, Ben Barrett <[EMAIL PROTECTED]> wrote: > > > Right on, thanks Quentin -- this better-defined "fakeraid" is much > > worse than soft-raid in many cases, > > I'd amend this to say _all_ cases. <overbroad inflammatory statment>Fakeraid > is a technological abomination, created by marketing departments and > unchecked capitalistic market forces.</ois> > > <snip> > > > modern CPU's are *plenty* fast enough to > > maintain throughput using simple soft-raid. > > > > Anecdotal data point: My home server is running on a 1Ghz Via C3 processor. > I have a 3+1 software Raid 5 array in it. The processor is fast enough to > saturate a 100MB ethernet connection copying data off the drives over NFS, > but not over Gb. When I copy stuff via Gb, throughput is very bursty, but > probably averages out to about 400-500Mb / sec > > > > > > I have not seen the most recent benchmarks or fully examined the > > latest HA (high-avail) compromises, but SCSI is still much better that > > SATA (bye, PATA) for high-volume multithreaded uses needed for many > > email, DB, web, and other servers. > > I have been tracking this stuff pretty closely, so I'll throw another few > cents based on my experiences. I've found that SCSI's primary advantage over > SATA comes from access time and IOPs (I/O operations per second). Unless you > have a workload that specifically requires it, SCSI is generally not worth > the money, even in "important" servers for business. I've found that it ends > up being more economical to have several "cheap" SATA-based servers than one > big SCSI(or SAS) based server. Of course, there are cases where this is not > true; per server license costs can influence this as well as the > clusterability of whatever service or application you are running. I've > gotten to the point though that I tend to "cheap cluster" by default, and > only "big iron" when there are specific factors that make cheap cluster not > work. > > That being said, SCSI's edge over SATA isn't quite as thin as it seems on > paper, where even in areas like seek time and IOPs some SATA drives are > challenging SCSI. There are the intangibles. The firmware on SCSI drives > tends to be a little more conservative, and the drives tend to be tested to > somewhat higher standards. These two items combined lead to more reliable > drives. Another somewhat intangible advantage is that the hardware that > surrounds and supports SCSI drives tends to be higher quality than that > which is built to support SATA. This leads to an overall better experience. > All in all, SCSI still has quite a few advantages over SATA, but the simple > "it's just always better" is no longer true. > > > > If this isn't making any sense to you, I'd like to simply propose the > > breaking and recovery of a raid array at a public function like the > > eugene celebration. I would be happy to bring down a sledgehammer and > > provide the single drive which we'll rip out and destroy (to great > > effect but in a contained manner). After that hooplah, a simple > > showing of the recovery: rebuilding in progress, etc, and some > > well-planted statements from the audience about whether this reliable > > and well-supported, free technology could help our government's > > accountability or something :) > > > > This would be hilarious. I too have some donatable drives... > > -- > -Regards- > > -Quentin Hartman- > _______________________________________________ > EUGLUG mailing list > [email protected] > http://www.euglug.org/mailman/listinfo/euglug > > _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
