You are correct. The ethernet frames use CRC32 while the IP frames use 16-bit CRC. While the checksums need not be of cryptographic quality (and not all checksum algorithms in ZFS are), there are multiple trivial ways in which the wrong data can match a CRC32 checksum and that is inadequate for the purposes of data integrity. It does help, but it does not go far enough.

As for my assertion that btrfs uses 64-bit CRC on 64-bit processors, this was the result of a misunderstanding between myself and the btrfs developers in #btrfs on freenode last year. I double checked with them and it turns out that you are correct that btrfs uses 32-bit CRC even on 64-bit processors. That makes btrfs much worse in this area than I previously thought.

Thanks for clearing some of the confusion about btrfs send/receive on its snapshots. To be clear, does this mean that btrfs will refuse to send a "writeable snapshot"?

I think the triviality and inadequacy are overstatements for the following two reasons: it's rare to have undetected errors in normally operating hardware that simultaneously go undetected by Btrfs. If this doesn't go far enough, then I'm challenged how to characterize the vast majority of the world's data on NTFS, HFS+, ext234, and XFS as being anything but fragile and tenuous, which would be an overstatement. What is going far enough? It's a use case question rather than something absolutely determinable. For a general purpose filesystem, I think CRC-32C is adequate, although it will be nice when there's choice for another algorithm to meet other use case requirements.

Yes, it won't send writable snapshots. e.g. ERROR: /mnt/root is not read-only.