Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On my (early SSD) laptop I normally choose to put everything in an encrypted LVM because I'm a bit paranoid. :) I assume that all of the great performance features of the file systems such as ext4 assume a lot about the distribution of data that simply isn't true when there's an encryption layer on top. To that end, what is the best file system on top of a layer of encryption? Is it JFS since it "does less" and there for is computationally less expensive?

share|improve this question
What do you mean "assume a lot about the distribution of data..."? Encryption does not alter the placement of data. – psusi Jan 19 '11 at 2:22
Are you saying that LVM encryption is performing encryption on small blocks at a time? – Mike Axiak Jan 19 '11 at 2:24
Yes. – psusi Jan 19 '11 at 2:49
So is your answer that it doesn't matter? I don't know enough about the mechanics of LVM encryption to answer this myself, though you appear to be an expert :) – Mike Axiak Jan 19 '11 at 3:06
@Maike Axiak: Yes. The only difference encryption makes is that if you look at the raw disk, it looks like random garbage. The FS does not know or care that encryption is in use. – psusi Jan 19 '11 at 15:05
up vote 4 down vote accepted

dm-crypt doesn't depend on LVM. It can encrypt any block device, like CDs, even swap space.

It supports a bunch of modes of operation, some of which impact performance more than others, and all of which interact differently with the file system. The encryption doesn't necessarily operate using the same block size as the device itself: the XEX-TCB-CTS mode of operation (XTS) deliberately uses blocks that are not evenly divisible by the hardware block sizes, for example.

However, in reality, the overhead from the encryption is so large that it doesn't make any difference at all. I therefore recommend you choose your file system based on reliability considerations.

As maaartinus points out, if your CPU supports the AES-NI instruction set (cat /proc/cpuinfo to find out), encryption will be fast enough that it may make sense to test different filesystems. However the differences between various filesystems should still be comparable to using no encryption at all, and the usual advice would hold. I still recommend to choose a file system based on considerations of reliability, not speed.

share|improve this answer
I disagree, the overhead from encryption may actually be negligible and the setting may be important. For example, my computer can decrypt 3 GB/s while using AES and only about ten times less while using anything else (that's because of AES-NI; in both cases the overhead is quite low). – maaartinus Feb 26 '12 at 8:03
I didn't take AES-NI into account - however, what do you mean by "anything else"? You don't really have a choice but to use AES today, this discussion was about which file system to use with AES encryption. – Stefano Palazzo Feb 26 '12 at 13:59
Sorry, I missed your point - the encryption overhead might indeed dominate the filesystem performance differences. By anything else I mean the other two algorithms provided by Truecrypt (Twofish and Serpent), but this doesn't matter... the speed of other modern ciphers is quite similar; it's the HW support what makes AES much faster. – maaartinus Feb 26 '12 at 14:27
Great. On a side-note, I absolutely advise against using anything but AES for full disk encryption. The reason Twofish and Serpent haven't been broken yet might be, for all we know, that they haven't gotten enough attention by researchers, whereas AES is the focus of vast cryptoanalysis. The fact that AES-NI speeds it up dramatically hammers it home, AES is the cypher to use. – Stefano Palazzo Feb 26 '12 at 15:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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