Disk Utility in Monterey

Oh so it's not my Hackintosh (that I use alongside with my iMac and Macbook Pro) that's the cause of the long mounts in Disk Utility, it's actually a bug in Big Sur!

I'm glad Disk Utility has been improving.

I'm not sure, given that APFS Snapshot is a section underneath the volume anyway, why it isn't simply always there but with a disclosure triangle. Creating a new snapshot doesn't seem to be there? However, mounting is! Neat.

> There’s also a Cumulative Size column, shown as Size no matter how wide I make the table. This takes a really long time to calculate. At first, I thought this would be the difference from the current state of the volume, i.e. the Private Size plus the components of that snapshot that are also used by other snapshots. However, the fact that Cumulative Size is larger for more recent snapshots, which differ less from the current state of the volume, seems to undermine that theory.

I *think* you may have that backwards — take the (chronologically) first snapshot, which is zero bytes. That's the current "base" of the volume. Each consecutive snapshot then adds changes on top of that. Finally, the "current state" of the volume doesn't exist as a snapshot (by definition, it would be outdated as soon as any change is made).

I.e., snapshots aren't stored based on the current state (which makes sense; otherwise, their differential storage mechanism would have to be rewritten each time) but rather based on a past state. Presumably, deleting the oldest snapshot (or anything but the most recent snapshot) requires re-writing the storage for each newer snapshot.

> Six years after the rewrite in El Capitan, we’ve still not regained the ability to open multiple windows

More and more, software engineers seem to have unlearnt that multiple windows are a thing. (Teams and other Electron apps / web apps are particularly bad at this, but it's been creeping into Apple as well. Microsoft, too; you used to be able to do more things in Control Panel without losing your state; the new Settings app just takes you to completely different sections. There's a back button, but it's not great.)

@Sören Yes, I don’t understand why there isn’t a button in the window to show the snapshots. They’re hidden behind a menu command.

What is your interpretation of Cumulative Size, then? The Cumulative Size of the oldest snapshot is not shown as zero bytes in Disk Utility.

As far as I know, snapshots aren’t stored based on any state. They’re not backwards diffs like CVS/SVN. They’re just collections of blocks. When a block is no longer “retained” by any snapshot or the current state then it can be reclaimed. As far as I know, deleting one snapshot does not require rewriting others. But I’m having trouble finding the documentation for this at the moment.

What is your interpretation of Cumulative Size, then? The Cumulative Size of the oldest snapshot is not shown as zero bytes in Disk Utility.

Hum, this time, I’m not seeing a snapshot with zero size. Earlier today, I did.

Still, I think that supports my supposition — there’s a “base” that’s either before any of the snapshots or the very first snapshot. Then, each consecutive snapshot has a higher cumulative size than the previous.

That said, on one volume of mine, the “High tidemark” is the last snapshot, and on another, it’s the first. I would expect it to always be the last?

As far as I know, snapshots aren’t stored based on any state. They’re not backwards diffs like CVS/SVN.

I think they are (“forward diffs”, if you will). And if they weren’t, why would there be a cumulative size?

(This is, of course, significantly different from version control in that, at
some point, all old snapshots are merged into a new base.

I also presume that, at some point, the more snapshots you have, the slower
the file system is at reads, as it has to “defragment” data across multiple
snapshots.)

As far as I know, deleting one snapshot does not require rewriting others. But I’m having trouble finding the documentation for this at the moment.

So, Apple File System Reference says:

Snapshots let you get a stable, read-only copy of the filesystem at a given point in time — for example, while updating a backup of the entire drive. Snapshots are designed to be fast and inexpensive to create; however, deleting a snapshot involves more work.

Which seems to support my notion: deleting a snapshot involves more work because the FS needs to actually merge its changes to one of the neighboring snapshots.

About Apple File System and its predecessor Apple File System Guide merely say that snapshots are a “state-of-the-art file system feature” or an “improved file system fundamental” while not going into detail of what they are and how they work.

If only Apple had the resources to actually write some documentation about this…

@Sören I’m not sure what the tidemarks are. My tidemarks are essentially all the same and equal to the capacity of the drive. But the oldest snapshot is shown as the high tidemark.

Well, I don’t know what Cumulative Size means. You think it’s the diff vs. the oldest snapshot?

Copy-on-write slows down reads due to fragmentation, but I don’t think whether you’re keeping the snapshots affects that because it always uses fresh blocks for writes, anyway.

I think the “involves more work” only refers to figuring out which blocks can now be freed. It doesn’t actually touch/merge the data when you delete a snapshot, AFAIK.