This is what worries me about the current push that all backups including the off site tape vault must be encrypted at rest. Any problem with the de-encryption and your data is toast.
My understanding is that many SSDs do encryption transparently. The ATA protocol even has a “SECURE ERASE” command that instructs the drive to wipe just the encryption key. This allowed even “bad blocks” to be erased securely.
Tapes at rest don't have to worry about that though.
Most filesystems do not do any error correction. ZFS, btrfs, ReFS, bcachefs are a few notable exceptions. And for the most part these schemes are for multiple device resilience - which is architected quite differently from the schemes used in an SSD or tape (yes, even tape).
> Tapes at rest don't have to worry about that though.
This isn't really true. Pretty much every physical medium at the densities used in modern time requires robust error correction because all physical media has flaws either manufactured or acquired from wear and degradation. For instance, modern LTO tapes use relatively robust 2D Reed-Solomon forward error correction similar to DVD/Blu-Ray.
It would be wonderful if they all have the feature, but I thought only ZFS was really that paranoid.
No it doesn’t.
Many journal filesystems use a checksum for log entries, but that is certainly not covering every block of the filesystem with a checksum. And that checksum only comes into play during log recoveries. Once a block is committed to disk there is no checksum in play (unless the fs has special support for it).
Some newer journaling filesystems support metadata checksumming, but that is not some requirement to be journaling. XFS has not always supported metadata checksumming, and it’s a relatively recent addition to ext4 (like last decade). NTFS doesn’t do checksums on even metadata. This is one reason why ReFS is a thing.
False. A limited number of filesystems keep checksums of data - most notably ZFS and btrfs. Some like ext4 and APFS will do it for metadata only. One of the most commonly used filesystems, NTFS, does not for either data or metadata.
> Typically it's done at the filesystem level or higher, including when using self-encrypting drives.
I don’t know where you got this idea from, but it’s basically the opposite of true.
> If single bits are flipped then they can be corrected.
Also false. Most checksums are used for error detection, not correction. CRCs as are typically used for filesystems are not particularly well suited for error correction.
Also, look into TCG Pyrite. Almost all consumer drives with SED features are Pyrite.
At least 2 people have informed you that you’re wrong. Now it’s up to you if you choose to educate yourself on this topic or remain a fool.
> Checkdisk isn't powered by magic.
What is “checkdisk”? If you’re talking about chkdsk, or Check Disk, or fsck like tools - none of those require checksums to do what they do. At a basic level they check the integrity of on disk data structures - the actual connectivity, valid counts, etc. How in your mind does a checksum contribute to this task?
Chkdsk exists for FAT32, which you already seem to admit has no checksums. How do you think it works?
> Also, look into TCG Pyrite. Almost all consumer drives with SED features are Pyrite.
What does this have to do with anything - it certainly isn’t filesystem level encryption.
Modern hardware tries to detect these sorts of things and halt before the corruption is propagated. Sometimes it succeeds, sometimes it does not.
The best checksums can reliably do is point at the software/hardware component that is at fault.