Hacker News Reader

Comment by vbezhenar | Hacker News Reader

Apple trusts their hardware to do their own checksums properly. Modern SSD uses checksums and parity codes for blocks. SATA/NVMe include checksums for protocol frames. The only unreliable component is RAM, but FS checksums can't help here, because RAM bit likely will be flipped before checksum is calculated or after checksum is verified.

View on HN

If they do trust their hardware, APFS won’t need to checksum fs metadata either, so I guess they don’t trust it well enough? Also I have external drives that is not Apple sanctioned to store files and I don’t trust them enough either, and there’s no choice of user data checksumming at all.

Apple does not care about your external non-Apple drives. In the slightest.

Most SSD's can't be trusted to maintain proper data ordering in the case of a sudden power off.

That makes checksums and journals of only marginal usefulness.

I wish some review website would have a robot plug and unplug the power cable in a test rig for a few weeks and rate which SSD manufacturers are robust to this stuff.

I'd say it makes checksums even more important so that you know whether something got corrupted immediately and not after a year (or whatever) has gone by and you actually need it.

The problem is that if the SSD suffers a power failure and reverts a 1 megabyte block of metadata to the way it was yesterday, the filesystem won't see that as corruption - since all the checksums will match.

Yet all the pointers in that metadata will point to data which no longer exists, and your filesystem will be destroyed.

So... metadata checksums? I mean if enough data/metadata gets corrupted you're SOL either way.

For example, in ZFS the metadata is checksummed such that pointers to the data carry the checksum for that data.

Reply on news.ycombinator.com