Bug Description

Karmic with all updates. Home is encrypted with ecryptfs.
I have tried downloading several torrents with thansmission and rtorrent. When downloading to the encrypted home, both programs hang, use 100% CPU and I can't kill them. Downloading to /tmp, which is not encrypted works.

I having the very same problem with an up2date jaunty ecryptfs home, and transmission (the included version, and after first having the issue, updated to transmissionbt ppa) as soon as transmission starts allocating the space for the torrent data, my one of my cpu cores gets 100% (transmission gets it in htop) memory cache gest filled in no time, till that the disk activity is high and after the disk stop, and transmission locks up... can only stopped by holding down the power key for several seconds, or using sysrq!! (SIGKILL does not help!)

Please lead me to provide all the information you need to fix this ass soon as possible!!

Hi Victor and u-foka - It looks like u-foka is correct that it occurs when rtorrent creates and extends a file big enough for the entire torrent download. If you're downloading something like a dvd iso, this causes eCryptfs to encrypt 4.7 GB of zero's and write the result to the lower filesystem.

When I tried to reproduce this, I didn't see more than 50% cpu utilization, but it did take quite some time to create and extend the file. However, rtorrent then proceeded to download the file, as expected.

You can also reproduce this behavior without rtorrent with `truncate -s 1G foo` inside of an eCryptfs mount to create and extend foo to 1 GB. It took about 1 minute and 16 seconds to complete inside of my kvm guest.

Are you all experiencing this on a machine with a relatively slow processor?

I don't think there's any need for the ecryptfs_readpage -> ecryptfs_read_lower_page_segment -> ecryptfs_read_lower sequence, as we know that we just need to encrypt a bunch of zeroes. Fixing that will improve performance, but the CPU is still likely to be pegged pretty high while doing all the encryption operations.

Improving the truncate path would really be a nice-to-have improvement, but I will probably not be able to devote much time to it. If someone wants to try to tackle it, I'll be more than happy to provide any help that I can.

I understand that it can take a while to create a 4 gb file, but what is strange, that:
- I don't think that it has to take more than ten minutes (core2duo@2ghz 2 gb ram WD3200BEVT hdd 5200 rpm)
- The disk stops working after about 3-4 seconds
- with dm-crypt (what I switched to encrypt my home instead of ecryptfs) it only takes seconds to do the job done (about 20-30) when I started to download the same file...

what I think the ext4 file system
Green is still very slow and I think it is stupid to think that besides
the stable ecryptfs that not all Czech
v ext3 and see the difference in yield figure look what happens in fedora
have many problems with ext4

is cruel to say but I would eliminate it would cease to prueva ecryptfs
future and when ext4 is well developed that you see the 2.6.31 kernel
patches may give a temporary solution but performance would be slow despite
the efforts ....

in dmesg a crazy amount of the same error messages
[26030.752479] Valid eCryptfs headers not found in file header region or xattr region
[26030.752483] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

I have this problem as well, but I'm quite sure it's now just being slow, as I waited for several hours and operations didn't finish (all other operations on the encrypted filesystem take minutes at most, even with 10 GiB files). It appears that this happens when the requested file size is bigger than free RAM.

Therefore, I think this shouldn't be classified as Wishlist, but rather as a proper bug.

The description is similar to what others have observed: looking at the system monitor, it starts using CPU and disk and the cache goes up very fast; when the cache is full, disk operations stop, but the CPU keeps running at 100% and the program becomes unresponsive (both Transmission and Vuze). If the processes are killed (kill -9), they keep running as zombies at 100% and reboot is the only way to stop them (BTW from what I read this in itself could be considered a bug, as zombie processes shouldn't keep the CPU busy as far as I know). Swap is never used during the process.

My current workaround is to create an unencrypted directory under /home/ with permissions set to my user, and use that one for torrent downloads (clearly not an optimal solution, but still better than using /tmp).

> I have this problem as well, but I'm quite sure it's now just being
> slow, as I waited for several hours and operations didn't finish (all
> other operations on the encrypted filesystem take minutes at most, even
> with 10 GiB files). It appears that this happens when the requested file
> size is bigger than free RAM.
>
> Therefore, I think this shouldn't be classified as Wishlist, but rather
> as a proper bug.
>
> The description is similar to what others have observed: looking at the
> system monitor, it starts using CPU and disk and the cache goes up very
> fast; when the cache is full, disk operations stop, but the CPU keeps
> running at 100% and the program becomes unresponsive (both Transmission
> and Vuze). If the processes are killed (kill -9), they keep running as
> zombies at 100% and reboot is the only way to stop them (BTW from what I
> read this in itself could be considered a bug, as zombie processes
> shouldn't keep the CPU busy as far as I know). Swap is never used during
> the process.
>
> My current workaround is to create an unencrypted directory under /home/
> with permissions set to my user, and use that one for torrent downloads
> (clearly not an optimal solution, but still better than using /tmp).
>
> Some additional details on my configuration:
> I'm using Ubuntu Lucid 10.4, clean install, ext4 filesystem, encryption
> selected at installation, up-to-date Kernel (Linux 2.6.32-22-generic
> #36-Ubuntu SMP i686 GNU/Linux)
>
> --
> downloading a torrent to an encrypted home partition hangs and uses 100%
> CPU
> https://bugs.launchpad.net/bugs/431975
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Actually, it is a kernel bug, and Tyler Hicks (the upstream maintainer) sees the problem, but hasn't had time to fix it. Ubuntu kernels are affected, though we're not working on it on the Ubuntu side. We're just waiting for upstream to commit a fix.

I can attest to this in Lucid with ecryptfs encrypted /home/user. I'm not sure about Transmission or Vuze, but in rtorrent, there's a way to save the machine and still have large torrent downloads; add this to your ~/.rtorrent.rc:

split_file_size = 8G # or 4G or 3G, depending on your system (mine is good at 3G)

And then when the torrent is completed simply run 'cat file_1 file_2 ... > file_x' and then you're good to go.

Please could someone upgrade this from wishlist? It is a bug, unkillable processes require a system reboot which is very annoying, this is likely to contribute to people (including me) regarding Ubuntu LTS as unstable, and I'm now regretting choosing to encrypt my homedir during the installation because of this bug.

Does this mean that drive encryption is no longer supported? Or, that drive
encryption is still supported and this bug will never be fixed?

-Malcolm
On Jul 14, 2011 1:18 PM, "Brad Figg" <email address hidden> wrote:
> This bug was filed against a series that is no longer supported and so
> is being marked as Won't Fix. If this issue still exists in a supported
> series, please file a new bug.
>
> This change has been made by an automated script, maintained by the
> Ubuntu Kernel Team.
>
> ** Changed in: linux (Ubuntu)
> Status: Triaged => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/431975
>
> Title:
> downloading a torrent to an encrypted home partition hangs and uses
> 100% CPU
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem:
> Triaged
> Status in “ecryptfs-utils” package in Ubuntu:
> Invalid
> Status in “linux” package in Ubuntu:
> Won't Fix
>
> Bug description:
> Karmic with all updates. Home is encrypted with ecryptfs.
> I have tried downloading several torrents with thansmission and rtorrent.
When downloading to the encrypted home, both programs hang, use 100% CPU and
I can't kill them. Downloading to /tmp, which is not encrypted works.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ecryptfs/+bug/431975/+subscriptions

I think the automated scripts are far to aggressive while trying to "fix" the bugs. Please change the importance of this problem to something else than "wishlist", as it's a bug. In case Tyler found some time and the bug got already fixed, please close it. Maybe Dustin or Tyler can change the status? If you need some more information or help I'm pretty sure the users are willing to help you.
I always wondered what made my hard disk so slow, and after reading here and about the other trailing bug I am done with ecryptfs. I mean, you should not offer the feature on the install disc without warning since years when there are severe bugs. I will go back to luks for now.

How to trigger: Use transmission (or any other software) to create over 4GB file (5GB torrent in my case) on
encrypted home directory.

It is NOT filesystem or disk performance problem (filesystem continues to perform for all other purposes and
I waited over 30h for it to possibly sort itself out). It really is something unduely stuck in kernel.

It is probably a bug in many places:

1. Bug in init for not reaping up the zombie
2. Bug in kernel for zombie process consuming resources other than process table slot.
3. Bug in ecryptfs kernel module (or possibly ext4 or their mutual interaction) for getting in the trouble in the first place

I agree that it is reckless to advertise in install process the ability to encrypt home directories
while this bug persists. Only known workaround is not to encrypt home directory. Bugs like
this help to educate users that encryption is a bad thing - exactly opposite of what was
probably intended by including encrypt home directories feature in the first place.

This is clearly a bug, not a wish list item. I can't change the importance, but since it's clearly been incorrectly triaged, I can change the status from Triaged to Confirmed.

This is yet another example of Ubuntu pushing out software with known, serious bugs. In this case, Ubuntu's pushed out FOUR more releases with this bug. This bug causes system instability, data loss, and requires a hard reset...how much more serious can it get? Can we come up with a security angle? Maybe then it will get fixed...

On 2012-02-08 18:17:49, Amit wrote:
> i just want to fix ecryptfs.
> what i should do .?

You can pull down those patches, apply them, and build a kernel yourself
(something that you'd have to research and do on your own) or you'll
have to wait for your distro to release a kernel update with these
fixes.