Part of the issue (why it takes so long) is that ecryptfs does not support sparse files. So an operation that is fast in an unencrypted fs is slow with ecryptfs.
$ time truncate -s 2000M file.img # ecryptfs real 0m26.239s user 0m0.001s sys 0m22.984s $ time truncate -s 2000M file.img # unencrypted real 0m0.019s user 0m0.001s sys 0m0.002s I can kill the "truncate" process if I wish to. I wonder what makes the process unkillable in the scenario of this bug. The unkillable issue also happens with qemu-img. See https://bugs.launchpad.net/ecryptfs/+bug/936706 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/431975 Title: downloading a torrent to an encrypted home partition hangs and uses 100% CPU Status in eCryptfs: Fix Released Status in “ecryptfs-utils” package in Ubuntu: Invalid Status in “linux” package in Ubuntu: Won't Fix Status in “ecryptfs-utils” source package in Precise: Invalid Status in “linux” source package in Precise: In Progress 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
