[ale] Linux support for Intel Matrix Storage Manager?

James P. Kinney III jkinney at localnetsolutions.com
Tue Dec 13 16:10:48 EST 2005


On Tue, 2005-12-13 at 16:30 -0400, Jeff Hubbs wrote:
> >2. Is it common practice to put the root partition on the RAID along with 
> >the other partitions, or to use a regular drive separate from the RAID for 
> >this?
> >
> Much depends on why you're using RAID in the first place.  If 
> disk-failure survivability is the goal, then nothing should be on *any* 
> drive that will be bring you down or keep you from booting if it goes 
> out - not root, not swap, nothing. 
> 
> I've developed a pet peeve since disk drives started going beyond 9GB or 
> so.  I don't like splitting up individual physical disk drives into 
> matching sets of partitions so that I can make RAID volumes across 
> corresponding partitions on the various drives.  Why?  Because if one 
> partition on one drive develops a bad block, I have to disrupt healthy 
> (and potentially more critical) RAID volumes when I pull the drive with 
> the bad block, and I have to endure degraded disk I/O while ALL the RAID 
> volumes rebuild at once when I put the replacement drive in.
> 
> This is why I wish that the industry would still produce 2, 4, and 8GB 
> drives that are just butt-fast and butt-reliable.  It seems to me that 
> the dot-com-boom drive to sell 1U and 2U servers forced these two- and 
> four-drive configurations on the world had a lot to do with making 
> multiple RAID volumes across the same set of drives a common practice.  
> That, and WinNT's default "C Drive = Only Drive" combined with admins 
> who had never before dealt with multi-disk/RAID systems and how you can 
> use different kinds of drives and RAID levels to optimize a machine for 
> what it's going to be doing.

Huzzaa! Great points, Jeff. My solution to this for max reliability is:
1GB CF for / (to house /boot, /sbin, /bin, /root, /etc -NOTE putting etc
on this is getting harder with everything being part of the distribution
and it all goes in /etc now).
2 drive raid that houses /var, swap and /tmp. This requires that I move
database files for postgresql and mysql and /var/www on RH/Fedora
systems. /var is RAID0 and the other 2 are RAID1 for speed.
Most of my systems these days are LAMP boxes. So database and apache
gets pounded on. I much prefer separate RAID5 schemes (3 hot plus 1
spare) for database files (I had been getting small 15k rpm 9GB SCSI LVD
drives and putting them on their own controller until recently - PCI-X
controller cards are F A S T) and similar for the apache files.
/home is typically where the apache files get located in a hosted setup
so it is the mount point for the apache raid.

Recently, I've been using almost all SATA drives. The cost of the
multiple controllers is low enough that I have been able to stuff the
box with 3-5 (and whole MESS of fans for the 10+ drives I use...).

To realize Jeff's process requires skipping SATA and going SCSI. 9 GB
SCSI are still produced in large quantities. They are BUTT fast and BUTT
reliable. With proper case design and the correct scsi controller
card(s), hot swap is possible to minimize service interruption.

I have not seen hot-swap SATA yet. SATA still can't support the
sustained throughput of SCSI. SATA _still_ doesn't get hot enough to fry
eggs on like SCSI (thankfully :) since it only recently added 10k rpm
and has another 1-3 years to get 15k. By then, SCSI will be up to 25-30k
and 1280 MB/s sustained transfer rate. And also using separate power
supplies fro the drive components is likely (I'm thinking phase-change
cooling at this point).

> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part




More information about the Ale mailing list