The $300 LSI Card Question
It happens to every home-labber eventually. You’re browsing eBay at some unreasonable hour — let’s say 1:30 AM — and you find an LSI MegaRAID card for $40. The listing says “8-port SAS RAID controller, enterprise grade, pulled from a Dell PowerEdge.” Your brain does the math: enterprise. Eight ports. Forty bucks.
Before you click Buy It Now, let’s talk about whether you actually want that thing, or whether you want to flash it into oblivion and turn it into an HBA. Because in 2026, the “hardware RAID vs software RAID” conversation has a very different answer than it did in 2010 — and the wrong answer could mean your array is held hostage by a specific firmware blob long after the card has died.
Full example: Clone the working files at github.com/KingPin/sumguy-examples/linux/hardware-vs-software-raid
What Hardware RAID Actually Does
A hardware RAID controller is a dedicated card with its own processor, firmware, and usually some amount of onboard cache — typically 512MB to 2GB of RAM. It sits between your operating system and your disks, presenting a single logical volume to the OS. The OS sees “one big disk.” All the RAID math happens on the card.
The onboard cache is where things get interesting. Most enterprise RAID controllers support two cache modes:
- Write-through: Data is written to disk before the controller acknowledges the write to the OS. Safe, but slower.
- Write-back: The controller acknowledges the write as soon as data hits the cache, then flushes to disk later. Fast, but dangerous without a Battery Backup Unit (BBU) or supercapacitor+flash combo.
That BBU — the little battery pack hanging off the side of the card — is what justifies write-back cache in a power-loss scenario. If the power dies, the BBU keeps the cache alive long enough to flush it to disk (or preserves it until the system comes back up, if the card has a flash-backed write cache).
It’s a real engineering solution to a real problem. In 2005, when your CPUs were single-core and running RAID 5 parity in software would genuinely destroy your I/O performance, it made sense. Keep that context in mind.
HBA vs RAID Controller: Same Card, Different Firmware
Here’s the thing most people don’t realize when they’re buying used server hardware: a lot of RAID controllers and HBAs are the same physical card with different firmware. LSI — now Broadcom — has been doing this for years.
The LSI 9211-8i, for example, ships from the factory in IR mode (Integrated RAID) — it manages arrays in firmware. But flash it with IT mode firmware (Initiator-Target), and it becomes a pure HBA: a dumb pass-through that exposes your raw drives directly to the OS. Same PCIe lanes, same SAS expander, same port count. Completely different behavior.
IR mode (RAID controller): Firmware manages arrays. OS sees logical volumes. The card is in charge.
IT mode (HBA): Pass-through. OS sees raw disks. The software stack is in charge.
This distinction matters enormously depending on what software stack you want to run on top of it. And one filesystem in particular has extremely strong opinions about this.
The Single-Point-of-Failure Problem
Here’s the horror story format, because this stuff really does happen.
You build a NAS. You drop in an enterprise RAID controller — let’s say a Dell PERC H730 running IR mode. You create a six-drive RAID 6 array. Everything works great for three years. Then the H730 dies. Not a drive — the card. You buy a replacement, but you can’t find an exact match, so you grab an H730P. You pop in the drives, boot up, and…
The array won’t import.
The firmware metadata format changed slightly between card revisions. Or the new card’s BIOS version is different. Or the stripe-size encoding is subtly different. You call Dell support. They say the configuration database is stored on the card, not the drives. Your drives are fine — all six of them — but without the right card in exactly the right state, you can’t read your data.
Your array is literally held hostage to a specific piece of hardware.
This isn’t theoretical. It happens with HP Smart Array cards, older Dell PERCs, Adaptec cards, and plenty of others. Enterprise RAID controllers store configuration state on the controller itself, in a format that is proprietary and firmware-version-specific. That’s not a bug — it’s a design decision that made sense when the alternative was crashing your server with software RAID overhead. But it ages badly.
Software RAID metadata — whether mdadm superblocks or ZFS pool metadata — lives on the drives themselves. Your array survives controller death because the array state moves with the drives, not with the card.
Why ZFS Wants HBAs, Not Hardware RAID
ZFS is opinionated about a lot of things. One of them is this: it wants to see raw disks. Not logical volumes. Not RAID sets presented by a firmware layer it can’t inspect. Raw. Disks.
This isn’t stubbornness. It’s architecture. ZFS is an end-to-end storage stack — it handles checksumming, error detection, and data repair at the filesystem layer. Every block gets a checksum. Every read is verified. If a block comes back wrong, ZFS knows and can repair it from a mirror or parity vdev.
But here’s where hardware RAID becomes a problem: it hides errors.
When a drive has a bad sector, a RAID controller’s firmware will often silently remap it. The OS never sees the error. ZFS never sees the error. The checksum on the affected block might be fine — the controller faked a successful read by substituting zeros or returning stale data. ZFS can’t detect corruption it’s never told about.
Hardware RAID also intercepts SMART data. ZFS and mdadm both benefit from per-drive health monitoring — smartmontools can catch a drive that’s accumulating reallocated sectors long before it fails. Through a hardware RAID controller in IR mode, you often can’t get SMART data at all. The drives are invisible to the OS.
On top of that: TRIM/discard commands don’t pass through most RAID controllers. If you’re running SSDs behind a hardware RAID card, you’re not trimming. Your SSDs will degrade over time in ways they wouldn’t if the OS had direct access.
For ZFS specifically: run it behind an HBA in IT mode, not behind a RAID controller in IR mode. This is not optional. It is the recommendation of every ZFS project, OpenZFS documentation, and anyone who has cleaned up a corrupted ZFS pool after running it through a RAID controller that was helpfully fixing errors behind ZFS’s back. Check the ZFS vs Btrfs article for more on why the checksumming layer matters so much.
The CPU Cost of Software Parity (It’s Basically Free)
The main historical argument for hardware RAID was CPU overhead. In 2005, running RAID 5 parity in software on a dual-core Xeon was a real performance hit. Your I/O latency would suffer. Application performance would suffer. You needed a dedicated processor on the card to handle the XOR math.
In 2026, this argument is almost entirely dead.
Modern CPUs — anything from the last several years on the AMD or Intel side — include AVX2 and AVX-512 instruction set extensions. Linux’s mdraid RAID stack uses these extensions for vectorized XOR calculations. The result: RAID 6 parity calculation on a modern CPU costs almost nothing at real-world scale.
We’re talking single-digit CPU percentage during active RAID 6 parity writes across 24 drives on a midrange Ryzen or EPYC. During a scrub — which is the most CPU-intensive operation mdraid does — you’ll see a bump, but “a bump” on a 16-core processor means you’ve still got 15 cores sitting around doing nothing.
The cpu-overhead-test.sh script in the example folder lets you measure this yourself. It creates loop devices, assembles them into a RAID 6 array, runs fio workloads, captures mpstat during a scrub, and prints a summary. No real drives involved — entirely safe to run on any Linux box. You’ll probably be unimpressed by how little CPU it uses, which is exactly the point.
For dRAID and RAID-Z variants, the story is similar — see the ZFS RAID-Z and dRAID article for the ZFS-specific numbers and a breakdown of how dRAID improves rebuild performance. And for nested RAID levels like RAID 50/60, the RAID 50/60 article covers how those layer on top of what we’re discussing here.
Where Hardware RAID Still Wins
Honesty requires acknowledging the niches where hardware RAID with a real BBU still makes sense.
High-frequency synchronous writes on spinning drives. If you have a legacy application that does a ton of fsync() calls — databases, certain financial applications — and your drives are spinning rust, a RAID controller with write-back cache and a BBU can meaningfully improve performance. Every fsync() call hits the cache instead of waiting for the drive head to park. This is real, measurable, and was the killer feature of enterprise RAID cards for decades.
Windows-only shops that haven’t moved to Storage Spaces. If your shop runs Windows and isn’t using ReFS or Storage Spaces (or doesn’t want to), hardware RAID is the path of least resistance. Windows software RAID (dynamic disks) has its own limitations, and the integration story isn’t as clean as Linux mdraid.
Certain SAN environments. Fiber-channel SANs with their own storage controllers, where the RAID logic is embedded in the SAN itself and the host never needs to see raw drives. The controller-per-host model doesn’t apply here in the same way.
Hardware that doesn’t support pass-through. Some older server platforms, or systems where the SAS controller is embedded on the motherboard and can’t be flashed, don’t give you a choice. You run what you’ve got.
For everything else — ZFS pools, mdadm arrays, any Linux-native storage stack on hardware you control — software RAID via an HBA is the better default.
IT-Mode Flashing: The LSI Card Redemption Arc
Most of the RAID controllers you’ll find on eBay in the LSI 9211, 9300, and 9400 families can be reflashed to IT mode. This turns a $40 RAID controller into a $40 HBA, which is genuinely useful. The 9211-8i in IT mode is one of the most recommended HBAs for home ZFS builds — eight SAS ports, PCIe 2.0 x8, and drives appear as raw disks to the OS.
The short version of the process: you need a UEFI-bootable USB drive, the IT mode firmware image for your card, the sas2flash utility, and patience. The card is flashed to a blank state first (the “crossflash” step), then the IT mode firmware is written.
I’m deliberately not including a shell script for this. Flashing firmware is one of those operations where if something goes wrong at the wrong moment — power loss, wrong firmware for your card revision, crossed-up SBR file — you end up with a card that won’t POST. It’s not catastrophic (you can usually recover with a UEFI shell if you’re persistent), but it’s not the kind of thing you want to run as a one-liner.
The flash-lsi-it-mode.md in the examples folder is a full procedure document: prerequisites, hardware-specific caveats, the exact steps, and recovery options if something goes sideways. Read it fully before touching anything. Link it to your actual LSI card model number and cross-reference with the ServeTheHome guides, which remain the best community documentation on this.
The Decision Tree
| Scenario | Recommendation |
|---|---|
| ZFS pool on Linux | HBA in IT mode. Non-negotiable. |
| mdadm array on Linux | HBA in IT mode, or motherboard SATA/SAS direct. |
| Existing HW RAID array, working fine | Leave it. Don’t migrate for the sake of it. |
| HW RAID controller died, array won’t import | This is what we warned about. Pray for an identical card. |
| Legacy app needing write-back cache + BBU | Keep the RAID controller. Or add NVMe write cache. |
| Budget home lab, 4–8 drives, no existing card | Motherboard SATA + mdadm or ZFS is fine. |
| More drives than motherboard SATA ports | Buy an HBA. LSI 9211-8i or 9300 series in IT mode. |
| Windows environment | Storage Spaces, or HW RAID. mdadm doesn’t apply. |
| Buying an eBay LSI “RAID card” for ZFS | Flash it to IT mode before you plug in drives. |
A few notes on the table. “Motherboard SATA + mdadm or ZFS is fine” is genuinely true for most home lab scenarios. If you’ve got 6–8 drives and your board has 6 SATA ports plus a PCIe slot, a cheap HBA handles the rest. You don’t need a RAID card. You definitely don’t need a RAID card with a BBU. You need raw disk access and a CPU that stopped being impressed by XOR math sometime around 2018.
If you want to benchmark your own storage setup before committing to an architecture, fio disk benchmarking covers setting up realistic workloads. Run the numbers before you buy hardware — not after.
For the rebuild math on large arrays and why RAID 6 (two-drive failure tolerance) is strongly preferred over RAID 5 for anything over 4TB drives, see RAID reliability and recovery and RAID 6 vs RAID 10. RAID levels without two-drive failure tolerance are increasingly uncomfortable recommendations on modern large drives — the RAID 0/1/5 explainer has the baseline context.
Real Talk
The hardware-RAID-or-bust orthodoxy is a relic. It made sense when CPUs were slow, when software RAID implementations were immature, and when the alternative to a BBU was genuine data loss on power failure. None of those constraints apply in the same way in 2026.
Linux mdadm is production-quality software. It’s been running in production environments for over two decades. It stores array metadata on the drives themselves. When your server board dies, you pull the drives, put them in any Linux box, run mdadm --assemble --scan, and your array comes right back up. No firmware negotiation. No card-specific metadata format. No calling the vendor to get your own data back.
ZFS is in a different category entirely — it’s a complete storage stack with end-to-end checksumming, snapshots, send/receive, and a level of data integrity guarantees that no hardware RAID controller can match at the filesystem layer. Put ZFS over an HBA and you have a setup that’s both more reliable and more portable than any enterprise RAID card arrangement.
The $300 LSI card question from the intro has an answer: buy the $40 one, flash it to IT mode, and spend the other $260 on drives or RAM. Your storage stack will thank you. Your 2 AM self — the one who can migrate that array to any box with SAS ports — will really thank you.
