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.

A basic Mac system consists of the Mac itself and external storage for its backups, and is by far the most popular configuration. For many folk backing up the whole of its Data volume is wise, but that isn’t always the most economical. If the Data volume contains large items that don’t need to be backed up as often as its working folders, that can waste space. This article shows how you can make it more efficient without additional cost or hardware.

Backups and local snapshots

Most good backup utilities including Time Machine also make local snapshots of the volumes they back up. Let’s say your Data volume contains 100 GB of files that either change little or don’t need to be backed up as frequently as the rest. One proven strategy for minimising the time and storage required for backups is to add those to the exclusion list, and back them up separately, maybe only once a week. You can do that to another volume on external storage, provided you ensure there’s sufficient space for both that and your normal automatic backups.

What that doesn’t do is keep those 100 GB out of the frequent snapshots made of the Data volume. While you can exclude files and folders from backups, snapshots always include everything in that volume, without exclusions. The only way to save the space they add to snapshot size is to move them to another volume that doesn’t get snapshots made of it. But your Mac’s standard disk layout doesn’t provide any spare volume for that.

This could apply to all sorts of relatively static data that doesn’t need Time Machine’s automatic hourly backups, including Virtual Machines and some large media libraries, although you won’t then be able to share these in iCloud Drive, which would require them to be in your Data volume.

Boot disk layout

Standard layout of the internal SSD of an Apple silicon Mac running Sequoia or earlier is shown below.

Intel Macs have the same Apple APFS container with the Boot Volume Group in it, but the other two containers are replaced by a single small EFI partition.

Adding another partition or container is possible, but not recommended as it has a fixed size, and lacks the flexibility of a volume. It also risks disturbing the three existing partitions/containers. As they’re essential for the Mac to start up successfully, you don’t want to meddle with them.

In practice, the best place to add a new volume is inside the third container, the one already holding the System and Data volumes. Add that in Disk Utility once you’ve decided the next two steps.

Limit volume size

Your new volume is going to share space in its container with all the existing volumes, including both System and Data. It’s usually wise to impose a maximum limit on the size it can grow to, to avoid compromising any of those. When you add the new volume, put a sensible limit on its Quota Size.

Encryption

Although Apple’s documentation isn’t explicit, volumes added to the boot container aren’t protected by FileVault, unlike the Data volume. If you want your extra volume to be encrypted, you’ll have to format it in APFS (Encrypted). Whether that’s accelerated by the hardware in the Secure Enclave isn’t clear, and on Apple silicon Macs it’s hard to tell the difference, as you should get similar full speed performance from your extra volume to that of the Data volume.

Setting it up

Open Disk Utility, ensure its View options are set to Show All Devices, then select the Container holding the boot volumes. Click the + tool to add the new volume.

Give the volume a name, then click on the Size Options… button.

Enter your chosen Quota Size, as the maximum you want to allow the extra volume to use on the boot SSD, and click OK.

Then select whether you want it formatted in plain APFS, or encrypted, and click the Add button.

If you’ve opted for APFS (Encrypted) you’ll then be prompted to enter the encryption password. Unlike FileVault, there’s no option for a Recovery Key, or for iCloud Recovery.

When you first unlock the extra volume, you’ll be given the option to save its password to your keychain. That confirms this isn’t being performed by FileVault, as that protects its encryption keys in the Secure Enclave.

There are a couple of quirks:

• If you try unmounting the extra volume using the Finder’s contextual menu, macOS might try to unmount all volumes on the boot disk, and warn you that it can’t. Simply cancel those warnings, and the extra volume should unmount fine. If you’re worried by this, unmount the volume in Disk Utility, which isn’t as silly.
• You can use the Finder contextual menu to encrypt or decrypt the volume if you change your mind.

Summary

• To save space in local snapshots made for backups of your Data volume, move bulky items that you back up separately to an extra volume alongside the Data volume.
• Set a Quota Size on the extra volume to limit the maximum space it can take.
• Use plain APFS or APFS (Encrypted) as the extra volume can’t be protected by FileVault.
• If you encrypt the volume, safeguard its password as there’s no recovery option if you lose it.
• The extra volume performs as well as any other volume on the internal SSD, and is far faster than using external storage.