I have my home directy encrypted with ecryptfs. Does ecryptfs lead to fragmentation?

I have the feeling that reading files, displaying folders and login became continuously slower and slower (although it was not noticeably slow at the beginning). The hard disk makes a lot of seek noise even if I open only a text file. In /home/.ecryptfs I see many big archives (that probably contain the encrypted files), so I'm wondering if Linux file system online defragmentation gains anything here.

What options do I have to increase performance? Should I decide whether I maybe better do without encryption?

  • maybe your encrypted partition is getting full? can you check this with df command, pls? Please edit your initial posting to add the output. – Michael K Feb 2 '12 at 12:21

Phoronix has run a suite of tests and a couple of articles on eCryptfs performance when encrypting home directories:

My take away from those articles is that encryption (as expected) according to the benchmarks, does impact read and write performance to a degree. On small CPUs (Atom processors), and on fast hard drives (SSDs), this is perhaps more noticeable. That said, by using eCryptfs, you're only paying that performance penalty when reading/writing data to your home directory (and not the rest of the system, as you would with full-disk encryption). Furthermore, with faster processors, the amount of time spent doing that encryption/decryption often fits within the IO wait accessing the data from disk, which is usually the bottleneck.

As to your particular issue, if you're hearing a lot of "hard disk seek" noise, it sounds to me that your system is swapping data from memory to disk, and back and forth. If you've chosen to use eCryptfs, then Ubuntu will automatically encrypt your swap space (which is required to safeguard your encrypted data). However, encrypted swap is very expensive, too.

Personally, I overload my systems with lots of RAM (8GB on most of my systems), and disable swap entirely.


I am programming with python in my home directory, and I have a Python virtual environment for project packages.

For my programs startup times are considerably slower on eCryptfs as Python issues many stat() system calls when locating module files; because many of these stat calls result in "file not found", and such results are not ever cached, but we still pay penalty for the ecryptfs, things are consistently sluggish.


I ended up removing ecryptfs from my home dir by moving the ecryptfs mountpoint to ~/private, copying most files out of the ~/private to my uncrypted homefolder. Things are now fast again. Maybe the performance penalty would be less for some other CPU, I have an Asus 1215N with Atom.

  • I have a new Pentium i7 QuadCore and the performance still sucks for me. – HDave Feb 11 '14 at 20:09

I haven't made any hard core measurements so take the following with a grain of salt but I have noticed extremely poor performance with ecryptfs in the following scenarios compared to a dm-crypt'd LV (mounted as /home/username):

  • du on a folder with lots of files. It takes several minutes while only a few seconds using dm-crypt of the whole partition - this is by far the worst case

  • opening a folder with lots of items in mutt takes several seconds (around 20 on a folder with 10000 items) while it is almost instantaneous with dm-crypt

  • git operations are slower (by some, not a lot) compared to dm-crypt

  • applications such as firefox take noticeably longer to start but we are still in the seconds range

I just moved to dm-crypt (with pam_mount) and couldn't be happier!


calls such as truncate() and ftruncate() that increase file size are slower on ecryptfs because it has to fill with encrypted zeros, unlike normal file systems that just create holes in the file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.