删除大量大文件后，可用空间会大大延迟

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

因此，我只有9 GB，而不是拥有71 GB的额外可用空间。我仔细检查了没有打开任何文件，并且确实删除了71 GB，可用空间实际上仅增加了9 GB。

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

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

如今，我无法轻松地卸载和重新安装文件系统，因为它在我的录像机软件，家庭的owncloud服务器以及到目前为止我还没有的其他一些服务中一直很忙。而且我不想在晚上3点起床只是为了卸下并重新安装。

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

但是今天早上，我注意到该空间已经释放了一整夜。在我看来，好像已经进行了某种清理，这可能是同一件事，需要在卸载时花费额外的时间。

到目前为止，我仅在删除大量数据时才注意到此行为。另一方面，我不确定它是否定期发生，并且差异太小而无法察觉。

创建的文件系统为根（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. 有什么我可以做，以触发释放的空间，现在没有卸载和重新安装？

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

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

• 这些都是日志文件系统。更改将写入日志，然后提交。所做的更改可能需要一段时间。操作系统通常会缓存磁盘更改，并且仅定期将更改提交到磁盘。运行sync命令应刷新对磁盘的所有未决更改。使用该sync选件安装磁盘可以提高磁盘速度，但会使磁盘工作更困难。