Live data from Hacker News

Apple File System Reference [pdf]

developer.apple.com

21–30 of 67 posts

Re: Apple File System Reference [pdf]

#21
post #6
post #4

This 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...)

Agreed. I was honestly expecting a more hand-wavy explanation, but I was surprised that they dived into so much detail on, e.g., the structs used to represent various objects in APFS.

[deleted]

Re: Apple File System Reference [pdf]

#22

One 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 o…

I haven't defragged a disk in almost a decade. When is defragging an SSD ever a good thing?

I only have spinning rust in my (older) NAS or as backup drives.

Re: Apple File System Reference [pdf]

#23
At last! Apple's old APFS docs always had this mysterious note about Fast Directory Sizing:

"You cannot enable Fast Directory Sizing on directories containing files or other directories directly; you must instead first create a new directory, enable fast directory sizing on it, and then move the contents of the existing directory to the new directory."

but there was never any documentation on how to do this, and no Apple engineer would say. The most common internet theory seemed to be that this feature was purely automatic, and all mentions (like this) in the docs were just incredibly misleading.

Now it seems we have an answer, in this flag: "INODE_MAINTAIN_DIR_STATS: The inode tracks the size of all of its children."

Re: Apple File System Reference [pdf]

#24
post #22

One 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 o…

I haven't defragged a disk in almost a decade. When is defragging an SSD ever a good thing? I only have spinning rust in my (older) NAS or as backup drives.

Probably often but there is no way to tell really because the controller has a mind of its own and they are all different.

Re: Apple File System Reference [pdf]

#26
post #22

Earlier quoted context omitted.

I haven't defragged a disk in almost a decade. When is defragging an SSD ever a good thing? I only have spinning rust in my (older) NAS or as backup drives.

Probably often but there is no way to tell really because the controller has a mind of its own and they are all different.

> Probably often

Defragging an SSD is often a good thing? Why? It would seem to greatly increase wear for no benefit.

Re: Apple File System Reference [pdf]

#27

Earlier quoted context omitted.

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).

Memory errors are still a concern, however, RAM is not used for persistent storage.

If a bit flip occurs during the path to storing data, that could get persisted. That's a moment in time, though. Maybe you'll notice the document you just wrote seems corrupted, or just has a typo.

But if you write successfully to disk, you are trusting that data to stay there long-term. If years later your drive corrupts a bit, you may have a very hard time noticing. Bad RAM manifests as computer instability and you can just replace RAM without data loss, as nobody is permanently storing data in RAM

Because the data spends so much longer on disk than in RAM, the chance of a bit flip affecting stored data.

Re: Apple File System Reference [pdf]

#28

One 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 o…

> I fear this is too little, too late to have iDefrag make a comeback

Defragging has been snake oil for more than a decade, anything that hastens it’s demise is a good thing.

Re: Apple File System Reference [pdf]

#30
post #12
post #11

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.

Care to enlighten ignorant me why we would want that?

Simple, to help prevent “bit rot”. The problem is exacerbated further in that many of us treat cloud sync services as backup, which they arguably aren’t - they can inconveniently just spread the decay.

I’d also hoped that a next generation file system from Apple would have had more to say on this topic, but it seems like features that promote their iOS device agenda took front seat over less “sexy” features like data integrity.

In the days before iOS devices dominated OS level decision making at Apple there was an assumption that Apple might adopt ZFS as their next generation file system, which is apparently much better in this regard. There’s various evidence of a cancelled MacOS ZFS project scattered throughout past MacOS releases.

> https://en.wikipedia.org/wiki/Data_degradation

> https://arstechnica.com/gadgets/2016/06/zfs-the-other-new-ap...

Post reply on HN