Disk Images may be old hat, but we’re using them more often and they’re far from straightforward. Generally, a Disk Image is just a file or bundle (a specially structured folder posing as a file) which can be ‘attached’ by macOS and function like a whole disk, with volumes, folders and more. They’re commonly used to distribute software, to protect sensitive documents using encryption, and to provide a virtual file system for Time Machine backups on other host systems with networked storage. What’s so complicated about Disk Images are their many variants and options. This article explains what’s on offer in macOS, with particular emphasis on sparse bundles.

Plain and sparse types

There are two main types of Disk Image: regular images, which include not only the data stored in them but also all free space, and sparse images/bundles which try to store just the data without any free space. Create a normal 10 GB disk image to contain 1 GB of files, and that .dmg file will be 10 GB in size, even though most of it is empty. Create a 10 GB sparse image or bundle, put 1 GB inside it, and it will be little more than 1 GB in size, as it doesn’t store any empty space.

The most common types of Disk Image you’re likely to come across are:

• plain disk image, known as a UDIF read/write image, abbreviated to UDRW;
• sparse image, the UDIF variant that has variable size, UDSP;
• sparse bundle, a bundle that has variable size, UDSB;
• CD/DVD master for export to optical media, UDTO.

Plain single-file UDIF images have other variants, such as UDRO which is read-only, and several compressed formats, and there’s UFBI which is an entire image with an MD5 checksum. Full details including release notes for recent changes are in man hdiutil.

Use

When you open an image or bundle, macOS first attaches it, then inspects it for file systems, which it tries to mount. This is performed at a low level, in the kernel and its extensions, just as if the image/bundle were an external storage device. Thus, the image file or bundle is merely a container for a file system and files.

Those container formats support a range of different file systems, including HFS+ with or without journalling, APFS case-insensitive or case-sensitive and with or without encryption, UDF, ISO9660 or Joliet for UDTO, FAT32 or ExFAT. Different types of checksum can also be used, including SHA-256. Taken together, disk images have more options than most new cars.

Once attached and mounted, you can use Disk Utility and other tools to partition the disk image, add volumes, and perform First Aid checks and repairs on them.

While plain and sparse images are flat files, a sparse bundle consists of a folder, the bundle, with the extension .sparsebundle. Inside that is an Info.plist property list, a duplicate copy named Info.bckup, an empty file named token, and a folder named bands which contains the file system and files forming the virtual disk. As a minimum, there are two numbered bands, but these can grow into as many as needed to contain the files stored in the sparse bundle. By default, each has a maximum size of 8.4 MB; when the sparse bundle needs more storage than can be accommodated within its existing bands, another will be added, up to the maximum capacity of the sparse bundle.

Sparse images and bundles don’t automatically recover space when contents are deleted. To do that, you’ll need to compact them with a utility or hdiutil. Generally, sparse bundles compact more fully than sparse images, but both types can accumulate lost space over time, and in the longer-term can need their contents copied to a new disk image to restore their space efficiency.

Performance

Recent testing of different types of disk image in Monterey has shown that, while their read performance comes close to the high speeds obtained from Apple’s fastest internal SSDs, their write performance is often dismal, particularly when encrypted.

Currently, the only type of Disk Image which can be relied on to deliver acceptable write performance is the sparse bundle. If encrypted, when it has been freshly made and hasn’t been unmounted, write speed can be abysmal, but once written to and unmounted, it’s likely to deliver write speeds 60%-70% of those of the host SSD. Sparse disk images and plain disk images have poor write performance at best, and when encrypted can become abysmally slow. Until their performance has improved substantially, they can’t be recommended for any purpose involving the writing of substantial amounts of data.

Choice

Key questions to decide which type and format to use are:

• After their creation, do you want to write more to them? If not, a plain disk image UDRW or UDRO should be preferred.
• Should their size vary according to how much is stored in them? If so, you’ll want a sparse image (UDSP) or sparse bundle (UDSB).
• Does it need good write performance? If so, you’ll be better off with a sparse bundle, not a sparse image, which normally has lower write speed.
• Encrypted images can be particularly slow to write to, but adding an APFS encrypted volume to the disk image is no faster, and can be even slower than a whole encrypted image. However, if you only need some of the contents encrypted, that might be a better choice.

Resilience

When macOS attaches a disk image, it normally checks its integrity using a checksum. If that check fails, the only way to attach that disk is with hdiutil which has the option -ignorebadchecksums to ignore any errors and tries to attach the disk image regardless, or you can use DropDMG (below).

Flat file formats, including disk and sparse images, are vulnerable to even minor damage. In all cases, automatic attachment should fail, and overriding that seldom allows any recovery of damaged contents. Sparse bundles can be more resilient to damage when it only affects file data rather than that for the container or virtual file system, although that’s a matter of chance. Whichever disk image format you use, backing up contents remains essential if you don’t want to lose data.

Large disk images can contain very many files, and there are concerns over whether they are particularly vulnerable to internal file system corruption. Problems appear to be reported most frequently with sparse bundles used to store network backups, which can suddenly become unmountable. Three factors are worth noting:

• macOS Catalina and later don’t support reading of HFS file systems found in some older disk images. Those are only accessible in Mojave and earlier.
• The number of band files that can be used on HFS+ volumes could be limited to 100,000, although that limit doesn’t appear to be specified anywhere. Choosing an appropriate band file size for the maximum sparse bundle size, to keep the number of bands below that number, could thus be worthwhile.
• File systems in disk images are no less prone to errors and damage than those in regular disk storage, and could be more prone. Preventative maintenance may be worthwhile on large or active file systems in disk images, again sparse bundles in particular.

Creation and management

Disk Utility provides basic support for the most common requirements, although in Monterey it has the exceedingly annoying habit of setting the disk image size to 100 MB whenever it feels like it. At the other extreme, the hdiutil command in Terminal can do almost anything supported for public use, if you can master its byzantine verbs and options.

In between those are two essential utilities:

• C-Command’s excellent DropDMG caters for almost every need, giving full access to nifty features such as background pictures and software licence agreements, used by many developers to distribute their products.
• My own free Spundle only works with sparse bundles, but gives ready access to hdiutil features including the ability to set band file size.

Both apps have long and detailed documentation which you should read carefully, using man hdiutil as your ultimate technical reference.