Tuesday, November 9, 2021

Disk Utility in Monterey

Howard Oakley (user guide):

I’ve been on the look out for nominations for the title of the most improved utility of the year. I’m delighted to announce not just a nomination, but an outright winner: Disk Utility 21.0, bundled with Monterey. After four years in which it had offered frustratingly limited support for the new features of APFS, Disk Utility is now complete: this version has excellent support for snapshots, no matter which app created them.

[…]

The most recent snapshot has a Partition symbol shown against its Tidemark, a value which isn’t explained in the Help page, unfortunately.

Select a snapshot from the list and you can mount it, show it in the Finder, rename it, and delete it, using the More button and the – tool at the bottom left.

The Private Size column, which mostly but not completely matches what Carbon Copy Cloner shows, I think represents the amount of space that’s only used by that snapshot. This is the amount you would free by deleting it.

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.

Six years after the rewrite in El Capitan, we’ve still not regained the ability to open multiple windows (and thereby perform simultaneous operations or compare one disk to another).

I also continue to see the problem, introduced in Big Sur, where external drives can take up to an hour to mount, during which time Disk Utility may constantly beachball, and other apps that use the Cocoa document system or file coordination will beachball as soon as they try to read or write a file. Thus, it’s no longer safe for me to initiate a backup while working.

Previously:

Update (2021-11-12): Thomas Clement:

Snapshots API is still gated behind an entitlement. And Apple still does not allow users to create new snapshots and pin them in order to control their lifetime.

Update (2021-11-15): Howard Oakley (tweet):

Tidemark is the highest block referenced by a snapshot. As this can’t be moved, this effectively limits any resizing which might be applied to the container without destroying that snapshot. Values which haven’t changed since the previous snapshot are shown in grey. The Partition symbol is used to mark the high tidemark for that volume, which sets the limit for non-destructive repartitioning of its container.

[…]

Size is the cumulative size occupied by that snapshot and all previous snapshots. This reaches a maximum for the latest snapshot. Values which haven’t changed since the previous snapshot are shown in grey.

5 Comments RSS · Twitter

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.

Leave a Comment