Slow Mac Disk Image Writing
While reading from each of the Disk Images was almost as fast as from the SSD, write speeds were severely reduced. The sparse bundle was least impaired, with a write speed just under half that of the SSD, but all three disk images wrote at less than 20% of SSD speed, with the encrypted disk image the worst of all, at less than 1%.
[…]
Given the high write performance of the SSDs used, this can only indicate that macOS is intentionally throttling threads responsible for performing writes to the encrypted disk image, and to unencrypted disk images too.
[…]
This difference may reflect Apple’s historical usage of disk images, which have been most commonly used for reading rather than writing. However, that has now changed, with write performance becoming important to the user in:
- encrypted disk images used as a substitute for the absence of folder encryption in APFS;
- both encrypted and unencrypted sparse bundles used for shared Time Machine backup storage;
- unencrypted disk images used as Block Device storage in virtualisation.
There’s a new twist: results differ when the image is still mounted after creation, and after unmount-remount.
I haven’t done encrypted UDSP, but
enc UDRW is 55 MB/s first time, 900 remounted;
enc UDSB is 360 first, 4.3 GB/s remounted;
plain UDRW 1.3 GB/s falls to 970 MB/s.
Previously:
Update (2022-07-07): Howard Oakley:
This article presents a lot more data, which both clarify and confound. The TL;DR is that writing to macOS Disk Images – whether plain .dmg, sparse disk images, or sparse bundles – is a complete gamble. Sometimes they perform fairly well, and sometimes they’re excruciatingly slow.
[…]
As things stand, 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.
The disk (block) image device driver does not cache any decrypted fata and also does not allow the use of macOS disk block cache to be used, all probably in order to prevent finding any unencrypted data in memory by an attacker. Thus, every time the file system driver wants to access a block, eg. to traverse the directory b*tree, it’ll have to fetch the block from the SSD and then decode it. And I also suspect that even when encryption is not used, the block cache is denied, thus causing bad performance even then.
1 Comment RSS · Twitter
To clarify: My comments on (not) using the volume disk cache are a hypothesis, which I made based only on experience, with no actual knowledge of what is going on. My experience comes from having written disk drivers and file systems for the Mac in the past.
