Server Fault is a question and answer site for system and network administrators. 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

I am running Ubuntu Lucid with a raid0 setup

  • Intel Xeon X3440 - 4x (2x 2.9GHz)
  • 16GB RAM

I got a 1.9TB truecrypt7.0 file container with AES located in my /home (where raid is).

When testing network performance in different ways, like wget, it seems to be able to write/read to the disk just fine for the first 10-20 seconds. I notice then the download suddenly halts for 2-3 seconds, and then continues.

  • Uploading and downloading from a truecrypt volume halts the ul/dl for 2-3 seconds and then continues
  • Uploading and downloading from a tryecrypt volume AND downloading to a regular non encrypted folder, halts all downloads including the regular one
  • Uploading and downloading with a non truecrypt volume (like /root) does not halt and everything goes smooth
  • The halts seems to happen more often the faster the upload/download

I've monitored with htop if it's excessive cpu usage, but only 1-3 cores usually have any load on them. When the download suddenly halts, the cpu usage does not burst unexpectedly. Looking at iostat I only see burst of writes with 2-3 seconds intervals - assuming that's correct due to cache, but I can't see a direct relations to the halt in download/upload

I am unable to reproduce the same error when downloading/uploading to/from a non truecrypt mount, which leads me to believe that there is something going on when reading/writing to a truecrypt file volume.

I am not sure how to troubleshoot this further or if there are tweaks I can do to make it go more smooth. Appreciate any tips/help you can give me.


share|improve this question
up vote 0 down vote accepted

I suggest dstat -cf with an update rate of one second or less so that you can get the resolution required to see inside of that 1-3 second pause.

What you're looking for is a single CPU that is 100% usage or more. Often it isn't possible to parallelize the encryption to take advantage of multiple processors. This means that the maximum rate you can write information to disk is the rate at which a single processor can encrypt.

If you see a single CPU pegged during the entire write / download process, and when the write / download is done, it is idle a part of the time, I would consider that this might be the problem.

NOTE: When I say 'a single CPU', I mean 'one CPU at a time', and not a single specific CPU. Often the OS will move a process (like the disk encryption) from one CPU to another for some reason. That is normal and should be ignored unless those moves correspond particularly well with the download pauses.

Something else you can do to test is to find a large file (say 2x the amount of RAM you have at least) on an unencrypted disk and see how fast you can write it to the unencrypted disk and to the encrypted disk. Also watch the CPU performance as you do each. This will give you verification and probably a good idea of what the total encryption bandwidth is that you can get out of the system.

If you don't find the CPU is the bottleneck, try dstat -af to show statistics on most of the things dstat can measure. You're looking for a similar pattern in other statistics to find the bottleneck, and a similar test can probably help.

share|improve this answer

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.