Because the hardware RAID controllers present assembled
RAID 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 the
open-source software driver, with extended features being provided through
binary blobs directly by the hardware manufacturer. Normally, RAID controllers can be fully configured through card
BIOS before an
operating 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 the
network interface controllers for
Ethernet, which can be usually be configured and serviced entirely through the common operating system paradigms like
ifconfig in
Unix, 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 a
vendor lock-in, and contributing to reliability issues. For example, in
FreeBSD, in order to access the configuration of
Adaptec RAID controllers, users are required to enable
Linux compatibility layer, and use the Linux tooling from Adaptec, potentially compromising the stability, reliability and security of their setup, especially when taking the long term view in mind. 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 and mptutil is available for FreeBSD since FreeBSD 8.0 (2009), as well as mpsutil/mprutil since 2015, each supporting only their respective device drivers, this latter fact contributing to
code 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 and from within the operating system without having to reboot into card BIOS. For example, this was the approach taken by
OpenBSD in 2005 with its
bio(4) pseudo-device driver and the
bioctl utility, which provide volume status, and allow LED/alarm/hotspare control, as well as the sensors (including the
drive sensor) for health monitoring; this approach has subsequently been adopted and extended by
NetBSD in 2007 as well. With
bioctl, 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, 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. ==References==