删除大量大文件后，空闲空间增加延迟大

Question

昨天，我删除了家庭/媒体服务器上的 71 GB 文件。
之前的可用空间：117 GB
之后的可用空间：126 GB

因此，我没有 71 GB 的额外可用空间，而是只有 9 GB。我仔细检查过没有打开任何文件，我真的删除了 71 GB，可用空间只增加了 9 GB。

我也尝试过同步，但没有效果。

这不是第一次发生。事实上，多年来我时不时地看到这种行为。首先是 ext3，现在是 ext4。
发生这种情况时，我可以通过卸载然后重新安装文件系统来回收可用空间。在这些情况下，卸载最多需要 2 分钟而不是几乎没有时间。

现在，我无法轻松卸载和重新安装文件系统，因为它一直在忙于我的录像机软件、我家人的 owncloud 服务器以及一些我目前还没有的服务。而且我不想在晚上3点钟起床只是为了卸载和重新安装。

不，'at' 实用程序不会这样做，因为其中一个服务执行不可恢复的长时间运行任务，因此需要手动状态检查以找到可以关闭的好时机，即任务刚刚完成。

但是今天早上，我注意到这个空间一夜之间被释放了。在我看来好像进行了某种清理，这可能与卸载时需要额外的时间相同。

到目前为止，我只在删除大量数据时注意到这种行为。另一方面，我不确定它是否经常发生，而且差异太小而无法注意到。

文件系统创建时为 root ( mkfs -m 0)保留了 0% 。根据fsck -f（我总是在卸载和重新安装之间这样做），文件系统没有损坏，并且根据 SMART 诊断扩展测试，硬件也正常。

[编辑]

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  

[/编辑]

所以这是我的两个问题：

1. 这里发生了什么？为什么在 umount 或延迟时释放空间而不是在删除时立即释放？
2. 有什么我可以做，以触发释放的空间，现在没有卸载和重新安装？

Answer 1

有两个因素可能相互作用。

• 与 Windows 不同，您可以删除打开的文件。如果您删除正在流式传输的电影，它将从目录中删除，但在流式传输程序关闭它之前仍会作为文件存在。一旦流媒体软件关闭它，空间将被释放。该fuser -m命令可用于查找具有打开文件的任何进程的进程 ID。某些程序在处理完文件后可能不会立即关闭文件。

• 这些都是日志文件系统。更改写入日志，然后提交。提交更改可能需要一段时间。操作系统通常会缓存磁盘更改，并且只会定期将更改提交到磁盘。运行该sync命令应该将所有挂起的更改刷新到磁盘。使用该sync选项挂载磁盘将提高磁盘速度，但更难处理磁盘。