ICP vortex GDT RAID Controllers
Manufacturer: ICP Vortex
Price: $1595 US for GDT6518RD $2195 US for GDT6538RD (volume pricing available)
Reviewer: Eric Lee Green
ICP Vortex is a German company that has been a long-time supporter of Linux. The ICP driver was written by ICP and has been included in the Linux kernel since the Linux 1.3 days, and their RAID configuration utility (gdtmon) runs natively under Linux. While ICP is the largest supplier of RAID hardware in Europe, they appear to have a low profile here in the U.S. compared with Mylex, Adaptec and AMI.
What ICP provides is a number of RAID cards ranging from a low-cost one-channel RAID0,1 controller to a series of high-end fibre-channel controllers. All ICP cards work with Linux and are supported by current Linux distributions “out of the box”, with the exception of Red Hat 6.0, where the ICP driver was inexplicably left off the boot disk despite being on the install menu. A fixed boot disk is available from Red Hat's FTP site or directly from ICP.
First, a bit of background: RAID is a method for combining disk drives for either performance or reliability purposes. There are a number of approaches to doing RAID. Software RAID is built into the Linux kernel. “Pure” hardware RAID has the SCSI controller(s) actually built into the PCI card. There are also hybrid approaches that have the advantage of being cheap but requiring specially equipped motherboards (usually with what is called a “RaidPort”) or double the PCI bandwidth in order to run.
The biggest advantages of “pure” hardware RAID are low CPU usage, robustness, minimal bus bandwidth usage and avoiding the underlying limit in the number of SCSI devices that can be addressed by the Linux SCSI driver architecture. The Linux SCSI subsystem can access a maximum of sixteen hard drives (labeled sda through sdp). By presenting the multiple drives in a RAID array as a single drive to Linux, hardware RAID bypasses that limit.
The first problem was deciding which ICP RAID controller to test. It was easy to discard the low-end and high-end controllers. The 61xx series, which does only RAID0 and RAID1, is slower than the built-in Linux software RAID. The fibre-channel controllers work well under Linux using the EXT2 file system, but Linux support for file systems capable of using the fibre-channel drives as fibre-attached storage (shared between multiple machines) is in experimental stages at best.
To decide which to use, I turned to the two most common uses of RAID under Linux: web and news servers.
Web servers typically have three drives, a hot spare. With 4.5GB SCSI hard drives, this would give them 9GB of usable disk space. Note that 9GB SCSI drives are generally twice as fast as 4.5GB, so that would also be an option. A one-channel 6518RD works fine in this application.
News servers need massive amounts of disk space. A news server capable of backing up the entire USENET news hierarchy for a month will probably need at least twelve 36GB hard drives. My informal benchmarks show that an IBM 7200rpm 36GB hard drive transfers data at approximately 25MB/sec, while Ultra2 SCSI has a bandwidth limit of 80MB/sec. Thus, four drives per channel would be a good “seat of the pants” estimate here, requiring a 3-channel RAID controller. The 6538RD, one of their “mid-range” controllers, was chosen to be the second card evaluated.
The ICP controllers come in a fairly hefty box containing the controller, a CD with drivers and utilities, and a hefty wire-bound manual. The CD also contains a full PDF version of that manual as well as any addendums and errata created since the manual was published.
Examining the 6518RD uncovered an Intel 960 CPU, a Symbios 53c895 SCSI chip set, a Symbios 53c860 chip and various small support chips. There is also a socket for cache SIMM. This also serves as the Intel 960's scratch memory, so the controller will not operate without it.
The 6518RD and 6538RD both contained the 53c860 Ultra-SCSI chip to handle CD-ROM and tape drives on a separate narrow-SCSI bus. Thus, the 6518RD can actually be considered a two-channel device, though it has only a single Ultra2 RAID channel. Despite having two channels, the 6518RD has a single external SCSI connector on the back. Annoyingly, this connector goes to the Ultra2 controller. Note that attaching any non-LVD devices to an Ultra2 bus will slow it down to non-LVD speeds, i.e., 40MB/sec, so hooking that tape drive to this connector would be a serious mistake. An external tape drive will require a special cable bringing out the internal narrow SCSI to a socket on the back of the computer.
The 6538RD looked similar to the 6518RD, but was longer in order to hold the two additional 53c895 chips. It has three of the high-density SCSI connectors on the back. Similar to the 6518RD, only the Ultra2 channels are brought out to the external connectors. The workaround if you have an external tape device is the same: bring the internal narrow-SCSI connector out to an external connector using a special cable.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide