Upgrading an M4 Pro Mac mini's storage for half the price

The article speculates on why Apple integrates the SSD controller onto the SOC for their A and M series chips, but misses one big reason, data integrity.

About a decade and a half ago, Apple paid half a billion dollars to acquire the patents of a company making enterprise SSD controllers.

> Anobit appears to be applying a lot of signal processing techniques in addition to ECC to address the issue of NAND reliability and data retention. In its patents there are mentions of periodically refreshing cells whose voltages may have drifted, exploiting some of the behaviors of adjacent cells and generally trying to deal with the things that happen to NAND once it's been worn considerably.

Through all of these efforts, Anobit is promising significant improvements in NAND longevity and reliability.

https://www.anandtech.com/show/5258/apple-acquires-anobit-br...

> The article speculates on why Apple integrates the SSD controller onto the SOC for their A and M series chips, but misses one big reason, data integrity.

If they're really interested with data integrity they should add checksums to APFS.

If you don't have RAID you can't rebuild corrupted data, but at least you know there's a problem and perhaps restore from Time Machine.

For metadata, you may have multiple copies, so can use a known-good one (this is how ZFS works: some things have multiple copies 'inherently' because they're so important).

Edit:

> Apple File System uses checksums to ensure data integrity for metadata but not for the actual user data, relying instead on error-correcting code (ECC) mechanisms in the storage hardware.[18]

* https://en.wikipedia.org/wiki/Apple_File_System#Data_integri...

> If they're really interested with data integrity they should add checksums to APFS.

Or you can spend half a billion dollars to solve the issue in hardware.

As one of the creators of ZFS wrote when APFS was announced:

> Explicitly not checksumming user data is a little more interesting. The APFS engineers I talked to cited strong ECC protection within Apple storage devices. Both NAND flash SSDs and magnetic media HDDs use redundant data to detect and correct errors. The Apple engineers contend that Apple devices basically don't return bogus data.

https://arstechnica.com/gadgets/2016/06/a-zfs-developers-ana...

APFS keeps redundant copies and checksums for metadata, but doesn't constantly checksum files looking for changes any more than NTFS does.

> Or you can spend half a billion dollars to solve the issue in hardware.

And hope that your hardware/firmware doesn't ever get bugs.

Or you can do checksumming at the hardware layer and checksumming at the software/FS layer. Protection in depth.

ZFS has caught issues from hardware, like when LBA 123 is requested but LBA 456 is delivered: the hardware-level checksum for LBA 456 was fine, and so it was passed up the stack, but it wasn't actually the data that was asked for. See Bryan Cantrill's talk "Zebras All the way Down":

* https://www.youtube.com/watch?v=fE2KDzZaxvE

And if checksums are not needed for a particular use-case, make them toggleable: even ZFS has a set checksums=off option. My problem is not having the option at all.

When the vast majority of the devices you sell run on battery power, it makes far more sense from a battery life perspective to handle issues in hardware as much as possible.

For instance, try to find a processor aimed at mobile devices that doesn't handle video decoding in dedicated hardware instead of running it on a CPU core.