Yesterday, I have deleted 71 GB of files on my home/media server.
Free Space before: 117 GB
Free space after: 126 GB
So, instead of having 71 GB of additional free space, I only had 9 GB. I have double-checked that no files were open and I really have deleted 71 GB and free space really increased only 9 GB.
I also tried to sync, but no effect.
This is not the first time it happens. Indeed, I have seen this behaviour since years every now and then. First on ext3, now on ext4.
When this happens, I can reclaim the free space by unmounting and then remounting the filesystem. In these cases, unmounting takes up to 2 minutes instead of nearly no time.
Nowadays, I can not easily unmount and remount the filesystem, because it is permanently busy from my video recorder software, the owncloud server for my family, and a few more services I did not have so far. And I don't want to get up at 3 o'clock in the night just to unmount and remount.
No, the 'at' utility won't do because one of the services performs non resumable long running tasks and thus needs a manual state check to find a good moment when it can be shut down, i.e. a task was just finished.
But this morning, I noticed that the space has been freed overnight. Looks to me as if there was some kind of cleanup, and this may be the same thing that takes the additional time when unmounting.
So far, I only noticed this behaviour when deleting a large amount of data. In the other hand, I am not sure if it happens regularly and the difference is just too small to notice.
The filesystem was created with 0% reserved for root (
mkfs -m 0). According to
fsck -f (I'm doing this always between unmount and remount), the filesystem is not corrupted, and according to S.M.A.R.T. diagnostics extended test, the hardware is also OK.
tune2fs 1.42 (29-Nov-2011) Filesystem volume name: bigdata Last mounted on: /bigdata Filesystem UUID: 6aebd17a-e064-41dc-9c68-c9a3acbe4f66 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 121413632 Block count: 485645568 Reserved block count: 0 Free blocks: 29081276 Free inodes: 121382378 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 908 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Tue Dec 25 23:42:35 2012 Last mount time: Fri Jan 3 17:37:36 2014 Last write time: Fri Jan 3 17:37:36 2014 Mount count: 37 Maximum mount count: -1 Last checked: Thu Apr 18 17:03:40 2013 Check interval: 0 (<none>) Lifetime writes: 14 TB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: be2b977e-5127-4843-9123-fe33b6d7b573 Journal backup: inode blocks
So here are my 2 questions:
- What is happening here? Why is space freed at umount or with a delay instead of immediately at delete?
- Is there something I can do to trigger freeing the space right now without unmounting and remounting?