oh snap —

Testing out snapshots in Apple’s next-generation APFS file system

We brave beta software and do some cautious testing—and it looks like it works.

Build a binary

With a little more testing I wrote my own version of Apple's unreleased snapUtil command from the WWDC demo:

Usage:
   snapUtil -l <vol>
   snapUtil -c <snap> <vol>
   snapUtil -n <snap> <newname> <vol>
   snapUtil -d <snap> <vol>
   snapUtil -r <snap> <vol>
   snapUtil -s <snap> <vol> <mntpnt>

Listing snapshots with the -l option shows us that indeed that first snapshot worked!

$ sudo ./snapUtil -l /Volumes/APFS/
first_snap

And we can take some more snapshots!

$ sudo ./snapUtil -c second /Volumes/APFS/
$ sudo ./snapUtil -c third /Volumes/APFS/
$ sudo ./snapUtil -l /Volumes/APFS/
first_snap
second
third

We can complete the demo from WWDC by mounting a snapshot:

$ mkdir /tmp/mnt
$ sudo ./snapUtil -s first_snap /Volumes/APFS/ /tmp/mnt
mount_apfs: snapshot implicitly mounted readonly
$ mount | grep first_snap
first_snap@/Volumes/APFS on /tmp/mnt (apfs, local, read-only, journaled)

Apple's hidden gem

We figured out the proper use of the fs_snapshot system call and reconstructed the WWDC snapUtil. But all this time an equivalent utility has been lurking on macOS Sierra. If you look in /System/Library/Filesystems/apfs.fs/Contents/Resources/, Apple has included a number of APFS-related utilities, including apfs_snapshot (and, tantalizingly, a tool called hfs_convert). The key value-add of apfs_snapshot over Apple's earlier snapUtil appears to be a scary warning message:

Sneaky, Apple!
Enlarge / Sneaky, Apple!

I don't think I’ve ever searched for an Apple technology that found a paltry seven hits—apfs_snapshot may be Apple’s best kept non-secret:

Okay, Google, why don't you know more about this?
Enlarge / Okay, Google, why don't you know more about this?

Snapshot reversion

Snapshots let you preserve state to later peruse; we can also revert an APFS volume to a previous state to restore its contents. The current APFS semantics around rollback are a little odd. The revert operation succeeds, but it doesn't take effect until the APFS volume is next mounted:

Snap, revert, unmount, success.
Enlarge / Snap, revert, unmount, success.

After the volume is mounted again, not only are the contents reverted (to an empty directory in this case), but any snapshots taken after the snapshot used for the revert operation are deleted as well. One might expect APFS snapshot revert to immediately take effect and restore the contents of the volume to the previous state. Some technical issues likely make that challenging, such as what to do about programs that have files within in that volume open. So seeing if and how Apple decides to expose this functionality will be interesting. It would be quite surprising to do a rollback, forget, keep writing to the device, and then discover that all your work had been undone on the next reboot.

A work in progress

Another reason Apple may not have wanted people messing around with snapshots is that the feature appears to be incomplete. Winding yourself into a state where only a reboot can clear a mounted snapshot is easy, and using snapshots seems to break some of the diskutil APFS output:

$ diskutil APFS -IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData list

=====================================================================
ENUMERATION OF ALL CURRENT APFS OBJECTS

APFS CONTAINER: REFERENCE:     disk2s1     Total Container Size = 1.1 GB (1073700864 Bytes)
|                                          Container Free Space = 1.1 GB (1070309376 Bytes)
|
|--  APFS VOLUME:             disk2s1s1   Volume Name = APFS (/Volumes/APFS)
|                                          Space-Sharing Current Volume Size = (UnavailableBecauseNotMounted)
|
=====================================================================

---------------------------------------------------------------------
APFS OBJECTS BY ITERATING ALL CURRENT DISKS WHILE CHECKING APFS ROLES

APFS PHYSICAL STORE = disk2s1   -> APFS CONTAINER REFERENCE = disk2s1
APFS VOLUME =         disk2s1s1 -> APFS CONTAINER REFERENCE = disk2s1
---------------------------------------------------------------------

Watch this space

Snapshot are going to be a powerful feature of APFS. Beyond creating snapshots, mounting them, and reverting volumes to earlier snapshots, they have the potential to form the basis for an efficient and robust backup system. Apple (or a third party!) could arrange for snapshots to be taken periodically and then backup files changed between snapshots when a backup device is available. That could be a disk in your house or a cloud service from Apple, Dropbox, Google, or someone else. With its unknown utilities and unpublished APIs, Apple has already enabled a whole new collection of backup tools.

The next APFS capability I'm hoping for is the ability to package and send the changes between snapshots or a related ability to identify files that were changed between when two snapshots were taken. Either would be a huge boon for backup and data integrity.

But who knows—maybe Apple’s already shipped it and it’s just waiting to be discovered.

Adam H. Leventhal is a developer of DTrace and ZFS; he is currently the CEO and co-founder of Transposit.

Channel Ars Technica