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 member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
