https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new-disk-image-format/ Skip to content [eclecticlight] The Eclectic Light Company Macs, painting, and more Main navigation Menu * Downloads * Freeware * M-series Macs * Mac Problems * Mac articles * Macs * Art 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. [diskimages25] 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. Share this: * Click to share on X (Opens in new window) X * Click to share on Facebook (Opens in new window) Facebook * Click to share on Reddit (Opens in new window) Reddit * Click to share on Pinterest (Opens in new window) Pinterest * Click to share on Threads (Opens in new window) Threads * Click to share on Mastodon (Opens in new window) Mastodon * Click to share on Bluesky (Opens in new window) Bluesky * Click to email a link to a friend (Opens in new window) Email * Click to print (Opens in new window) Print * Like Loading... Related Posted in Macs, Technology and tagged ASIF, disk image, Disk Utility, diskutil, macOS 26, sparse image, Tahoe. Bookmark the permalink. 14Comments Add yours 1. 1 John Woods's avatar John Woods on June 12, 2025 at 6:41 am Reply Interesting find! didn't VMs on macOS already use a sparse disk image? Is this just really bringing speed improvements? LikeLiked by 2 people + 2 hoakley's avatar hoakley on June 12, 2025 at 8:29 am Reply Thank 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. LikeLike 2. 3 joethewalrus's avatar joethewalrus on June 12, 2025 at 7:36 am Reply This 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. LikeLiked by 1 person + 4 Alan B's avatar Alan B on June 12, 2025 at 8:10 am Reply SMB - do you mean SMB v3 which is much faster than v1? LikeLiked by 2 people o 5 joethewalrus's avatar joethewalrus on June 12, 2025 at 8:25 am Reply Yes, of course version 3. LikeLiked by 2 people + 6 hoakley's avatar hoakley on June 12, 2025 at 8:36 am Reply I'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. LikeLiked by 3 people o 7 joethewalrus's avatar joethewalrus on June 12, 2025 at 9:17 am Reply Virtually 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. LikeLiked by 2 people # 8 hoakley's avatar hoakley 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. LikeLiked by 1 person 3. 9 jzonedotcom's avatar jzonedotcom on June 12, 2025 at 10:31 am Reply Apologies in advance if I missed this: ASIF = Apple Sparse Image Format Thanks very much. LikeLiked by 1 person + 10 hoakley's avatar hoakley on June 12, 2025 at 12:39 pm Reply Thank 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. LikeLiked by 1 person 4. 11 Dominic Dunlop's avatar Dominic Dunlop on June 12, 2025 at 10:39 am Reply Sooner 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). LikeLiked by 3 people + 12 hoakley's avatar hoakley on June 12, 2025 at 12:43 pm Reply Maybe, 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. LikeLiked by 1 person 5. 13 .:. brainsik's avatar .:. brainsik on June 12, 2025 at 7:06 pm Reply Thank 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? LikeLiked by 1 person + 14 hoakley's avatar hoakley on June 12, 2025 at 7:50 pm Reply Yes. 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. LikeLike Leave a comment Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Quick Links * Free Software Menu * System Updates * M-series Macs * Mac Troubleshooting Summary * Mac problem-solving * Painting topics * Painting * Long Reads Search Search for: [ ] [Search] Monthly archives * June 2025 (30) * May 2025 (76) * April 2025 (73) * March 2025 (78) * February 2025 (67) * January 2025 (75) * December 2024 (74) * November 2024 (73) * October 2024 (78) * September 2024 (77) * August 2024 (75) * July 2024 (77) * June 2024 (71) * May 2024 (79) * April 2024 (75) * March 2024 (81) * February 2024 (72) * January 2024 (78) * December 2023 (79) * November 2023 (74) * October 2023 (77) * September 2023 (77) * August 2023 (72) * July 2023 (79) * June 2023 (73) * May 2023 (79) * April 2023 (73) * March 2023 (76) * February 2023 (68) * January 2023 (74) * December 2022 (74) * November 2022 (72) * October 2022 (76) * September 2022 (72) * August 2022 (75) * July 2022 (76) * June 2022 (73) * May 2022 (76) * April 2022 (71) * March 2022 (77) * February 2022 (68) * January 2022 (77) * December 2021 (75) * November 2021 (72) * October 2021 (75) * September 2021 (76) * August 2021 (75) * July 2021 (75) * June 2021 (71) * May 2021 (80) * April 2021 (79) * March 2021 (77) * February 2021 (75) * January 2021 (75) * December 2020 (77) * November 2020 (84) * October 2020 (81) * September 2020 (79) * August 2020 (103) * July 2020 (81) * June 2020 (78) * May 2020 (78) * April 2020 (81) * March 2020 (86) * February 2020 (77) * January 2020 (86) * December 2019 (82) * November 2019 (74) * October 2019 (89) * September 2019 (80) * August 2019 (91) * July 2019 (95) * June 2019 (88) * May 2019 (91) * April 2019 (79) * March 2019 (78) * February 2019 (71) * January 2019 (69) * December 2018 (79) * November 2018 (71) * October 2018 (78) * September 2018 (76) * August 2018 (78) * July 2018 (76) * June 2018 (77) * May 2018 (71) * April 2018 (67) * March 2018 (73) * February 2018 (67) * January 2018 (83) * December 2017 (94) * November 2017 (73) * October 2017 (86) * September 2017 (92) * August 2017 (69) * July 2017 (81) * June 2017 (76) * May 2017 (90) * April 2017 (76) * March 2017 (79) * February 2017 (65) * January 2017 (76) * December 2016 (75) * November 2016 (68) * October 2016 (76) * September 2016 (78) * August 2016 (70) * July 2016 (74) * June 2016 (66) * May 2016 (71) * April 2016 (67) * March 2016 (71) * February 2016 (68) * January 2016 (90) * December 2015 (96) * November 2015 (103) * October 2015 (119) * September 2015 (115) * August 2015 (117) * July 2015 (117) * June 2015 (105) * May 2015 (111) * April 2015 (119) * March 2015 (69) * February 2015 (54) * January 2015 (39) Tags APFS Apple Apple silicon backup Big Sur Blake Bonnard bug Catalina Consolation Console Corinth Delacroix Disk Utility El Capitan extended attributes Finder firmware Gatekeeper Gerome High Sierra history history of painting iCloud Impressionism landscape LockRattler log M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 macOS 14 malware Metamorphoses Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting performance Pissarro Poussin privacy Renoir riddle Rubens Sargent security Sierra SilentKnight Sonoma SSD Swift Time Machine Tintoretto Turner update upgrade Ventura xattr Xcode XProtect Statistics * 19,341,487 hits Blog at WordPress.com. Footer navigation * Free Software Menu * About & Contact * Macs * Painting * Downloads * Mac problem-solving * Extended attributes (xattrs) * Painting topics * SilentKnight, Skint, silnite, LockRattler, SystHist & Scrub * DelightEd & Podofyllin * xattred, Spotcord, Metamer & xattr tools * 32-bitCheck & ArchiChect * XProCheck, T2M2, LogUI, Ulbow and log utilities * Cirrus & Bailiff * Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma * Versatility & Revisionist * Text Utilities: Nalaprop, Dystextia and others * PDF * Keychains & Permissions * Updates * Spundle, Cormorant, Stibium, Dintch, Fintch and cintch * Long Reads * Mac Troubleshooting Summary * M-series Macs * Mints: a multifunction utility * VisualLookUpTest * Virtualisation on Apple silicon * System Updates * Saturday Mac Riddles * Last Week on My Mac * sysctl information Secondary navigation * Search Post navigation Reading Visual Art: 216 Scales (weighing) Interiors by Design: Barns and cowsheds Search for: [ ] [Search] Begin typing your search above and press return to search. Press Esc to cancel. * Comment * Reblog * Subscribe Subscribed + [croppe] The Eclectic Light Company Join 8,032 other subscribers [ ] Sign me up + Already have a WordPress.com account? Log in now. * + [croppe] The Eclectic Light Company + Subscribe Subscribed + Sign up + Log in + Copy shortlink + Report this content + View post in Reader + Manage subscriptions + Collapse this bar Loading Comments... Write a Comment... [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] %d [b]