Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

APFS not having block or file-level checksums really seems like a big oversight to me. While the filesystem’s designers considered the hardware-level guarantees to be sufficient [1], this issue shows that there is an entire class of problems that they have not considered. Disk images and loopback-mounted filesystems or even disk-level cloning introduce additional layers of complexity where a filesystem can be silently corrupted, even when the actual physical storage layer is perfectly reliable.

A filesystem should be able to last for decades (HFS was designed thirty years ago); I regard not having checksums in a brand new filesystem an over-optimistic tradeoff.

[1] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part5/



Apple HFS+ didn't have file data checksums either. The default filesystem on most Linux distributions, ext4 doesn't, it just stores checksums of the file metadata, not the file data. Same story with Windows NTFS filesystem. Microsofts newer ReFS filesystem has file data checksums disabled by default. So it seems like a tradeoff that most of the major operating system are making. Most likely related to performance.

Edit: macOS disk images do have a checksum of the whole image data though. The issue mentioned in the article seems to be caused by an oversight in the disk image helper app, rather than in the APFS filesystem itself.


Performance is only an issue if your disk can write faster than your CPU can hash. hammer2 changed its hash a couple of years ago because this started happening with newer NVMe drives[0], but before that disk writes weren't CPU-bound.

[0] http://lists.dragonflybsd.org/pipermail/commits/2016-June/50...


What about: * Disk reads may unnecessarily trash the CPU caches, because CPU will need to verify the checksum when the DMA read is done, even if the app isn't going to process the data immediately afterwards * Battery life - without checksums the CPU can stay mostly idle, and go into a lower power mode, while the disk controller does its job


APFS not having block or file-level checksums really seems like a big oversight to me.

It wasn't an oversight; it was a deliberate design decision.

Others replies have noted that maybe it was a performance issue, etc. But I think it's something much different. The real reason is that there is more downside than upside to reporting these errors.

Users would be very upset if iOS told them that there was a bad block in one of their precious selfies from last month. But they might not even notice or care about a few bad pixels in the image itself.

I'm just telling you what one big probable rationalization was for this decision. I'd personally want to know, but people on HN aren't "average" IOS users.


That's not really any better. That just supports the narrative that Apple only cares about frivolous uses of their devices ("toys") and aren't serious about supporting Pro users (who will definitely want to restore corrupt files from backups)




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: