Re: Best RAID configuration

> Either get more disks or scrap the idea of RAID with only 3 disks. While it
> is "true" that you can create a raid set with just 3 drives, the second you
> lose on drive, you start corrupting data. We have used the HP line of

No you don't, unless more than one of your drives is defective, or you have a defective controller or defective cabling.

3-drive RAID-5 configurations can run with a single drive failure. Otherwise, there'd be totally no point to RAID at all.

> servers in test environments and with in 15 minutes of a failed disk (the
> length of time to go from my office to the server room), all data was
> corrupted.

Then the HP machine and/or it's RAID controller has serious problems. I build hardware RAID-5's rountinely with 3 drives and usually DPT or Mylex controllers, and have never encountered any problems whatsoever dealing with data corruption with respect to a single failed drive.

> While the performance of the HP raid controller is probably the best I have
> ever tested, you simply must have no less than 6 drives. Configure 5 as

The HP's work just fine with 3 drives.

> your actual container then configure the 6th as an automatic fail over.
> Also make sure you have disk 7 in a drawer somewhere close. HP takes up to
> two weeks to replace a defective drive.

Well, good sets of backups and a variety of manufacturing dates on the drives is the strategy that I use.

> When using raid, there really isn't a lot of sense in partitioning.

Yes there is. Partitioning makes the restoration process proceed much more quickly than it would if there wasn't any partitioning. With partitions, one can re-install the operating system (or restore it from tape or from an image saved on another machine) to the boot partition, and then fire up the backup software and restore the rest of the machine.

After all, complete RAIDset failures, while rare, do happen, and human error does happen. Keep good backups.

> Admittedly, partitioning let's you view the os, applications and data as if
> they were on separate disks, but access of any file on any partition still
> impacts access to other files on other partitions. The only way to limit

Indeed, but such accesses still would be occuring, and thus, the impact is pretty much the same whether partitioned or not partitioned.

> this impact with a raid set is to throw a lot of ram on the raid
> controller's cache. Your most frequently used files will be cached and

Well, for a very highly loaded machine, yes, that's good, but there is little, if any performance impact by making a partition or two (one for the operating system, one for the apps, and the other for the data is what I use around here..).

> written by the controller in a very acceptable method which limits
> contention. But you need a lot! 512MB is not uncommon

On the main machine, or course. On the raid controller, that's severe overkill in most situations. Received on Sun Nov 14 1999 - 14:38:00 CST