https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new-disk-image-format/

macOS Tahoe brings a new disk image format

The Eclectic Light Company

Macs, painting, and more

hoakley June 12, 2025 Macs, Technology

macOS Tahoe brings a new disk image format

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.

22Comments

Add yours

1John Woods on June 12, 2025 at 6:41 am ReplyInteresting find!didn’t VMs on macOS already use a sparse disk image? Is this just really bringing speed improvements?Liked by 2 people
- 2hoakley on June 12, 2025 at 8:29 am ReplyThank you.
  Existing VMs use what Apple now terms RAW, in other words UDIF read-write or UDRW. As you can see in the comparisons, ASIF is considerably faster than that, particularly when writing. As APFS converts UDRW to a sparse file, there’s little gain in disk space, though, which can’t really be any more efficient.
  Howard.Like
3joethewalrus on June 12, 2025 at 7:36 am ReplyThis is really awesome. I’m excited for the possibilities.
Now that they’re fixing disk image speed, my wish list for next year is a successor to AFP, with or without the acknowledgement that under many (or most?) conditions that involve two Macs, SMB is ghastly slow.Liked by 1 person
- 4Alan B on June 12, 2025 at 8:10 am ReplySMB – do you mean SMB v3 which is much faster than v1?Liked by 2 people
  - 5joethewalrus on June 12, 2025 at 8:25 am ReplyYes, of course version 3.Liked by 2 people
- 6hoakleyon June 12, 2025 at 8:36 am ReplyI’ve benchmarked SMBv3 between two Macs, and it really isn’t at all slow. Most of its slowness is attributable to using only 1 gig Ethernet: try connecting at 10 gb/s and it’s really quick, unless you’re connecting to a NAS running flawed software.
  Howard.Liked by 3 people
  - 7joethewalrus on June 12, 2025 at 9:17 am ReplyVirtually all of my file sharing occurs Mac to Mac over 1 gig Ethernet (or, for smaller projects, fast 802.11ax Wi-Fi). Usually the Macs are both connected to the same switch on a modest sized home network. If I drag and drop a large folder of files over macOS Screenshare, I can see the transfer rate running around 110 MB/s (60–80 MB/s for Wi-Fi), pushing at the theoretical maximum, as long as I don’t start doing anything else that puts traffic over the same route.If I use traditional file sharing instead (SMB), there is a noticeable hit in performance, around 25-30%.I don’t have the luxury of 10 Gig Ethernet yet, but if I connect a Thunderbolt IPv4/IPv6 Bridge between two Macs, as I recall I get around 2 Gig (~200 MB/s) speed for SMB and approximately 5 Gig for screen sharing file transfer.Diving further into my tangential rabbit-hole: Using Migration Assistant over Thunderbolt is wicked fast, and transferring hundreds of gigabytes of music over Media Sharing / Home Sharing through a Thunderbolt bridge knocks my socks off; it’s the one place where Thunderbolt actually wows me with its speed.A while back I sat at my 2020 M1 Mac Mini and mounted my dual 1 Ghz G4 tower (gigabit ethernet) as an AFP share and moved a few gigabytes of data over. This involved not just the very old hardware and Mac OS Tiger, but running the connection through the router to a single 1 Gig line to a fairly busy switch in the room where the Mac Mini is, and even that seemed faster than M1 Mac to M1 Mac over SMBv3.I’m probably driving you crazy, as none of this has been logged and charted as in the excellent articles on Eclectic Light Co. Maybe I’ll make a vanity project for myself of sitting down and doing this right, so I can show my work and prove that SMB for my use cases sucks. Or maybe I’ll prove myself wrong; I’m open to that in the name of good science.Returning to the original topic, I have no gripes at all about performance of my virtual machines, but I’m certainly not going to complain when ASIF makes them faster. Am I correct in understanding that you can only create a new ASIF disk image as a copy from another, that is you cannot directly convert an existing image? I’m not someone who obsesses about wear on his SSDs, but it would be pretty sweet if things were structured such that the data blocks in an older disk image could be assigned (cloned?) as is to ASIF format without having to be rewritten.Liked by 2 people
    - 8hoakley on June 12, 2025 at 10:09 am Tahoe does support the conversion of some disk image formats to ASIF, but I don’t know whether it would support going from RAW/UDRW to ASIF. I have absolutely no idea whether that conversion, if possible, would retain any of the existing data blocks, and I don’t know of any way to find that out, I’m afraid.
      Howard.Liked by 1 person
    - 9Raoul on June 12, 2025 at 11:22 pm What’s the difference in I/O and CPU usage with packet signing on v off?smbutil statshares -amultichannel might help if you’ve got spare ports as you don’t even need to use unique subnets. Just make sure the NIC speeds are the same.Liked by 1 person
    - 10joethewalrus on June 13, 2025 at 5:39 am I’ve had my fun with multi-channel in the past. It’s not worth the trouble when Thunderbolt is available to run a bridge much faster with zero config. Howard’s right that 10 gig is the way to go…eventually.Liked by 1 person
    - 11joethewalrus on June 13, 2025 at 7:40 am When I use M1 Macs running Sequoia and gigabit Ethernet, I can’t reproduce the issue. I’m getting darn close to 125 MB/s whether I use SMB or Screen Sharing. The same is true when I test a 2018 Mac Mini running Sequoia. Using Thunderbolt nearly doubles that to 230 MB/s.One caveat that I noticed with Apple Silicon is that during file transfer, the SMB host process loads the 2 E cores on my MB Pro, so there may be times when it has to compete with other processes deemed low priority. However, I did not observe it having an impact this evening. And it seems Apple is done with the 2e configurations for now.I began to think that maybe I imagined the whole thing, but when I plugged in an old Mac Mini with Mojave on it, verified I had connected to it as host over SMBv3.0.2, and attempted file transfer, I got just over 70 MB/s. Not exactly terrible, but bad enough that I could maybe regain some of my dignity here. Sure enough, sending the same test files over a Screen Share resulted in 103 MB/s.So at some point in the past SMB disappointed me, perhaps due to underpowered hardware, or a software issue. I never gave it another chance until y’all convinced me. Thank you!Liked by 1 person
    - 12hoakley on June 13, 2025 at 7:43 am Well done.
      Never worry about high use of E cores – remember that Activity Monitor doesn’t allow for their frequency. They could well be fully used but still pottering along at little more than idle frequency. macOS will manage that for you, and ensure those background tasks get done when needed.
      Howard.Liked by 1 person
13jzonedotcom on June 12, 2025 at 10:31 am ReplyApologies in advance if I missed this: ASIF = Apple Sparse Image FormatThanks very much.Liked by 1 person
- 14hoakley on June 12, 2025 at 12:39 pm ReplyThank you, but I avoided that as ASIF is more distinctive and less confusing. We already have sparse files in APFS, and both sparse bundles and sparse images in disk images. Having another sparse image to confuddle isn’t going to help!
  Howard.Liked by 1 person
15Dominic Dunlopon June 12, 2025 at 10:39 am ReplySooner or later, I’d expect ASIF to become the format used for Time Machine disk images on shared volumes (where the current sparse disk images can be perplexingly slow — yes, even with SMB3 over 10GbE).Liked by 3 people
- 16hoakley on June 12, 2025 at 12:43 pm ReplyMaybe, but I don’t know of anyone who uses old sparse images for network shares or TM backups. Sparse bundles are the standard, and for the moment it’s far from clear whether ASIFs will work well when hosted on a NAS local file system. But if the server can handle them locally, why not?
  Howard.Liked by 1 person
17.:. brainsik on June 12, 2025 at 7:06 pm ReplyThank you for the article. Is it reasonable to assume the efficiencies touted for transferring ASIF files between hosts/disks would extend to Time Machine backups of those files?Liked by 1 person
- 18hoakley on June 12, 2025 at 7:50 pm ReplyYes.Current RAW/UDRW disk images work efficiently because APFS can handle them as sparse files. Copied or backed up to another disk or over a network, those sparse files can explode to their full size. That not only means they would take up more space, but also that their transfer would take longer. Thankfully Time Machine handles APFS sparse files properly, and preserves their format and efficiency whenever it can, but that’s not guaranteed, and if you copy a sparse RAW/UDRW disk image to a different file system it’s guaranteed to explode to full size in the process.ASIF works as an APFS sparse file (it is flagged as such), but apparently is intrinsically sparse rather than depending on APFS for its efficient storage. So wherever it goes, it should remain the same size, whether that’s being copied or backed up.Howard.Liked by 1 person
19Sebastian on June 13, 2025 at 11:14 am Reply“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.”… which has the disadvantage that flipping a single bit in the disk image will cause backups of that disk image to require a full copy, as opposed to just one band. So it very much depends on your use case which will give you less waiting time overall.Liked by 1 person
- 20hoakleyon June 13, 2025 at 11:20 am ReplyI’m sorry, I don’t think that’s correct. Since TM has been backing up to APFS, it has performed block copies. So it only backs up the changed blocks, not the whole file. Otherwise that wouldn’t be the case with sparse bundles either, would it?
  Howard.Like
  - 21Sebastian on June 13, 2025 at 12:03 pm ReplyI didn’t know that Time Machine performed block copies between APFS volumes. Indeed it will not be an issue then. But other backup tools don’t, and generally this is only a possibility if the target file system is also APFS (which it might not be in the case of network or remote backups, and not even locally when HFS+ is still used on an HDD).Sparse bundles are not dependent on APFS or Time Machine. To the backup software, they’re pretty much just folders with files in them, so when a band is changed, any such software will recognize that and copy only what’s changed. That’s not as granular as a block copy (I believe 8 MB is the default band size for sparse bundle disk images?), but it’s sufficiently granular to prevent much unnecessary copying, especially with larger disk images when only little data is changed.So, still depends on the use case, I think.Like
    - 22hoakley on June 13, 2025 at 3:24 pm You shouldn’t be using TM to back up to anything other than APFS now. The whole purpose of using a disk image (sparse bundle or whatever) on your NAS or other network storage is so that its virtual file system is APFS, to enable TM to back up APFS volumes to APFS storage. So the target file system should always be APFS now.So yes, there are use cases where sparse bundles may be preferable. But for the great majority of those currently using sparse bundles on network shares to take their Time Machine backups, a single-file solution would actually be better, rather than using a directory containing tens or hundreds of thousands of band files. You may not be aware, but sparse bundle failure isn’t uncommon with NAS backups, and it’s invariably fatal.Howard.Like

Quick Links

Search

Monthly archives

Statistics

19,372,796 hits

Blog at WordPress.com.

Begin typing your search above and press return to search. Press Esc to cancel.

R.M.P Marotta Long Island

macOS Tahoe brings a new disk image format – The Eclectic Light Company

The Eclectic Light Company

macOS Tahoe brings a new disk image format

Make an ASIF disk image

Economy

Performance

Use

Conclusions

Share this:

Related

22Comments

Leave a comment

Quick Links

Search

Monthly archives

Tags

Statistics

Leave a comment Cancel reply