If you used a Mac before 2017, you’ll be accustomed to running First Aid in Disk Utility as part of your routine housekeeping. Now all recent versions of macOS start up from a boot volume group in APFS, you might wonder whether that practice is still needed, and how it should be done.

Reliability of APFS

Like any file system, APFS can still acquire errors, but it’s designed to be as reliable as possible, particularly when used on SSDs.

Its file system uses Fletcher 64 checksums to ensure its integrity, although it doesn’t use checksums or hashes to check the integrity of file data. When each partition (container) is mounted, APFS finds the superblock with the most recent transaction identifier, and checks that it and its contents are valid. Each volume then has a quick check run by fsck_apfs (called by Disk Utility to perform First Aid) before it’s mounted. APFS also performs a Trim on each volume during the mount process.

APFS was designed to be the file system for Apple’s devices, including iPhones, where self-maintenance and reliability are essential, and users can’t perform routine maintenance on the file system.

Boot volume group

All Macs now start up from a boot volume group, consisting of the Signed System Volume (SSV), and a conjoined Data volume. Since Big Sur, the SSV is a read-only snapshot of the system that’s sealed using a tree of hashes to verify the integrity of its entire contents. As a snapshot, it’s read-only, and its hierarchy of hashes is checked progressively as its contents are accessed. Any error found in its hashes will normally result in the volume being reinstalled and a fresh snapshot made.

Although Disk Utility will attempt to check the Data volume while it’s still ‘live’, you should avoid that whenever possible. If you want to run First Aid or fsck_apfs on the Data volume, then it’s best to do so in Recovery mode, so the volume can be properly unmounted for checking. Safe mode is no substitute, though, neither does Safe mode perform any more thorough checks than normal user mode.

Time Machine backups

All Time Machine backups are made as read-only snapshots. Local snapshots are also made at the same time to each volume being backed up, and those too are read-only. Local snapshots are routinely deleted when they’re 24 hours old, although you can delete them manually before then. As Time Machine uses the most recent local snapshot when making the next of its backups, avoid deleting that if possible.

Indications for First Aid

The most reliable indicator of a problem with a file system is an alert reporting a file system error. Severe errors may be responsible for a kernel panic, although that’s now unusual unless a disk is in the process of failing altogether.

Running First Aid is no longer recommended as a routine practice in the way that it was when using HFS+. macOS updates are performed with the Data volume unmounted for much of the time. They update the files on the System volume (which is unmounted during normal running), make a snapshot of it, and build the hash tree to verify its contents. When that’s completed, the top-level hash is hashed again to produce the SSV’s signature, which is then compared with that set for the specific version of macOS. If there is any discrepancy, macOS has to be reinstalled and the process of creating the SSV repeated.

Warnings or errors?

Both First Aid and fsck_apfs may report warnings as well as errors, which are distinguished by the term given in the report. Warnings are almost invariably benign, and not a call to take any action. For example
warning: inode (id 1234567): Resource Fork xattr is missing or empty for compressed file
doesn’t normally require any repair, as it’s a warning of a condition that may be normal.

First Aid may refer to performing “deferred repairs”; those appear to be repairs to errors that APFS has already decided it needs to make, but did’t at the time. Sometimes they and other errors require “full space verification”, normally performed when you run First Aid on that container rather than the volume. In that case, when you check and repair the container, any error should be fixed.

Sequence

Apple recommends that check and repair using First Aid or fsck_apfs is performed first on each volume within a container (partition), then on the container itself, and finally on the disk. This sequence may differ from that used on HFS+ and other file systems.

Run First Aid on the Data volume

If you have evidence suggesting that there’s an error affecting your Mac’s Data volume, start it up in Recovery mode, select Options, click Continue underneath it then select Disk Utility in the window and click Continue.

Set its View tool to Show All Devices, then select the Data or Macintosh HD – Data volume in the boot group you want to check, and click First Aid.

Once that’s complete, select the container above that Data volume, and click First Aid.

Finally select the disk above that container, and click First Aid.

When you need to run First Aid on an external disk, you should be able to follow the same sequence when running in normal mode, rather than in Recovery. If First Aid complains of an error because one or more volumes are mounted, select the volume in the list at the left and click the Unmount tool. Once that volume has unmounted, select it again, and try First Aid. If that also fails for the same reason, select the disk itself, click on Unmount and then First Aid again. If you don’t have any joy, start your Mac up in Recovery and work from there instead.

Summary

• Run First Aid in Disk Utility, or fsck_apfs, when there has been an error or incident that makes you suspect there may be an error in the file system.
• Check and repair volumes in your current boot group in Recovery.
• Set View to Show All Devices so you can see containers.
• Run First Aid on volumes first, then containers, then disks last of all.
• If any fail because they’re mounted, select the volume or disk, unmount it, and try again.
• Warnings aren’t errors, and are likely to be normal.

Disk images have been valuable tools marred by poor performance. In the wrong circumstances, an encrypted sparse image (UDSP) stored on the blazingly fast internal SSD of an Apple silicon Mac may write files no faster than 100 MB/s, typical for a cheap hard drive. One of the important new features introduced in macOS 26 Tahoe is a new disk image format that can achieve near-native speeds: ASIF, documented here.

This has been detailed as a major improvement in lightweight virtualisation, where it promises to overcome the most significant performance limitation of VMs running on Apple silicon Macs. However, ASIF disk images are available for general use, and even work in macOS Sequoia. This article shows what they can do.

Apple provides few technical details, other than stating that the intrinsic structure of ASIF disk images doesn’t depend on the host file system’s capabilities, and their size on the host depends on the size of the data stored in the disk. In other words, they’re a sparse file in APFS, and are flagged as such.

Make an ASIF disk image

Currently, there are only two ways to create one of these new disk images, either in Tahoe’s Disk Utility, or using its diskutil command tool, as in
diskutil image create blank --format ASIF --size 100G --volumeName myVolume imagePath
to create an ASIF image with a maximum capacity of 100 GB with a single APFS volume named myVolume with the path and name imagePath. You can also use a from option to convert an existing disk image to ASIF format.

These are only good for Tahoe, as there’s no support for their creation in Sequoia 15.5 or earlier. Neither is there any access documented for the hdiutil command tool, more normally used to work with disk images, although its general commands should work fine with ASIFs.

Resulting disk images have a UTI type of com.apple.disk-image-sparse, in contrast to RAW (UDIF read-write) images of type com.apple.disk-image-udif, which can be used to distinguish them.

Economy

When first created, a 100 GB ASIF disk image took less than 1 GB disk space, but after extensive use and adding a second volume, its size on disk when empty again ranged between 1.9-3.2 GB. No attempt was made to compact the disk image using hdiutil, and its man page doesn’t make clear whether that’s supported or effective with this type of disk image.

Performance

Read and write performance were measured using Stibium over a total of more than 50 GB in 160 files ranging in size from 2 MB to 2 GB in randomised order. When performed using a 100 GB ASIF image on the 2 TB internal SSD of a MacBook Pro M3 Pro running macOS 26 beta, transfer speeds for unencrypted APFS were 5.8 and 6.6 GB/s read and write. Those fell to 4.8 and 4.6 GB/s when using an APFS encrypted volume in the disk image.

Although there’s currently no way to create an ASIF disk image on a Mac running Sequoia, I compressed the disk image using Apple Archive (aar) to preserve its format and copied it to a Mac mini M4 Pro running macOS 15.5, and repeated the performance tests on its 2 TB internal SSD. Unencrypted APFS there attained 5.5 and 8.3 GB/s read and write.

Use

Apple recommends switching from the previous RAW (UDIF read-write) disk images used for the backing store of VMs to ASIF for their greater efficiency in file transfer between hosts or disks. As the disk image in a VM is created when the VM is first made and installed, this awaits implementation in virtualisers. Because the only access provided at present is the diskutil command tool, apps will need to consider creating an ASIF image where that’s available, in macOS 26 Tahoe.

Although ASIF appears to be supported by Sequoia 15.5, the danger with a VM based on an ASIF image is that it may not be compatible with older versions of macOS. Apple hasn’t yet revealed which of those can mount and use this new format.

Previous tests on different types of disk image demonstrated that, prior to ASIF, the best performance was achieved by sparse bundles. The following table compares those with ASIF.

Allowing for the differences in chips, ASIF is clearly faster than both UDRW read-write and UDSP sparse images, whether plain or encrypted. It’s also likely to be significantly faster than sparse bundles, and has the advantage that it uses a single file for its backing store.

Conclusions

• Where possible, in macOS 26 Tahoe in particular, VMs should use ASIF disk images rather than RAW/UDRW.
• Unless a sparse bundle is required (for example when it’s hosted on a different file system such as that in a NAS), ASIF should be first choice for general purpose disk images in Tahoe.
• It would be preferable for virtualisers to be able to call a proper API rather than a command tool.
• Keep an eye on C-Command’s DropDMG. I’m sure it will support ASIF disk images soon.