Applied: [PATCH 0/1][Oneiric][Precise][Quantal][SRU] Evict inodes on rename()/mv
Leann Ogasawara
leann.ogasawara at canonical.com
Mon Sep 17 14:49:54 UTC 2012
Ack'd and applied to master-next for Quantal, Precise, and Oneiric.
Thanks,
Leann
On 09/15/2012 12:10 PM, Colin King wrote:
> 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(+)
>
More information about the kernel-team
mailing list