Adisk array controller is a device that manages the physicaldisk drives and presents them to the computer aslogical units. It often implementshardware RAID, thus it is sometimes referred to asRAID controller. It also often provides additional diskcache.
Disk array controller is often ambiguously shortened todisk controller which can also refer to the circuitry responsible for managing internal disk drive operations.
A disk array controller provides front-end interfaces and back-end interfaces.
A single controllermay use different protocols for back-end and for front-end communication. Many enterprise controllers use FC on front-end and SATA on back-end.
In a modern enterprise architecture disk array controllers (sometimes also calledstorage processors, orSPs[1]) are parts of physically independentenclosures, such asdisk arrays placed in astorage area network (SAN) ornetwork-attached storage (NAS)servers.
Those external disk arrays are usually purchased as an integrated subsystem of RAID controllers, disk drives, power supplies, and management software. It is up to controllers to provide advanced functionality (various vendors name these differently):
A simple disk array controller may fit inside a computer, either as aPCI/PCIeexpansion card or just built onto amotherboard. Such a controller usually provideshost bus adapter (HBA) functionality itself to save physical space. Hence it is sometimes called aRAID adapter.
As of February 2007[update]Intel started integrating their ownMatrix RAID controller in their more upmarket motherboards, giving control over 4 devices and an additional 2 SATA connectors, and totalling 6 SATA connections (3 Gbit/s each). For backward compatibility one IDE connector able to connect 2 ATA devices (100 Mbit/s) is also present.
While hardware RAID controllers have been available for a long time, they initially required expensiveParallel SCSI hard drives and aimed at the server and high-end computing market. SCSI technology advantages include allowing up to 15 devices on one bus, independent data transfers,hot-swapping, much higherMTBF.
Around 1997, with the introduction ofATAPI-4 (and thusUltra-DMA-Mode, which enabled fast data transfers with lessCPU utilization) the first ATA RAID controllers were introduced as PCI expansion cards. Those RAID systems made their way to the consumer market, for users wanting the fault-tolerance of RAID without investing in expensive SCSI drives.
Fast consumer drives make it possible to build RAID systems at lower cost than with SCSI, but most ATA RAID controllers lack a dedicated buffer or high-performance XOR hardware for parity calculation. As a result, ATA RAID performs relatively poorly compared to most SCSI RAID controllers. Additionally, data safety suffers if there is nobattery backup to finish writes interrupted by a power outage.
Because the hardware RAID controllers present assembledRAID volumes,operating systems aren't strictly required to implement the complete configuration and assembly for each controller. Very often only the basic features are implemented in theopen-source software driver, with extended features being provided throughbinary blobs directly by the hardware manufacturer.
Normally, RAID controllers can be fully configured through cardBIOS before anoperating system is booted, and after the operating system is booted,proprietary configuration utilities are available from the manufacturer of each controller, because the exact feature set of each controller may be specific to each manufacturer and product.Unlike thenetwork interface controllers forEthernet, which can be usually be configured and serviced entirely through the common operating system paradigms likeifconfig inUnix, without a need for any third-party tools, each manufacturer of each RAID controller usually provides their own proprietary software tooling for each operating system that they deem to support, ensuring avendor lock-in, and contributing to reliability issues.[2]
For example, inFreeBSD, in order to access the configuration ofAdaptec RAID controllers, users are required to enableLinux compatibility layer, and use the Linux tooling from Adaptec,[3] potentially compromising the stability, reliability and security of their setup, especially when taking the long term view in mind.[2] However, this greatly depends on the controller, and whether appropriate hardware documentation is available in order to write a driver, and some controllers do have open-source versions of their configuration utilities, for example,mfiutil andmptutil is available for FreeBSD since FreeBSD 8.0 (2009),[4][5] as well asmpsutil/mprutil since 2015,[6] each supporting only their respective device drivers, this latter fact contributing tocode bloat.
Some other operating systems have implemented their own generic frameworks for interfacing with any RAID controller, and provide tools for monitoring RAID volume status, as well as facilitation of drive identification through LED blinking, alarm management,hot spare disk designations anddata scrubbing § RAID from within the operating system without having to reboot into card BIOS. For example, this was the approach taken byOpenBSD in 2005 with itsbio(4)pseudo-device driver and thebioctl utility, which provide volume status, and allow LED/alarm/hotspare control, as well as the sensors (including thedrive sensor) for health monitoring;[7] this approach has subsequently been adopted and extended byNetBSD in 2007 as well.[8]
Withbioctl, the feature set is intentionally kept to a minimum, so that each controller can be supported by the tool in the same way; the initial configuration of the controller is meant to be performed through card BIOS,[7] but after the initial configuration, all day-to-day monitoring and repair should be possible with unified and generic tools, which is what bioctl is set to accomplish.