Update

Ars has some updated information, including details about the snapshotUtil apfs_snapshot utility.

Original

The Apple File System is still a slightly mysterious beast. Apple has reason to be cautious: A new file system is always a huge undertaking and the risks couldn't be higher: a serious bug can cause complete data loss.

AFPS is intended to replace CoreStorage, FileVault, and the iOS variants of HFS+. That's a lot of functionality!

Mysteries

At present we don't know anything about the design or the data structures it uses (though a little bird tells me it uses copy-on-write B-trees, similar to BTRFS). We do have some ideas about its capabilities at present and can guess about where it might go in the future.

I can only speculate here but I assume Apple is being cautious because they've already had an aborted attempt at a new file system in the form of ZFS for Mac and they don't want to make any commitments they can't back up.

Warnings

I'm going to talk about features as if they are implemented using copy-on-write B-trees but remember that this is just speculation! I could be completely wrong so don't cite this post as an authority on how it really works!

Secondly, this is a beta file system. Do not store anything on an APFS volume that you can't afford to lose permanently. Time machine doesn't currently work with APFS (in fact Time machine should be redesigned to take advantage of APFS) so making backups becomes your responsibility!

Volume format

In APFS, the basic level of storage is the container. Within a container, different volumes share the available free space. This puts an end to resizing or moving partitions.

My guess is this is implemented by simply having multiple B-tree roots, one for each volume. The implementation would be trivial and the data blocks for each volume would freely intermingle as needed, just like they would on a single traditional volume.

The only caveat for apps is you can't just add up the free space on each volume to get the total system free space because multiple APFS volumes in the same container share it.

Clones

Another major feature of APFS is the ability to clone any file or directory tree but at almost zero cost. The data blocks are shared using a copy-on-write scheme, only the metadata is actually copied. This makes clones really fast too. This feature seems like it just falls out naturally from the copy-on-write B-tree implementation.

Snapshots

A closely related feature is snapshots. These are point-in-time read-only versions of a volume. Whenever you modify a copy-on-write B-tree you mutate each node from the root down to the target node. To support snapshots, just keep the old root node around somewhere and 💥: you have snapshots.

You can revert a volume to an earlier snapshot but unfortunately that blows away any intermediate snapshots. That doesn't seem like a requirement, just an artifact of the current implementation. I made the suggestion that APFS should support rolling back without losing intermediate snapshots, as well as mounting a snapshot as read-write.

Currently APFS does not support shipping diffs between snapshots (ala ZFS) to keep a remote clone in sync but I think they are aware of it. Nevertheless it is worth filing a radar to request it.

Resilience

Related to snapshots and clones is resilience. The file system keeps the old data (and old metadata) around for the duration of a transaction. This means in the event of a crash or power loss either all the changes are visible or none are visible but things are never in an inconsistent state.

Again, this feature falls out naturally from the copy-on-write nature of the file system. Clones, snapshots, and resilience are merely decisions about when to keep the old versions of mutated tree nodes and which nodes to keep. Transactions can be thought of as transient snapshots. Clones are partial snapshots. Snapshots are clones of the volume root.

Note that there aren't any public APIs to access this functionality yet but Apple has promised these things are coming in future releases.

Encryption

APFS supports iOS style encryption from the beginning. A volume can have no encryption, whole-disk encryption with a single key, or per-file encryption (similar to how the iOS variant of HFS+ works today).

The Glaring Omission

Although APFS does checksum metadata blocks it does not do anything to provide resilience for data blocks. That is a huge omission in a modern filesystem, a point I tried to politely but forcefully make in the File System Lab directly to a responsible engineer. I got the feeling that the APFS team is divided on the necessity of this feature and some people on the team would appreciate some ammo to help win the argument internally. I would encourage anyone who agrees to file radars ASAP requesting this feature.

One concern I heard in the lab was that it would impose overhead on a device like the Apple Watch when it wasn't necessary. I pointed out that it would be easy enough to make this work like encryption: support different settings on the directory or file level: No Protection, Checksums (detect but not correct), and Parity (detect and correct), each with increasing performance and space costs to match the additional protection. By default things like your Documents directory or Photo Library should have Parity, while things like caches or system files could have Checksum or None since those can be re-generated or re-downloaded with no permanent loss of data.

Conversion & Compatibility

APFS takes the same conversion approach as other modern file systems: It reserves free space in the HFS+ volume and writes its metadata structures there, but without actually moving any data blocks. This should make the conversion relatively fast and if anything goes wrong during the process your HFS+ volume is unaffected. We don't have the full details yet but I assume at some point during the conversion it will need to freeze all access to the volume, convert the last few metadata changes, then immediately remount the volume (or reboot if it is the boot volume).

The conversion support is not present in current betas but should make an appearance soon-ish. You also can't make APFS your boot volume, but that is also something that will appear in a future update.

Apple seemed to be saying they will back-port APFS to El Capitan so a wide range of Macs should be able to read the volumes. However plugging in to a Snow Leopard system will present you with a dialog that will cause much sadness if you make the wrong choice.

Open Specification and Open Source

I did get confirmation that Apple intends to provide an open specification in 2017 when the design is finalized. They also emphasized that the data structures are designed to be extended in backward and forward compatible ways so things like parity checks should be easily implemented even if they don't make the first release.

It seems like Apple is planning on releasing the source but until we see documentation on that I'm not ready to claim this as confirmed. It would make sense because the Darwin XNU kernel will eventually need APFS support to boot from APFS volumes which implies it will be open-sourced.

Working with APFS

You'll need macOS Sierra to use these commands (presumably a future update to El Capitan will also include support for APFS).

To create a volume as a disk image:

hdiutil create -fs APFS -size 10GB apfs.sparseimage

To create a snapshot:

sudo snapshotUtil -c <name> /path/to/mounted/apfs

Update: The snapshot commands are broken or missing in the first beta!

To list snapshots:

sudo snapshotUtil -l /path/to/mounted/apfs

To mount a read-only snapshot:

mount_apfs -s <snapshotname> /path/to/mounted/apfs /path/to/mount/point

To create a new container on a physical device:

diskutil apfs createContainer /dev/<devicename>

To add a new volume to the container:

diskutil apfs addVolume <devicename> APFS <volumename>

To check the file system:

fsck_apfs

(In theory you should never need this but we are talking about beta software here so YMMV).

The Future is Bright

APFS is going to be a developer preview technology for the next year at least. This makes perfect sense. It gives all of us a chance to try it on external volumes or with experimental disk images, test apps against it, and provide feedback to Apple.

It remains to be seen whether Apple will prompt users to upgrade their Macs or iOS devices when iOS 11 / macOS 13 appear in 2017. They might choose the lower risk route and only ship it on new devices while relying on father time and mother entropy to slowly eliminate HFS+.

More importantly filing radars is effectively a vote for a feature and the APFS team is listening. You will never have a greater impact on APFS than going to bugreporter.apple.com and filing radars requesting missing features like parity on data blocks or copying snapshots.

Update: Here is my radar on Data Block Integrity if you want to duplicate it. Even if you copy-paste it your separate report counts as another "vote".

APFS is going to be Apple's official next-generation file system sometime in 2017 and that's excellent news.