Disk array controller: Difference between revisions

Revision as of 20:55, 29 November 2021

Revision as of 23:57, 16 February 2022

Line 48:

Unlike the [[network interface controller]]s 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.{{r|lyrics-38}}

For example, in [[FreeBSD]], in order to access the configuration of [[Adaptec]] RAID controllers, users are required to enable [[FreeBSD#OS compatibility layers|Linux compatibility layer]], and use the Linux tooling from Adaptec,{{r|f-aac}} potentially compromising the stability, reliability and security of their setup, especially when taking the [[long term]] view in mind.{{r|lyrics-38}} 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, <code>mfiutil</code> and <code>mptutil</code> is available for FreeBSD since FreeBSD 8.0 (2009),{{r|mfiutil|mptutil}} as well as <code>mpsutil</code>/<code>mprutil</code> since 2015,{{r|mpsutil}} 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 {{section link|data scrubbing#RAID}} 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 [[hw.sensors#drive|drive sensor]]) for health monitoring;<ref name=theo-misc-38/> this approach has subsequently been adopted and extended by [[NetBSD]] in 2007 as well.{{r|sensors-mmath}}