For years, hardware RAID was simply what we used. Dell servers, RAID controllers, CentOS and Red Hat; it was the standard setup, and because it was standard, I never really questioned it.
Eventually, though, I started to wonder what the controller was actually buying us. It worked, but it also brought its own firmware, tooling, drivers and management layer, all sitting between Linux and the disks. None of that was catastrophic, but it was extra complexity, and over time that complexity started to feel increasingly difficult to justify.
So when we began deploying newer NVMe-based servers, I made the decision to try Linux MD RAID instead.
It turned out to be one of those infrastructure changes that is memorable mainly because of how little drama it created.
The problem isn’t hardware RAID. It’s treating hardware RAID as the default “enterprise” answer when you don’t actually need what it brings.
The problem was never really performance
The thing that frustrated me most about hardware RAID was the operational overhead around it.
We had vendor-specific utilities and controller firmware to deal with, and although Dell provided tooling for managing their controllers from Red Hat and CentOS, we never had a particularly good experience with it. There was always this slightly awkward separation between the operating system and the storage beneath it.
That bothered me because almost everything else we ran could be inspected and managed using normal Linux tooling. RAID felt like this separate proprietary island hidden underneath the OS.
More importantly, the controller itself became another dependency. If it failed, recovery potentially meant finding compatible hardware, worrying about firmware revisions and making sure the replacement controller understood the existing array.
With MD RAID, that concern mostly disappears. The RAID metadata lives with the member devices and Linux owns the array, so if a server dies, my main concern is getting those disks into another Linux machine rather than sourcing a particular RAID controller.
I much prefer that failure model.
We tested the performance
The obvious concern was whether moving RAID into software would cost us performance.
Historically, that was one of hardware RAID’s strongest arguments: dedicated hardware handled the RAID workload instead of the host CPU. On modern servers, particularly for the mirrored NVMe storage we were deploying, I wasn’t convinced that still mattered enough to justify the controller.
So we tested it.
The overhead was negligible for our workload, CPU utilisation wasn’t remotely concerning and the storage remained extremely fast. Once we’d established that, the decision became fairly straightforward. We were carrying an additional proprietary layer without getting a meaningful performance benefit in return.
That didn’t seem like a good trade.
Protected write cache is useful, but it isn’t free
There is an obvious counterargument here: good RAID controllers can provide battery-backed or otherwise protected write-back cache, and that can be genuinely useful.
I’m not dismissing that. For the right workload, it may be enough on its own to justify a controller.
The trade-off is that you’ve introduced another stateful component that needs maintaining. Batteries age, they fail, they eventually need replacing, and controllers may disable write-back caching when their protection mechanism becomes unhealthy.
I’ve dealt with that before, and while it isn’t some enormous operational burden, it is still another thing to monitor and maintain. If the workload genuinely benefits from it, fine. If it doesn’t, I’d rather not add the complexity simply because hardware RAID is traditionally considered the more enterprise option.
Disk replacement is about as simple as it gets
The day-to-day operational side is probably the clearest example of why MD works so well for us.
Our servers live in a data centre, so if a drive fails, we don’t physically touch the machine. We contact remote hands, tell them which drive in which server has failed, and because replacement drives are already kept in the rack, they swap it and tell us when they’re finished.
That’s the physical side done. The person replacing the drive doesn’t need to know anything about the RAID array, understand a controller interface or make any decisions about the storage. They replace the failed hardware, and we manage the array from Linux.
Once the new drive is visible, we add it back into MD using mdadm and let the array rebuild while the server remains online. Between mdadm --detail, /proc/mdstat and the normal Linux monitoring around it, there isn’t a separate storage-management world we have to drop into just because a disk died.
Remote hands replaces the hardware. Linux handles the array. That’s about as much ceremony as I want from a failed disk.
It’s a very clean separation of responsibilities, and operationally it works brilliantly.
This isn’t an argument against controller cards
I’m not anti-controller, either. The Dell PERC H200 is a great example of hardware I genuinely like; in an HBA/non-RAID role, it’s an excellent way to give Linux access to a pile of SAS or SATA disks while largely staying out of the way.
That’s useful hardware solving a real problem.
The distinction for me is whether the controller is simply providing connectivity or whether it also needs to own the RAID layout, metadata and recovery process. Sometimes it absolutely should. Other times, I’d rather let Linux handle it.
Hardware RAID still has a place
I’ve worked with systems where hardware RAID was unquestionably the right choice.
At a previous company, we ran an ESXi cluster backed by a SAN. The SAN used hardware RAID, and that made complete sense because it was a purpose-built storage appliance designed around that architecture. The management tooling was good, disk replacement was straightforward and the RAID implementation was part of the product rather than an extra layer bolted underneath a generic Linux server.
That’s very different from saying hardware RAID is automatically the right choice everywhere. The part I disagree with is the assumption that hardware RAID is inherently more serious, more reliable or more “enterprise” simply because it happens in dedicated hardware.
We don’t use MD RAID for everything either
The same logic applies in the other direction.
We use ZFS on some of our disaster recovery storage because the priorities there are different. For DR data, integrity matters above almost everything else, so end-to-end checksumming and scrubbing are valuable enough to justify using a different storage stack.
Our production NVMe servers have simpler requirements. We want redundancy, speed, straightforward recovery and as little unnecessary operational complexity as possible. For that job, MD RAID has been excellent.
Use the thing that actually fits
That’s really the point of all of this. Hardware RAID has its place, ZFS has its place, HBAs have their place, and MD RAID has its place. The interesting question isn’t which technology is universally best, because there isn’t one.
For our Linux production servers, MD removed a proprietary dependency, gave us excellent performance and made the storage easier to operate. If a drive dies, remote hands swaps it; if the server dies, the array isn’t married to a particular controller. The rest of the time, Linux simply gets on with managing it.
That’s why I chose MD RAID: not because hardware RAID is bad, and not because software RAID is always better, but because in this particular environment it was the simpler tool for the job.
