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.
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. /bugs.launchpad .net/ecryptfs/ +bug/936706
See https:/