4 ms·

Say you have a bug that corrupts data which somehow happens after writes so filesystem level checksums can detect it and you run that filesystem on desktop/lapt

Say you have a bug that corrupts data which somehow happens after writes so filesystem level checksums can detect it and you run that filesystem on desktop/laptop/mobile without redundancy. Does it actually help you with anything since you can't correct that error on the same filesystem level? Of course not. Does it at least prevent inconsistency? No, it doesn't unless failed checksums stop filesystem from doing new reads and writes. So the only sensible place for checksumming is on the level where such errors can be automatically corrected. Without redundancy that's just your disk controller or applications designed with data recovery in mind that also can do checksumming, not filesystems though.

bayindirh 7y ago
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.
- zzzcpan 7y ago
  > 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.
  - vardump 7y ago
    > Of course, but most of this kind of corruption is trivial to recover from with just retries... Retries won't help you when the data was corrupted on its way to be stored.
    - zzzcpan 7y ago
      > 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.
      - throw0101a 7y ago
        > > Retries won't help you when the data was corrupted on its way to be stored. > Why not? 1. Data is fine in memory 2. Data is fine over PCIe. 3. Data is corrupted by firmware bug in storage controller. 4. Data (now corrupted) is sent to disk, which generates checksums for each LBA, and sends the bits to the storage medium. 5. Some time later the data is requested, disk reads bits from sectors, checksums pass, corrupted data is sent back up the stack to the application. This is not a fantasy scenario: * http://www.cs.toronto.edu/~bianca/papers/fast08.pdf http://www.cs.toronto.edu/~bianca/papers/fast08.pdf * https://storagemojo.com/2007/09/19/cerns-data-corruption-research/ https://storagemojo.com/2007/09/19/cerns-data-corruption-res...
        zzzcpan 7y ago
        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.
        7y ago
throw0101a 7y ago
> Does it actually help you with anything since you can't correct that error on the same filesystem level? Of course not. Given that I run Time Machine, yes it does: it tells me I have to restore the file from a backup. I also use SuperDuper to create bootable clones on a rotating set of drives that I take to work for offsite backup, so the file would probably be there as well. (Though this is a bit extreme for a non-geek to do.)

bayindirh 7y ago

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.

zzzcpan 7y ago
> 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.
- vardump 7y ago
  > Of course, but most of this kind of corruption is trivial to recover from with just retries... Retries won't help you when the data was corrupted on its way to be stored.
  - zzzcpan 7y ago
    > 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.
    - throw0101a 7y ago
      > > Retries won't help you when the data was corrupted on its way to be stored. > Why not? 1. Data is fine in memory 2. Data is fine over PCIe. 3. Data is corrupted by firmware bug in storage controller. 4. Data (now corrupted) is sent to disk, which generates checksums for each LBA, and sends the bits to the storage medium. 5. Some time later the data is requested, disk reads bits from sectors, checksums pass, corrupted data is sent back up the stack to the application. This is not a fantasy scenario: * http://www.cs.toronto.edu/~bianca/papers/fast08.pdf http://www.cs.toronto.edu/~bianca/papers/fast08.pdf * https://storagemojo.com/2007/09/19/cerns-data-corruption-research/ https://storagemojo.com/2007/09/19/cerns-data-corruption-res...
      - zzzcpan 7y ago
        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.
        7y ago

throw0101a 7y ago

> Does it actually help you with anything since you can't correct that error on the same filesystem level? Of course not. Given that I run Time Machine, yes it does: it tells me I have to restore the file from a backup. I also use SuperDuper to create bootable clones on a rotating set of drives that I take to work for offsite backup, so the file would probably be there as well. (Though this is a bit extreme for a non-geek to do.)