3 ms·

> 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 jus

• throw0101a 7y ago
  It tells you that your data is corrupted, which gives you options on dealing with the situation. > If your application can deal with data loss it can deal with bit flips too. No, it may not. The file may mostly be okay except for a place where a single bit flip causes the value to go from positive to negative: * https://en.wikipedia.org/wiki/Signed_number_representations https://en.wikipedia.org/wiki/Signed_number_representations 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.
  • zzzcpan 7y ago
    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.
    • throw0101a 7y ago
      Yes, doing it at the application level would be better. But doesn't preclude it doing it at other layers as well. It's why we have Ethernet checksums, IP checksums, TCP/UDP checksums, etc. Defense in depth.
      • monocasa 7y ago
        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.
        • throw0101a 7y ago
          Headers: * https://en.wikipedia.org/wiki/IPv4_header_checksum https://en.wikipedia.org/wiki/IPv4_header_checksum Skipped in IPv6.