A peculiarity of “hardware” is that it can also make actual monitoring of the physical disks’ SMART status problematic, even when just using an enterprisey SAS controller with optional RAID features to hook up a few SATA disks. I’m still years behind, so hopefully this has been fixed for my particular hardware, but your mileage may vary with some of the weirder “make 2 _ a RAID volume!” enclosure-type devices out there.

What you point out… for a home user, replicating between disks… that is what HAMMER excels at with its mirror-stream functionality.

As for swapcache, yes, I don’t know if the cache contents survive a reboot. It’s possible with an SSD of course, though there may be valid reasons for that not to happen. I was thinking about writes mainly, that had gone to cache but had not been completely committed to spinning disk before the power failed. Reads you don’t care about, as that data is on the spinning disk already.

I don’t know if swapcache survives a reboot – even a normal one. The data has to be read off disk at least once, to be cached in the first place. If it does survive and the on-disk data locations haven’t changed, I would think that it works normally.

The problem with hardware RAID is that the on-disk formats are generally proprietary, so you can’t just take your RAID disks and stick them in another machine with a different controller if your original controller dies.

For enterprise-y environments, hardware RAID is still in many cases the best option. For home users, and Google, and Facebook, replicating the data across multiple disks and/or machines using standard hardware is often a better approach.

Out of curiosity, does swapcache reconstruct what it can onto the spinning disk when recovering from a power failure?