I’m still sad that this filesystem does not contain file data checksums. It looks like we will be stuck with it for some years to come.
Apple File System Reference [pdf]
11–20 of 67 posts
Re: Apple File System Reference [pdf]
#12I’m still sad that this filesystem does not contain file data checksums. It looks like we will be stuck with it for some years to come.
Care to enlighten ignorant me why we would want that?
Re: Apple File System Reference [pdf]
#13Earlier quoted context omitted.
There is already one third-party-implementation in the works. They sure find this helpful in their efforts. https://github.com/sgan81/apfs-fuse
This is user space – hopefully a kernel level one will come out as a result of this. Or does it matter, performance-wise? People that know more can chime in.
Yes, FUSE is slower than in-ring0 implementation, even by the sheer overhead of the syscalls.
Re: Apple File System Reference [pdf]
#14I’m still sad that this filesystem does not contain file data checksums. It looks like we will be stuck with it for some years to come.
Care to enlighten ignorant me why we would want that?
Not OP, but probably to make sure the contents of a file are not changed by hardware errors.
Re: Apple File System Reference [pdf]
#15One of my long-time favourite macOS applications -- iDefrag -- had support withdrawn shortly after APFS appeared. Reasons cited were lack of an APFS spec and increased System Integrity Protection.
I fear this is too little, too late to have iDefrag make a comeback. I understand defragmenting an SSD typically does more harm than good [edit: and I only defrag spinning drives), but nothing touched it for effectiveness on spinning drives.
https://coriolis-systems.com/iDefrag/
https://coriolis-systems.com/blog/2017/9/what-works-macos-10...
Re: Apple File System Reference [pdf]
#16The 'Fusion' section at the end is interesting. macOS 10.13 didn't convert Fusion drives to APFS, but 10.14 will. Presumably this specific support for Fusion drives is new in 10.14.
HFS+ had no knowledge about Fusion drives, the caching was handled entirely at block-level by the lower CoreStorage layer (although later versions did add some flags so CoreStorage could pin metadata/swap blocks to the SSD).
Now what I'm really interested to see is if they open-source the filesystem driver along with the macOS 10.14 code drop. HFS+ (and its utilities) has always been open-source, last year APFS was not.
Re: Apple File System Reference [pdf]
#17Earlier quoted context omitted.
Care to enlighten ignorant me why we would want that?
Not OP, but probably to make sure the contents of a file are not changed by hardware errors.
Yep, otherwise you aren't able to detect bit level errors unless they impact the metadata, and the metadata is a tiny fraction of your total storage.
That said, your hard drive already does block level checksumming so doing it at the FS layer is mostly redundant unless the errors are being introduced in your SATA controller or on the PCI bus.
Re: Apple File System Reference [pdf]
#18Earlier quoted context omitted.
Care to enlighten ignorant me why we would want that?
Not OP, but probably to make sure the contents of a file are not changed by hardware errors.
You would still need end-to-end integrity checking, unless your Mac came with ECC memory (which it probably didn't).
Re: Apple File System Reference [pdf]
#19Good find. Wonder if there's as much doc of ZFS/OpenZFS.
Re: Apple File System Reference [pdf]
#20This seems like it's probably enough to re-implement APFS on non-Mac platforms; in fact, the about page (page 6) says as much. Kudos to Apple for providing the information. It's a hell of a lot better than reverse engineering the thing (see how many years it took to get NTFS down...)
Likely enough to create third-party disk recovery utilities.