Existing eCryptfs inodes are not evicted when they're the target of a rename()/mv
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
Medium
|
Tyler Hicks | ||
ecryptfs-utils (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
NOTE: A test case for this bug has been created at tests/kernel/
This bug is the result of existing eCryptfs inodes not being evicted when they are the target of a rename() syscall. The existing inodes are left around, meaning that the lower inodes are also left around, until the eCryptfs filesystem in unmounted. This means that disk space is not properly freed when mv'ing a file on top of another file.
I've verified that 2.6.39 and newer kernels are affected.
Here's the original bug report:
---
1 - Try to download some Ubuntu DVD versions with bit torrent (so it reserves space).
2 - Fill your disk to the maximum and leave something like 5GB.
3 - Wait
4 - Disk space will go to 0 (it doesn't make any sense since space has already been reserved)
5 - Ctrl+Alt+F1
There we can see some messages about ecryptfs :
ecryptfs_
ecryptfs_
[...]
I don't really know if it's really ecryptfs but it doesn't make any sense that disk space just get used up like this when only my firefox browser and bit torrent are open and not trying to write anything else.
While your disk space is at 0, it's slow as hell and it will swap quite much (even though your ram isn't full).
Related branches
CVE References
description: | updated |
Changed in ecryptfs-utils (Ubuntu): | |
status: | Confirmed → Invalid |
Changed in linux (Ubuntu): | |
status: | New → Triaged |
description: | updated |
Changed in ecryptfs: | |
assignee: | nobody → Tyler Hicks (tyhicks) |
Thanks for the report. I'm seeing some funny behavior using bit
torrent too. My disk isn't going to 0. But things have slowed down.