Disks lie.

Sorry, but what you write just proofs what the author is writing and i'm writing. Don't trust the hardware. Armor the data with as much additional integrity and validity checking mechanisms as possible.

And Oracle DB for example do this at great length: Like checksums, like redo logs, and yes ... HARD as well. Especially as Oracle DB prefers nothing in between itself and the rotating rust, it has to do on it's own and can do it in a way tailored for databases.

But a lot of data is unstructured, not in databases. Many filesystems don't offer this kind of protection for the data they store. NTFS, extfs, UFS, HFS. We trust a lot of data to storage that can't protect the data and leaves data protection to higher layers, which is often not done ...

ZFS is one exception. Brtfs another one. I consider both important steps forward in order to protect the data.

Of course: Using better hardware will reduce the probability of problems, but you can never totally rule out problems, the ability and wisdom of nature to find failure modes that break even the most well thought-trough protection is vast and infinite. Thus i would armor data with additional independent integrity information. Eg. I would never switch oracle checksums just because my disk array is using fat blocks. I wouldn't stop to use ZFS, just because my array has fat blocks.

And at the end you have still the "rust can't compute"-problem. Without read after write you don't really know if the data is really on the disk, because the rust can't say to you "yup, i've got the data". At the moment that problem is solved by writing redundant information so you are able to repair when everything else fails.

And then think about all the filesystems and databases not using higher-end/midrange storage.