alt Hacker NewsChecksum offload, recalculating a bad checksum after corrupting the data, is really insidious.
Shows that trust in TCP can be badly misplaced -- in this case the trouble was cache coherency, but lack of ECC RAM or other electrical gremlins could easily corrupt packets too (and NIC buffer RAM is never ECC afaik), and blindly trusting TCP checksums would eat your data every time.
(Side note, doesn't 'zfs send' blindly trust TCP checksums?)
Props to Rsync and SSH and Wireguard and everything else that went beyond the call of duty to keep your data safe, with varying levels of alertness.
Replies
> Streams are checksummed, so corruption introduced by the network or by intermediate storage is detected on receive.
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Oper...
I've set up all NFS mounts within my home LAN over WireGuard partly for this exact reason. The impacts to bandwidth and latency are negligible, and even the increase in CPU usage remains relatively low (at least on non-ancient hardware). This reduces some of my worries about silent data corruption (at least from this potential source).
zfs send/recv doesn’t do networking on its own?
> (Side note, doesn't 'zfs send' blindly trust TCP checksums?)
No.
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data...
> End-to-end checksums are a key feature of ZFS and an important differentiator for ZFS over other RAID implementations and filesystems. Advantages of end-to-end checksums include:
> [...]
> - checksums on ZFS replication streams, zfs send and zfs receive, ensure the data received is not corrupted by intervening storage or transport mechanisms
Edit: Also, as Asmod4n points out in a sibling comment, neither zfs send nor zfs recv actually transmit or receive any data. They just generate a data stream that you are then responsible for handling somehow (piping to e.g. ssh, redirection to a file, etc).