Tweet
That cryptofs is a HUGE overhead, whether the author will admit it or not (the author of such transparent filesystems is usually reluctant to admit that their software is slow, but it is). The overhead is mainly visible when you're reading lots of small files, not one or two big ones. An i3 is a "cheapo" really low-end CPU to be running a cryptofs on, because it's going to take noticeably longer to decrypt data than a faster CPU. I tried a cryptofs on my i7-3820QM and it was so slow that I had to reinstall without it. FWIW my sound menu opens as fast as i can click the button (no noticeable visual delay) without the cryptofs.
You might intuitively think that most programs installed in /usr or /opt wouldn't read from the encrypted filesystem. You'd be wrong. All the "dot" directories (directories beginning with ".") in your home folder are being very frequently read and written to by various programs; web browsers and gnome programs are particularly egregious offenders. Try running an strace on your favorite slow program and grep for "/home/<user>/."
A bargain-basement system to begin with is going to really underperform when you throw a lot of crypto at it. I'm not at all surprised. Hardware damage is thrown out by the passed SMART tests, so all I can conclude is that it's slow because it's a slow system. Unless you've been running the exact same software stack (without grabbing updates) for a long time and it was fine but then suddenly started tanking. That would be different.
My HDD is a HITACHI HTS725050A7E630. The I/O performance doesn't blow me away, but it's certainly about what I'd expect of a typical 7200RPM, 500GB laptop hard drive. Since yours is 5400RPM, latencies will be higher to begin with. Add in the extra effort of a cryptofs and you have a recipe for slow.
Also -- decrypted pages from a cryptofs are cached in RAM, like any other filesystem, to reduce disk activity. Since Ubuntu greedily eats RAM in the Unity environment, it's not going to leave much RAM left over for page cache. Page cache translates directly to high performance, especially when your fs is encrypted. So your slow hdd has to frequently read lots of tiny little files through an encryption layer on a bargain-basement slow CPU and then read them again when they are accessed again because they're constantly getting bumped out of the page cache.
Sounds like your problem is a systemic one; i.e., the reason for the observed result isn't just one single component but a combination of factors due to using cheap components and a high-overhead crypto layer. It's kind of like metabolic syndrome in older/obese people, and how your entire body starts to fail, but treating just one organ doesn't slow down the downward spiral. You have to treat the entire system.
I think you'd have expected performance levels if you:
1. Double your RAM to at least 4GB (even my extremely cheap employer, who has no idea what IT requirements its employees actually have, gives us 4GB)
2. Get rid of the ecryptfs
3. Upgrade your HDD to a 7200rpm model. They have 'em up to at least 750GB but you can find them affordably at the same capacity as you have (500GB).
I'd almost say that upgrading the processor would help too, except that the CPU isn't going to be nearly as busy if it isn't decrypting files, so you might find that the CPU has plenty of spare cycles when removing the ecryptfs.
You can also try, without upgrading any hardware, setting your ext4 filesystem to mount as "data=writeback,nobh" (documented here) -- this will give the filesystem much more flexibility about when to commit to disk, which results in less seeking and less frequent disk writes. Writes will pile up in RAM unless specifically fsync()ed to media or unless there's no more room in RAM. It should keep the disk relatively quiet unless it needs to read something that isn't from the page cache (which again is very likely with only 2GB).
You might intuitively think that most programs installed in /usr or /opt wouldn't read from the encrypted filesystem. You'd be wrong. All the "dot" directories (directories beginning with ".") in your home folder are being very frequently read and written to by various programs; web browsers and gnome programs are particularly egregious offenders. Try running an strace on your favorite slow program and grep for "/home/<user>/."
A bargain-basement system to begin with is going to really underperform when you throw a lot of crypto at it. I'm not at all surprised. Hardware damage is thrown out by the passed SMART tests, so all I can conclude is that it's slow because it's a slow system. Unless you've been running the exact same software stack (without grabbing updates) for a long time and it was fine but then suddenly started tanking. That would be different.
My HDD is a HITACHI HTS725050A7E630. The I/O performance doesn't blow me away, but it's certainly about what I'd expect of a typical 7200RPM, 500GB laptop hard drive. Since yours is 5400RPM, latencies will be higher to begin with. Add in the extra effort of a cryptofs and you have a recipe for slow.
Also -- decrypted pages from a cryptofs are cached in RAM, like any other filesystem, to reduce disk activity. Since Ubuntu greedily eats RAM in the Unity environment, it's not going to leave much RAM left over for page cache. Page cache translates directly to high performance, especially when your fs is encrypted. So your slow hdd has to frequently read lots of tiny little files through an encryption layer on a bargain-basement slow CPU and then read them again when they are accessed again because they're constantly getting bumped out of the page cache.
Sounds like your problem is a systemic one; i.e., the reason for the observed result isn't just one single component but a combination of factors due to using cheap components and a high-overhead crypto layer. It's kind of like metabolic syndrome in older/obese people, and how your entire body starts to fail, but treating just one organ doesn't slow down the downward spiral. You have to treat the entire system.
I think you'd have expected performance levels if you:
1. Double your RAM to at least 4GB (even my extremely cheap employer, who has no idea what IT requirements its employees actually have, gives us 4GB)
2. Get rid of the ecryptfs
3. Upgrade your HDD to a 7200rpm model. They have 'em up to at least 750GB but you can find them affordably at the same capacity as you have (500GB).
I'd almost say that upgrading the processor would help too, except that the CPU isn't going to be nearly as busy if it isn't decrypting files, so you might find that the CPU has plenty of spare cycles when removing the ecryptfs.
You can also try, without upgrading any hardware, setting your ext4 filesystem to mount as "data=writeback,nobh" (documented here) -- this will give the filesystem much more flexibility about when to commit to disk, which results in less seeking and less frequent disk writes. Writes will pile up in RAM unless specifically fsync()ed to media or unless there's no more room in RAM. It should keep the disk relatively quiet unless it needs to read something that isn't from the page cache (which again is very likely with only 2GB).
Comment