Full disk encryption and "large files" - a loose experiment

• life

So apparently full disk encryption is not the best idea for people who work with “large” files (where “large” was loosely defined as “multi-megabyte” in one of the threads I skimmed through). I couldn’t find anything informative never mind definitive on how full disk encryption would affect 3d and large digital painting work, so decided to run some experiments particular to my usage. These are not benchmarks in any way, shape or form, I was entirely too lazy to do things properly.

System:

• quad core 3.4Ghz Intel Core i7
• 16Gb 1333MHz DDR3 RAM
• AMD Radeon HD 6970M with 2Gb on board RAM
• 250Gb ssd
• 2Tb hdd

No hardware problems as far as I can tell.

Normally open:

A hundred billion things running simultaneously. At the very least:

• Adium
• Skype
• Mail
• iCal
• Firefox
• Sophos
• iTunes

Plus all the system and background processes.

Normal activity:

Art set

• Lightwave3D (usually just Modeler, sometimes Layout is open when I feel like playing, will be open more and more often when I start animating)
• GIMP, rarely Pixelmator, even more rarely both
• LibreOffice or NeoOffice

Coding set

• Netbeans
• Terminal
• Cyberduck
• Chrome
• Opera
• Safari

Test files:

• 45.7Mb xcf
• 9.5Mb lwo

I would have liked to test with a high definition uncompressed avi file (at least 1Gb worth) but I haven’t animated anything worthwhile yet.

Prior to encryption everything was running smoothly. GIMP 2.6 had some very minimal lag and multiple little irritating interface issues which I usually attributed to the fact it runs in X11, Modeler has a tiny bit of noticable lag when dealing with a large number of polygons but it seems to be a Lightwave problem as other people have reported the same issue, and I know it’s not my machine.

Encrypting the ssd was a very straightforward process (it’s the Lion volume so all I had to do was turn on FileVault and click through the prompts and copy the recovery key). Process reported 55mins and probably took about that long (I didn’t time it any closer). The hdd needed to be reformatted to MacOS Extended (Journaled, Encrypted) using OSX’s Disk Utility, which meant I had to copy the stuff on it onto the ssd temporarily. Reformatting the 2Tb drive was a bit weird as I expected it to take longer but it took 10 seconds. I was that uncertain I did it again and got the same results, but seemed to lock it in limbo (at least the second time it reported it was an “Encrypted partition”) which was fixed by a reboot, after which it reported the expected format and the correct size and asked for a passphrase to mount.

After encryption I didn’t notice any difference during the non-heavy usage. Copying 16.34Gb from the unencrypted hdd to the encrypted ssd took about as long as I expected it to. Copying the 16.34Gb of stuff back onto the encrypted hdd from the encrypted ssd didn’t take any longer. I broke what would have otherwise been something bordering on a scientific investigation by getting excited about GIMP 2.8 being OSX-native and grabbed it.

Opening the xcf file took slightly longer which was not unexpected. Manipulating the file (zooming, scolling around) took a lot longer than expected. Problems started when I experimented with fur painting and only every third or fourth brush stroke was being executed with no apparent pressure sensitive opacity. Additionally, it managed to blow away the 7Gb I had free on tmp and/or swap files (I currently have about 11Gb free on the ssd, Lightwave was open at the time and may have been using at least 1Gb but not sure what else would have been taking up space otherwise) causing many of the other applications to have a cry about “the startup disk is almost full, delete some stuff to recover space” (that’s a lot of prompts to tell to go away). Got frustrated, jumped to the somewhat premature conclusion that it must be the encryption and reformatted the drive back to MacOS Extended (Journaled).

Because any scientific validity I might have pretended to have was well and truly shot, I cranked up Lightwave and the copy of the 9.5Mb lwo that was on the still-encrypted ssd. That ran the same as it always had with no real advantage that I noticed to having the file on the same drive (previously I’d been working with the file on the hdd). So at this stage it was either encryption or GIMP 2.8.

After the 2Tb drive had reformatted back to the format it had been in originally, I copied the folder containing the 47Mb file back onto the hdd and cranked up GIMP 2.8 again. There was no difference in performance, it still choked on the 47Mb file. I rolled back to GIMP 2.6 in the X11 environment. It not only told me the file was 43.7Mb (where’d the other 2-3 go?) but it opened it without choking and with no lag on zooming or scrubbing. When I tried to paint some fur it spluttered a little, doing the strokes I told it to do down to accurate pressure-sensitive opacity but with just enough feedback lag to make working slightly annoying. Decrypted the ssd to see if that would make a difference or if it’s just working on big files in general that is the problem, and had a bit of a Microsoft moment where I decided to reboot to make sure any changes would take effect properly. It had no effect I noticed on working on the 46Mb file. I switched to using a 5Mb xcf, and GIMP 2.8 mysteriously had exactly the same problems with the smaller file as it had with the larger one. GIMP 2.6 had no performance issues.

So going back to what I should have done in the beginning if I’d not jumped the gun with GIMP 2.8, I tested with both drives encrypted. GIMP 2.6 functioned exactly the same on both files as it had when both drives were decrypted. Lightwave took part of a second longer to load its file from the hdd instead of the ssd, otherwise there was no difference in performance with both drives encrypted from when both were decrypted.

Further testing

I am leaving my drives encrypted to see how large any given large file can get before I start suspecting that the encryption might be affecting it and decrypt the drives to test the hypothesis. If I get to animating/video/sound editing before I feel the need to decrypt the drive for suspected performance reasons, I will be able to test the impacts (if any) on those activities.

Conclusions

• OSX-native GIMP 2.8 is laggy/buggy
• large xcf files (possibly large files in general) may occasionally lag to some degree regardless of hardware and whether or not the drive is encrypted
• full disk encryption does not appear to have performance impact working with large files in the way I’m working with them at the moment

This work by bek (ryivhnn) is licensed under a Creative Commons Attribution 4.0 International License