运行以下命令:
$ df -h
给出以下输出:
Filesystem Size Used Avail Use% Mounted on
/dev/md2 91G 85G 1.2G 99% /home
这意味着总共 91 GiB 中仅使用了 85 GiB,还剩下 6 GiB Avail
(91 - 85 = 6)。
为什么Avail
只有 1.2 GiB?
这个问题明确地涉及输出中的Used - Size
和列之间的矛盾,而不是和之间的差异Avail
df
df
du
,而不是诸如这个相关问题。
就我而言,文件系统上没有仍在使用的已删除文件。
答案1
默认情况下,ext2、ext3 和 ext4 文件系统保留 5% 的容量供 root 用户使用。这减少了碎片,并使得 root 用户或任何 root 拥有的守护进程不太可能耗尽磁盘空间来执行重要操作。有关此预订背后原因的更多信息可以在以下问题的答案中找到:这个相关问题。
您可以通过以下方式验证预订的大小tune2fs
命令:
tune2fs -l /dev/md2 | grep "Reserved block count:"
-m
可以使用以下命令的选项更改预留百分比tune2fs
:
tune2fs -m 0 /dev/md2
-r
可以使用以下命令的选项更改保留的保留块的数量tune2fs
:
tune2fs -r 0 /dev/md2
保留空间在具有与操作系统无关的静态内容的大型文件系统上最没有用处。对于此类文件系统,将保留减少到零是合理的。文件系统最好保留默认的 5% 保留,包括那些包含目录/
、/root
、/var
、 的目录,并且/tmp
这些目录经常被守护程序和其他操作系统服务用来在运行时创建临时文件或日志。
答案2
造成这种影响的最常见原因是打开的文件已被删除。
仅当删除文件时未使用该文件时,内核才会释放该文件的磁盘块。否则,这将推迟到文件关闭或系统重新启动为止。
确保不留下任何临时文件的 Unix 世界常见技巧如下:
- 进程创建并打开临时文件
- 在仍然保留打开的文件描述符的同时,进程取消链接(即删除)文件
- 进程通常使用文件描述符来读取和写入文件
- 进程完成后关闭文件描述符,内核释放空间
- 如果进程(或系统)意外终止,则临时文件已被删除,无需清理。
- 作为奖励,删除文件可以减少创建临时文件时命名冲突的机会,并且还为正在运行的进程提供额外的一层模糊性 - 对于除根用户之外的任何人来说。
此行为确保进程不必处理突然从其脚下拉出的文件,并且进程不必为了删除文件而相互协商。不过,对于来自 Windows 系统的用户来说,这是意想不到的行为,因为通常不允许您删除正在使用的文件。
lsof 命令以 root 身份运行时,将显示所有打开的文件,并且会特别指示已删除的已删除文件:
# lsof 2>/dev/null | grep deleted
bootlogd 2024 root 1w REG 9,3 58 917506 /tmp/init.0W2ARi (deleted)
bootlogd 2024 root 2w REG 9,3 58 917506 /tmp/init.0W2ARi (deleted)
停止并重新启动有罪的进程,或者只是重新启动服务器应该可以解决此问题。
例如,如果删除的文件是已安装的文件系统映像,则内核也可以将其保持打开状态。在这种情况下,卸载文件系统或重新启动服务器应该可以解决问题。
就您而言,根据“缺失”空间的大小来判断,我会查找您用于设置 VPS 的文件的任何引用,例如您在安装后删除的 Centos DVD 映像。