# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 7.4G 7.0G 0 100% /
none 498M 160K 498M 1% /dev
none 500M 0 500M 0% /dev/shm
none 500M 92K 500M 1% /var/run
none 500M 0 500M 0% /var/lock
none 500M 0 500M 0% /lib/init/rw
/dev/sda3 917G 305G 566G 36% /home
这令人困惑，原因有两个：1.）df表示已挂载/ dev / sda1 /处的容量为7.4 GB，其中仅使用7.0 GB的容量，但报告/已满100％；和2.）我可以在/上创建文件，因此显然还有剩余空间。
可能相关的是目录/ www是指向/ home / www的符号链接，该目录位于另一个分区上（/ dev / sda3，安装在/ home）。
有人可以提供建议吗？服务器似乎可以正常运行，但是我想确保分区表，文件系统或其他可能不会导致稍后爆破（或爆炸）的问题。
#1 楼
进程可能打开了一个较大的文件，此文件此后已被删除。您必须终止该过程以释放空间。您也许可以使用lsof来识别该过程。在Linux上，lsof知道已删除但打开的文件，并在lsof的输出中将其标记为（已删除）。可以使用
sudo lsof +L1 进行检查。
评论
为我解决了这个谜。我从uwsgi中删除了一个大日志文件，而没有重新启动服务。当查询df -ah时，我的磁盘已满，但是du -sh /告诉我应该有可用空间。经过retart uwsgi之后，我得到了很多可用空间！
–法比奥·蒙特福斯科洛（Fabio Montefuscolo）
14-10-15在16:03
我有40G的日志被困在一片混乱中，而lsof + L1使我有了X射线视线，以查看发生了什么事情；-)我要做的就是重启服务。
– PJ Brunet
18年5月7日，0：18
我注意到这种情况经常发生是因为自定义日志记录与logrotate一起添加到给定的服务配置中。例如，我使用Unbound（在Ubuntu下）。默认记录为syslog。但是，我有我自己使用的日志文件。通过logrotate旋转。对于Unbound，logrotate需要logrotate文件中的unbound-control log_reopen，以便释放旧的（已删除）打开的日志。您也可以选择仅重新启动服务。参考：lists.nlnetlabs.nl/pipermail/unbound-users/2019年7月/…
– bshea
20年6月10日在15:43
#2 楼
在文件系统已装满以防止严重问题的情况下，保留5％（默认）的文件系统。您的文件系统已满。由于有5％的缓冲区，因此不会发生灾难性事件-允许root用户使用该安全缓冲区，并且在您的设置中，非root用户没有理由写入该文件系统。作为非root用户运行但需要管理该文件系统中文件的守护程序，事情将会中断。
named是一种常见的此类守护程序。另一个是ntpd。评论
为何您的磁盘已满，但7G确实没有那么多空间。您似乎也将所有内容都转储到一个分区/文件系统（/）下。通常认为这是一件坏事（因为如果事情变得一团糟/填满了，世界结束了），但是Linux发行版仍然坚持这样做，因为它“更简单”。我将从在/ var（尤其是/ var / log）中查找巨大的日志文件开始。 du -hs /（以root身份）将帮助您找到最大的目录，并可能会指出需要清除的内容。
–voretaq7
2011年9月27日20:14在
#3 楼
您可能没有inode。使用以下命令检查inode的使用情况：df -i
#4 楼
大多数Linux文件系统保留5％的空间，仅供root用户使用。您可以使用例如
dumpe2fs /dev/sda1 | grep -i reserved
看到此内容。您可以使用：
tune2fs -m 0 /dev/sda1
在大多数情况下，服务器似乎可以继续正常工作-假设所有进程都以“ root”身份运行。
#5 楼
除了已经提出的原因之外，在某些情况下还可能是：在现有数据已充满的文件夹“上方”装载了另一个磁盘
du将计算已安装磁盘的大小，并且df将显示已实际使用的解决方案：（如果可能）卸载所有非根磁盘，然后再次使用
du -md 1检查该大小。通过将隐藏文件夹移动到其他位置或挂载到其他位置来修复情况。 评论
您如何找到df以外的挂载点？
– Hogan
2015年9月4日13:48在
@Hogan：也许调用“ mount”或“ cat / etc / fstab”会有所帮助？
– Robert Lujo
2015年9月7日于10:32
#6 楼
我遇到了这个问题，但由于在这里找到一些线索，删除各种大文件并不能改善情况（不知道5％的缓冲区）感到困惑，从根目录走到最大的目录通过重复执行以下操作而显示：-
du -sh */
直到我进入一个包含一些绝对大量日志的Web服务器日志文件的目录，我将其截短了。
:>lighttpd.error.log
df -h突然减少到48％！
评论
那应该以“ ...然后我设置日志轮换”结束。
– Hayalci
2012年12月3日17:02
hayalci：发现logrotation指向错误的目录。
– zzapper
2012年12月18日上午10:08
#7 楼
df -h将数值取整。甚至将百分比四舍五入。忽略-h，您会看到细微的差异。哦。 ext3及其派生文件为这个有问题的星座保留了一个百分比（默认为5％）给文件系统。如果您的根文件系统真的很满（剩余0字节），则无法引导系统。因此保留部分可以防止这种情况。
评论
也可能是他的可用i节点用完了。运行“ df -i”以获取inode的使用情况。
–安德鲁·凯斯（Andrew Case）
2011-09-24 21:52：
他没有提供磁盘已满的信息。他只认为磁盘已满。没有错误的100％已用空间仅是“几乎已满”。
– mailq
2011年9月24日在22:32
#8 楼
我做了几个库的大更新，并且有很多不必要的库和临时文件，因此我使用以下命令释放“ /”文件夹中的空间：apt-get install -f
sudo apt-get clean
并为空你的垃圾
评论
这是减少磁盘使用情况的合理一般建议，但并未解决df为什么说磁盘未满时为何已满的问题。
–安德鲁·舒尔曼（Andrew Schulman）
18年2月6日在14:51
#9 楼
如果您在/dev/shm上空间不足，想知道为什么（鉴于实际使用的空间（df -shc /dev/shm）比/dev/shm分配的大小小得多）？ lsof可以帮助：$ sudo lsof -s +L1 | awk '{print " "" "" "}' | grep 'dev/shm' | grep "^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"
7931428864 1133806 roel /dev/shm/1600335920/subreducer/2/data/ibtmp1
12710576128 1133806 roel /dev/shm/1600335920/subreducer/2/tmp/#sql-temptable-114cee-8-e18.MAD
4173332480 1352445 roel /dev/shm/1600335920/subreducer/1/data/ibtmp1
13040484352 1352445 roel /dev/shm/1600335920/subreducer/1/tmp/#sql-temptable-14a2fd-8-eb3.MAD
9670602752 2298724 roel /dev/shm/1600338626/subreducer/2/tmp/#sql-temptable-231364-8-d2e.MAD
第一个文件消耗〜7.9GB，第二个文件消耗约12.7GB，等等。正则表达式可以存储1GB以上的文件。您可以根据需要调整正则表达式。
原因可能是文件上存在死进程。
df -h不会显示此问题； Filesystem Size Used Avail Use% Mounted on
tmpfs 90G 90G 508K 100% /dev/shm
$ du -shc | grep total
46G total
您可以看到90G <> 46G偏移。在上面的文件中。
然后，杀死上面输出第二列中列出的PID（kill -9 PID）。
$ kill -9 1133806
结果：
Filesystem Size Used Avail Use% Mounted on
tmpfs 90G 72G 19G 80% /dev/shm
好，空间很干净。
用这种方式而不是像
sudo lsof +L1 | grep '(deleted)' | grep 'dev/shm' | awk '{print }' | sudo xargs kill -9这样的方式做事的原因是，底层处理可能仍在工作。如果您确信/不是，那么根据您的情况，该命令是一个可能的选择。它将杀死所有打开“已删除”文件的进程。评论
优化的命令：sudo lsof -s + L1 | awk'{print $ 7“” $ 2“” $ 3“” $ 10}'| grep'dev / shm'| grep -E“ ^ [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] | ^ [3-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0- 9]“ | awk'{print $ 2}'| xargs kill -9 2> / dev / null：杀死所有死文件> 300MB打开的进程
– Roel Van de Paar
20-09-18在6:10
#10 楼
检查/ lost + found，我有一个系统（centos 7），/ lost + found中的某些文件占用了所有空间#11 楼
如果您的分区是btrfs，则可能会有一个子卷占用空间。一个btrfs文件系统可以有许多子卷，只有其中一个是挂载的。您可以使用btrfs subvolume list <dir>列出所有子卷，并使用btrfs subvolume delete <dir>/<subvolume>删除所有子卷。确保不删除默认情况下已安装的目录。
评论
感谢所有有用的答案。我无法以普通用户身份创建文件，因此看来这是防止灾难发生的5％缓冲区。现在，我只需要弄清楚为什么磁盘已满（我有点担心会发生恶意事件，因为没有一个日志文件占用那么多空间，没有安装太多软件，只是一个简单的LAMP服务器） ...我要看的第一位是/ tmp。另一种可能性是您已删除了正在运行的程序所要保留的文件。我认为您可以运行'lsof | grep已删除”作为root来找到那些。