I do understand the point the article's author is trying to make, but honestly, it is ridden with misconceptions and sounds just like the fanboys he is trying t

I do understand the point the article's author is trying to make, but honestly, it is ridden with misconceptions and sounds just like the fanboys he is trying to enlighten. While CRC algorithms are used everywhere (and some provide data recovery to some extent), they do have their limitations. It is perfectly possible to read corrupted data from a disk. I know this because I've seen it happen several times over the years. If your system is making decisions (ie generating new data) based on read information, this can actually be quite harmful. Like it or not, transitional errors on to-be failing disks may cause data corruption. It is easy to say "hey, restore from backups!", but it may happen weeks go by before an actual failure happens. By then you don't know if your backups are tainted, and how long was your storage misbehaving. ZFS actually helps with this, because it can tell you explicitly that your file/block is tainted, even if readable. This provides a level of confidence on the system, based on observability. And snapshots can actually refer to different blocks, so it is often possible to recover a previous version of a given file without firing up the backup system. Also, the idea you need RAID for healing is nonsense - ZFS can keep multiple copies of your block even on a single-disk system. To finalize on the "bitrot" topic, keep in mind network communications, as most serial protocols, have varying degrees of CRC and checksum checks at different levels of the stack, following the end-to-end principle. We even use compression and encryption on top of that, that also provides multiple verification methods. Yet most relevant files such as iso images have a checksum file to verify your download - and sometimes it doesn't match. ZFS provides you the same functionality, but for your storage.