10

Writing to a fully encrypted USB flash drive on Mavericks is extremely slow.

The drive model I used for testing was a Kingston DataTraveler Ultimate 3.0 G3 (64 GB). I tested transfer speeds by reading/writing a large file from/to both an encrypted and an unencrypted drive. I tested on a current Macbook with Mavericks and on an older machine with Mountain Lion. I used Disk Utility to format the drive as Mac OS Extended (Journaled) and Mac OS Extended (Journaled, Encrypted).

MacBook Pro (2013) with USB 3.0 running OS X 10.9.2 (13C64)

Write: 86.16 MB/sec (encrypted: 0.62 MB/sec)
 Read: 181.66 MB/sec (encrypted: 151.15 MB/sec)

MacBook Pro (2007) with USB 2.0 running OS X 10.8.5 (12F45)

Write: 23.57 MB/sec (encrypted: 5.04 MB/sec)
 Read: 36.23 MB/sec (encrypted: 37.87 MB/sec)

As you can see on the older machine the write speed clearly decreases when writing to the encrypted volume but is still about ten times faster compared with the newer machine running Mavericks. Could this be some recently introduced issue in FileVault or CoreStorage?

Update (2014-06-28)

The USB drive seems to have had a hardware defect from the start. I got a replacement drive (same model) which still doesn't deliver the results I would expect but at least the encrypted write speed of the 2013 MBP is now on par with the 2007 MBP.

MacBook Pro (2013) with USB 3.0 running OS X 10.9.3 (13D65)

Write: 135.41 MB/sec (encrypted: 9.29 MB/sec)
Read: 196.22 MB/sec (encrypted: 187.04 MB/sec)

MacBook Pro (2007) with USB 2.0 running OS X 10.8.5 (12F45)

Write: - MB/sec (encrypted: 9.39 MB/sec)
Read: - MB/sec (encrypted: 37.79 MB/sec)

This still leaves the question though why the encrypted write speed to the USB drive on the 2013 MBP is less then ten percent of the regular write speed. I also compared read/write speeds before and after activating FileVault on the internal SSD of the 2013 MBP and there I couldn't detect any slowdown at all.

|improve this question
  • 1
    Wow - the normal read/write and encrypted writes look good. But that encrypted write is painfully slow. What tool is measuring the MB/s? Can you reproduce these results using Blackmagic (free on MAS) – bmike♦ Mar 13 '14 at 19:26
  • I used a simple Bash one-liner utilizing time, dd and awk. Blackmagic gives me the same results: goo.gl/bn32fC (unencrypted) vs. goo.gl/yghyqA (encrypted). – Stefan Schmidt Mar 13 '14 at 21:54
  • I suspect the read speed for the encrypted volume is missing because the duration of the read is shorter than Blackmagic's throughput sampling interval – Stefan Schmidt Mar 13 '14 at 22:00
2

I have the same problem, which I'm pretty sure is due to a combination of the way write operations work on flash memory and the way core storage (or any whole-volume) encryption works.

First, write behavior: unlike volatile memory (the stuff used in the memory of your computer) or hard disks, where any bit can be written to 0 or 1 at any time, flash memory has two main states: written and erased. Within "written" are 0 and 1. When you need to write to flash memory you must write an entire block that is currently in the erased state. File system software in the OS may know what blocks are free, but the controller and storage on a flash device don't. A special way for the OS to tell an SSD to make blocks available has been devised for "bus-connected" SSDs: it's called TRIM. USB protocol stacks don't, to my knowledge, support TRIM. So, basically, flash memory continues to fill up until there are no actual erased blocks, at which point the file system has to erase and rewrite blocks by reading them, merging in the new data, erasing, and writing them back out. That's why you see small-file write performance degrade on SSDs over time.

The special circumstances of encrypted volumes is interesting: depending on the way the encryption works, it may actually encrypt an entire volume, filling all the blocks with what appears to be random data even if the blocks are actually unused and would contain zeroes. So when you turn on FileVault (or otherwise enable core storage encryption), it basically consumes the entire volume, leaving no space for write operations. The file system has to constantly read, erase and rewrite blocks so that it can rewrite them with any encrypted data you want to put on it.

Now I will say right here that this is speculation based on a reasonable understanding of how things work, but there are people who actually know the details, who may correct or improve my explanation and I hope that they will do so.

|improve this answer
  • That indeed sounds very reasonable. I did some digging and it seems that for external drives eSATA and Thunderbolt both support TRIM. This might be interesting concerning external SSDs but probably not for thumb drives because Macs don't have eSATA interfaces and it doesn't look like affordable Thunderbolt thumb drives will be available anytime soon: goo.gl/sDM1au – Stefan Schmidt Jul 8 '14 at 14:06
  • 1
    Just in case someone is wondering: For the meantime my workaround is to create an encrypted sparse bundle on the drive sized as the capacity of the drive. I didn't do any benchmarks but it feels roughly on par with writing unencrypted data to the drive. – Stefan Schmidt Sep 10 '14 at 20:09
  • @StefanSchmidt an encrypted sparse bundle like described here? blog.fosketts.net/2015/07/22/… – Brad Cupit Sep 3 '15 at 21:17
  • @BradCupit Yes but I synchronize the content of the sparse bundle, not the sparse bundle itself, so I mount the sparse bundle with hdiutil attach, then use rsync to synchronize with my local folder, then unmount the sparse bundle with hdiutil detach and eject the disk drive with diskutil eject. – Stefan Schmidt Sep 10 '15 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .