Corrupting a ZFS File on Purpose

That distinction drove most of the conversation. Several people pushed back on the idea that disks usually fail by loudly returning read errors and that random byte edits are therefore unrealistic. The stronger answer was that storage fails in messier ways than that. Drives can silently return wrong data, firmware can write to the wrong LBA, and a mirror without higher-level checksums cannot tell which copy is the good one once the two disagree. Commenters also pointed out that bit rot is not just a theoretical archival edge case. People have seen silent corruption on old cold-storage disks, large files with many small writes, and SSD firmware bugs where the device reported success while ZFS kept finding and healing bad blocks. The thread landed on a sober view of storage integrity. Hardware ECC helps with common low-level errors, but it only proves the device can read back what it thinks it wrote. It does not prove the OS asked for the right block, the firmware handled the write correctly, or the returned block belongs to the requested address. That is why ZFS checksums and self-healing are valuable, and why serious archival setups still add duplicate media, geographic separation, and tools like PAR2 instead of trusting any single layer.