The reason I was given is twofold. 1) If your RAID card dies it's nice to be able to plug drives into any controller and be able to access the data. 2) "look at how often MDADM fix bugs. Now look at how often your RAID card firmware gets fixed... use MDADM".
Modern filesystems like btrfs & zfs both prefer to deal with the RAID aspects themselves as it gives them far more control. Even if you're a hardware raid afficianado, I wouldn't recommend formatting (eg) ZFS on top of a hardware raid pool.
It was updated plenty, from 1.58(B) (earliest I can find) to 6.64(B)
https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX-...
I'm not recommending some abstract hardware RAID, I'm recommending this particular card for personal use, with backup obviously. Although if you just use RAID 0 or 1, then data is perfectly readable outside of RAID with a normal SATA controller.
+ Raid 5 requires BBWC + Raid 6 requires licensing + HPE requires a support contract to download most firmware + When used in servers, they report non-hp drives as being in a constant fault state.
why wouldn't you use it if you have it?
> Raid 6 requires licensing
Keys are out there and can be googled, in any case you probably don't need RAID 6 or any extra features for personal use
> HPE requires a support contract to download most firmware
Um, firmware for this card is on the page I linked, free as in beer
> When used in servers, they report non-hp drives as being in a constant fault state
I wouldn't know, haven't seen anything of the sort personally
Nice to see firmware available - in 2014 HP started requiring support contracts or warranties to download firmware updates for the servers which really turned me off them. I didn't realise RAID firmware wasn't included in that (for some reason iLO firmware isn't either, but I think that's probably because it includes OSS). For this reason alone I'd avoid HP on principal.
I'm hoping one day I can find a reasonably cheap RAID card that still supports using hte BBWC in JBOD mode...
hardware raid has the hw complexity / pickyness you mention, but also is safer in crashes for checksumming raid levels (e.g. 4,5,6) since the stripe checksum happens from controller->disk in hardware rather than os->controller->disk in software, so you're less likely to lose a stripe due to OS issues (all else - like bugs - being equal)
also, IO wise, any mirrored raid is going to require N*mirrors of IO on the system bus, so you're more likely to saturate it
that said, with faster tech (NVMe), individual drives can easily saturate a single card, so its 'worth' paying the multiple IO pentalty multiplexed onto multiple individual lanes since the card is more likely to be the bottleneck than the bus
also, hw raid controllers even in jbod mode might be needed to get enough device fanout, though you're not using the controller for raid in that case
Recently with super powerful multi-core CPUs being the norm especially in places where RAID is a consideration, hardware RAID makes less and less sense. You just create additional complications like when moving your RAID array between 2 otherwise identical cards but with different firmwares fails. So you end up always buying spares and testing the migration before putting any data, then you freeze the config in place. On the other side you may be stuck forever with a buggy firmware.
On the server side, the tendency is now towards vertical striping (directly addressing disks on multiple servers through the network with software).
Is that new?
I have always been told to avoid hardware raid when possible.
It's great that you've had good experiences with this particular hardware RAID controller and are recommending it to others, but it's also the case that there are legitimate reasons to avoid all hardware RAID cards in some setups.
Too bad it's not possible to boot from it in HBA mode too.