[PATCH 0/1][Oneiric][Precise][Quantal][SRU] Evict inodes on rename()/mv

[Colin King]

From: Colin Ian King <colin.king at canonical.com>

BugLink: http://launchpad.net/bugs/561129

SRU for Oneiric and Precise, and please apply to Quantal too.

== SRU Justification ==

== Impact ==

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.

This can be triggered for example by:

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_write_lower: octets_written [-28]; expected [4096]
ecryptfs_encrypt_page: Error Attempting to write lower page; rc = [-22

== Fix ==

Apply commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a

== Test Case ==

Can be tested on various file systems using the ecryptfs tests (from
lp:ecryptfs).

sudo mkdir /tmp/image /lower /upper
sudo ./tests/run_tests.sh -K -c safe -b 1000000 -D /tmp/image \
-l /lower -u /upper -f ext2,ext3,ext4,xfs,btrfs -t lp-561129.sh

Without the fix, this fails, with the fix it passes.

Tyler Hicks (1):
  eCryptfs: Copy up attributes of the lower target inode after rename

 fs/ecryptfs/inode.c |    5 +++++
 1 file changed, 5 insertions(+)

-- 
1.7.10.4