▲ 139 points
back
25 comments
It's important to note that the actual slice names in this article may vary, depending on whether you have a HDD or SSD, and whether you've upgraded macOS through several versions.
For example, if you upgraded to Catalina from a pre-APFS version of macOS on an SSD, "Macintosh HD" will likely be disk1s5 in the APFS container scheme. In this case, "Macintosh HD - Data" will be disk1s1, "Preboot" will be disk1s2, "Recovery" will be disk1s3 and "VM" will be disk1s4.
Gotta hand it to Apple. As complicated as it may seem from the diagrams, they’ve done a good job at making the file system simple for everyday users.
Seems like firmlinks are like a union file system, such as overlayfs. A lower dir placed on a read-only file system, and merged with an upper dir on a read-write file system. It appears as if they were one directory.
Overlayfs will do an efficient (reflink) copy-up on a supporting filesystem, such as XFS or Btrfs. Both layers need to be on the same file system to do the reflink copy. The lower dir can be made read-only by VFS read-only bind mount option; or on Btrfs either a read-only snapshot or setting read-only property on a subvolume. But it sounds like APFS firmlinks institute some limitations, like you probably can't modify files on the read-only layer via copy-up to the read-write upper, rather just add new/unrelated items.
The “sealed system volume” thing is interesting, I assume the point of it being a snapshot is to be able to change out the OS atomically while it is running.
That seems to be exactly what they are planning...
"Faster updates: Once macOS Big Sur is installed, software updates begin in the background and finish faster than before — so it’s easier than ever to keep your Mac up to date and secure."
Something that’s been done on Android for a while and was possible on Linux if you knew what you were doing.
And with Windows you only need to restart like twice for an update.
Fedora Silverblue does that now.
Cool!
Not while running, but on reboot. It also makes it possible to produce the new OS image by just applying deltas to the currently-running OS, since the snapshot of the "current" OS is immutable - meaning smaller downloads for your OS updates.
Did anyone else ran into read-only or disk full issues after updating iMac to Catalina? Is this related to new volume layout?
For what it’s worth, I may have lucked out but I was able to recover without a reinstall by:
1. Boot to recovery mode
2. Open Terminal
3. Delete files I was trying to delete with rm
4. Reboot
The part where I may have lucked out was where the unrecovered space from deletions prior to step 1 were significantly more than the space I reclaimed this way. It’s entirely possible I could have just rebooted but I didn’t want to chance it, not knowing the failure modes I’d encounter.
I had the issue, was related to how APFS keeps deleted data around until it's forced to flush it. It didn't flush it... Had to do a full reinstall to get rid of the issue.
This seems to be connected to FileVault. If the volume is FileVault-encrypted, it can get quite “greedy” about holding onto deleted files.
Even though it is supposed to let go of the space upon demand, it is my experience that it does not.
When a big update came out (don’t remember exactly which one, but it was a couple or so months ago), my disk space was down to about 13GB free, even though I had deleted over 150GB of files. The update refused to run, citing lack of space.
I had to wipe the disk, and use Migration Assistant to restore the disk.
That was the second time this has happened.
I think that this particular aspect of APFS still needs a lot of work.
I’ve had free space problems during the actual upgrade. Turned out it was because Time Machine created a bunch of snapshots and never deleted them.
You can check by running: tmutil listlocalsnapshotdates
You can also manually delete the snapshots by using tmutil.
I’m pretty sure TimeMachine related issues (either bug or misfeature or something else TM related) is the cause for most folks having phantom disk space usage issues (not due to a bug specifically in APFS or FileVault), but obviously can’t prove that.
Anecdotally in my experience this has been local time machine snapshots occupying space.
Unrelated to APFS specifically - I also use Dropbox and it takes filling the disk for it to finally purge content I’ve marked as online only with smart sync.
From what I’ve seen, if you are using Time Machine, then the TM backup has to run before the space from deleted files can be freed.
You couldn't just change the permission on the disk to solve the issue?
Yes! Deleting files won’t work as it’ll fail with “no space available”. Snapshots could not be deleted. Resizing APFS volumes would also fail. Finally I caved and reinstalled from a backup. Now I keep a spare APFS volume of 10 GB that I can hopefully remove to resolve this problem when it happens next time.
APFS has serious problems and shouldn’t be forced upon people who value their data.
I learned about APFS's unreliability the hard way when a friend's Mac started kernel panicking after an upgrade to Catalina... I ended up having to copy file-wise with (a modern version of) rsync from another install to an HFS volume, then manually recreate the entire APFS volume structure, restore everything, and run some obscure commands to make it all bootable again. I was lucky all the files were still readable without the OS panicking; presumably it was a write operation that failed. fsck was completely useless and could not fix the problem.
The rsync mostly preserved all the obscure Mac-specific attributes (resource fork, etc), but at least one thing was lost: the "bundle bit" on directories. Thankfully most bundles are marked another way these days, so only a few things broke (in particular some VST plug-ins, but not others). Good luck finding documentation on that bit! As far as I can tell very few people know of its existence.
The kernel panic was an assert(), which is just inexcusable. FS corruption ("impossible" things in the FS driver) should absolutely never cause the OS to panic. If something fails, return an error to userspace, and possibly remount the filesystem read-only.
If things are unexpectedly broken you don’t want to continue making the system worse by executing transactions against the drive
I didn't know Resource Forks was a think on modern macOS anymore.
They are, although nothing modern uses them and they're mostly just sugar for an extended attribute (the resource fork contents are stored as the value of the attribute "com.apple.ResourceFork"). Mostly, but not entirely: search the APFS documentation[1] for "resource fork" and you'll find inode flags specific to them.
[1] https://developer.apple.com/support/downloads/Apple-File-Sys...
Sounds similar to the infamous ENOSPC bug that has plagued btrfs.