Comment 122 for bug 509180

I tried "cat /dev/zero > zerofile" since heavy writing / disk exhaustion seemed to be related to the problem. And sure enough, after the empty space went to zero, same errors appeared again to dmesg. After deleting the zerofile I logged out and tried to login, but it failed. Then I tried to shutdown cleanly, but it failed. After a hard reboot the disk space had been freed, and the .Private contained again zero length files. The perm trick reveals that zeroed files include gnome applet files and other stuff that logically could have been written into without user action. All of them are now completely unreadable due to input/output errors.

I'd say that ecryptfs is still extremely dangerous to use due to data corruption problems in a common scenario, writing too much. It simply cannot be offered to users without any kind of warning that this happens.