FileVault - Initial encryption slow - Wishing for option to speed this up

Originator:p.org
Number:rdar://FB9020453 Date Originated:
Status: Resolved:
Product:Filesystem Product Version:macOS 12.2.1
Classification:Application Slow/Unresponsive Reproducible:Yes
 
REPRODUCTION
- macOS 11.2.1 Big Sur on MacBook Pro 15'' (Mid 2014)
-- But other people on the Internet with other Macs report similar experiences
- Boot into a bootable USB3 attached HDD or SSD, formatted as APFS
- Go to System Preferences > Security & Privacy > FileVault
- Click "Turn On FileVault…", then follow the onscreen instructions until the initial encryption starts

ACTUAL
- Encrypting is roughly only 3% (!) of maximum read/write speed

EXPECTED
- Ideal: Encryption automatically uses the resources more economically (as fast as possible while still not blocking the systems and not harming the CPU and storage too much, basically the fans only going a bit above maximum.
- Alternative: Offer a min-max "Speed" slider, with some smallprint explanation text:
Minimum - Your system remains almost unaffected for work, but initial encryption takes longer to finish.
Maximum — Encryption finished quickly, but your system may gets less responsive drring that time. You may grab a coffee 😉.

OBSERVATIONS & ATTEMPTED WORKAROUNDS
- Many other people on the Internet moaned about the slow initial encryption speed, particularly when booted into external volumes.
- In my case the HDD and SSD through their respective enclosure had both ca. 200-220 MB/sec for read/write performance. But during initial FileVault encryption speed only was 7-10 MB/sec, which is only a fragment of it, and the CPU only took 3-5%, fans remained at minimum 2000rpm all time. So neither CPU not storage was facilitated at all.
- None of the following recommendation, which I found online, improved the speed:
-- Energy saving preferences hints. Already made sure that the machine runs 24/7 during that initial encryption.
-- caffeinate -> AFAIK unnecessary if Energy Saving preferences are set to 24/7 operation.
-- sysctl debug.lowpri_throttle_enabled=0 -> Had no effect, also when removing/reattaching AC adapter on MacBook Pro (which pauses/resumes FileVault encryption).

Comments

UPDATE comment from submitter to Apple

1) On-the-fly encryption of received files is a magnitude faster than awaiting initial data-on-disk encryption!

2) Not only on bootable volumes, but also when choosing "Encrypt" after right-clicking an externally mounted APFS volume.

Tested a TOSHIBA DT01ACA300 3.5" SATA HDD connected via a Delock USB-C DiskStation (Item No. 64090, USB 3.2 Gen 1).

Again the data-on-disk initial encryption was only at a crippling slow 7-8 MB/sec write speed, far below what's possible I/O and CPU wise. The same HDD in both Finder and BlackMagicSpeedTest consistently achieved:

~ 170 MB/s seq. write to APFS unencrypted.

~105 MB/s seq. write to APFS encrypted.

As I still had the data source (a SD Card with up to 90 MB/s for reading sequential data) I wanted to shorten my wait time. Hence I aborted the initial encryption progress on the HDD, reformatted right to APFS encrypted, and then copied to it from the SD card at an average of 70 MB/s over the lifespan of copying 490 GB of data in files of various sizes. On-the-fly encryption was 10 times faster than had I awaited the data-on-disk encryption!

And with a different source it could even be faster, as further tests showed. I do not understand why encryption on/to the very same 3.5" SATA HDD differs:

~ 105 MB/s when receiving files from the internal SSD whose read maximum is far above that it could ever be the bottleneck.

~ 70 MB/s when receiving mixed-filesize-data from a SD card, whose maximum for sequential read I measured at ca. 90 MB/s.

~ 7 MB/s when performing encryption of on-disk-data. Why so much slower than on-the-fly encryption?


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!