Data doesn't fly from CPU to disk. It has to pass the RAM, storage controller, some caches most of the time and then it reaches to the medium that stores the data.
Data can be corrupted in anywhere in this chain. Checksum or block can end up in a bad memory cell, your storage controller can bit-flip or the universe can corrupt your data on the bus. Larger storage systems also add more connections, controllers, caches and disks. So the probability increases. This is why your flash, RAID controller, transmission protocols, HDDs, RAM and everything in between have error correction capabilities in enterprise systems. However consumer systems lack some of these.
Also, not all data ends up in a cutting edge SSD. HDDs are still present and being produced. While HDDs also have some block level error correction, they are susceptible to bit rot.
At the end of the day, FS level checksumming is desirable but, it costs space and computation. Instead of reducing the runtime and performance of the computer, consumer devices rely on the recovery mechanisms of the hardware and prevent most of the problems most of the times with good-enough resiliency and reliability.
> Data can be corrupted in anywhere in this chain.
Of course, but most of this kind of corruption is trivial to recover from with just retries, that's why checksumming there works, but not on the filesystem level, where it can only detect corruption. What makes a bit more sense is something like erasure coding. Filesystem with erasure coding would probably be useful for all the broken FTLs on SD cards, eMMCs, SSDs, but at the end of the day wouldn't provide any significant level of resilience for a single disk to be worth the effort and the overhead. And checksumming alone still won't be useful.
> Of course, but most of this kind of corruption is trivial to recover from with just retries, that's why checksumming there works, but not on the filesystem level, where it can only detect corruption.
FS-level checksum saves you from the situation when the underlying storage thinks everything is okay but it is not:
> This means there was a data error on the drive. But it’s worse than a typical data error — this is an error that was not detected by the hardware.
> FS-level checksum saves you from the situation when the underlying storage thinks everything is okay but it is not:
It doesn't save you from anything, it just turns bit flips into full blocks of data loss and introduces overhead. If your application can deal with data loss it can deal with bit flips too. Filesystem-level checksumming is still useless.
Hardware not-handling bit flips is a documented phenomenon per my citations above. It does cause issues further up the stack. FS-level checksumming gives people the option to at least detect these errors, and depending on the situation, also perhaps fix them.
People already have a much better option by doing checksumming if necessary on the application level, much closer to the source of data actually with even less possibilities to miss corruption.
We don't have IP checksums, and only have TCP and UDP checksums because it's optional on Ethernet, and TCP/UDP doesn't always run over Ethernet anyway.
> Retries won't help you when the data was corrupted on its way to be stored.
Why not? This is exactly how such corruption is traditionally fixed. On crc error data is rejected before it is stored and retry then fixes the problem. And it's not that big of a deal either, only applications can get data checksummed in the earliest possible moment anyway. The hard part is automatically recovering from data loss and corruption later, which also makes it even unnecessary to verify if data is stored without corruption.
You are missing the point: checksums can't save you from data corruption and data loss. They are unnecessary without automatic recovery mechanisms and even make things worse.
> You are missing the point: checksums can't save you from data corruption and data loss.
No, I am not. The point is: checksums allow you to know that data corruption happened in the first place. Knowing this, you can then make informed decisions.
What saves you from "data corruption and data loss" is backups. But how do you know you have to go to backups if you're not aware that your data has problems?
> They are unnecessary without automatic recovery mechanisms and even make things worse.
Checksums allow you do know that there is a problem in the first place. If you don't know there's a problem, how can you invoke "recovery mechanisms", automatic or otherwise?
If you use (say) ZFS with some level of RAID-Z over multiple disks, then you get an "automatic recover mechanism". But even for a single-disk situation, it would be handy (for me at least), to know a file is bad so I can restore it from (say) my Time Machine backup.
But I have to know that the file is corrupted in the first place. And checksums would give me that.
> What saves you from "data corruption and data loss" is backups. But how do you know you have to go to backups if you're not aware that your data has problems?
It doesn't actually. It introduces inconsistencies unless on first detected corruption your filesystem stops all reads and writes until you recover corrupted block from backup and you might not even have it in backup, because backup is not synchronous replication.
> Checksums allow you do know that there is a problem in the first place. If you don't know there's a problem, how can you invoke "recovery mechanisms", automatic or otherwise?
You do your own appropriate checksumming suitable for recovery mechanism that you have. It's hardly as primitive as you think, because you have to respond fast, without corruption, transparently on request, you also have to schedule a check whether you actually need to heal anything, maybe it was a transient error, then mark it as corrupted, find what to resync from where, all of which also has to be fast, which means a bit complicated algorithms with sort of checksum databases on each replica, etc.
What do you do as a living? Because I think we are living in different realities.
I, as a sysadmin, have been helped by (ZFS) checksums multiple times. This includes times where I had to go to tape manually because the really expensive SAN has said "everything is fine" when it wasn't.
So telling me "checksums do not help" is contrary to my life experience.
I mostly speak from experience designing, implementing and operating a distributed database/storage system and traditional storages, databases before that.
And you've never seen the storage stack give back bad data?
You seem to be saying "checksums don't matter because there may be nothing we can do about about the corrupted data". So we should just blindly accept all the bits from the lower levels of the stack? We should do nothing to verify that those levels of the stack are working correctly?
You've mentioned application-level checksumming: yes, that would be good. But until every single dev adds code to checksum (and correct?) their data structures and file formats, having more checksums allows for beter information about when corruption occurs IMHO.
My point is checksumming is not a solution for data corruption, never was, never will be. It's only a tiny part of more complex algorithms and systems that detect and fix corrupted data automatically, never something usable on its own.
Data can be corrupted in anywhere in this chain. Checksum or block can end up in a bad memory cell, your storage controller can bit-flip or the universe can corrupt your data on the bus. Larger storage systems also add more connections, controllers, caches and disks. So the probability increases. This is why your flash, RAID controller, transmission protocols, HDDs, RAM and everything in between have error correction capabilities in enterprise systems. However consumer systems lack some of these.
Also, not all data ends up in a cutting edge SSD. HDDs are still present and being produced. While HDDs also have some block level error correction, they are susceptible to bit rot.
At the end of the day, FS level checksumming is desirable but, it costs space and computation. Instead of reducing the runtime and performance of the computer, consumer devices rely on the recovery mechanisms of the hardware and prevent most of the problems most of the times with good-enough resiliency and reliability.