兄弟，这情况真的够诡异的，我之前帮朋友排查过类似的磁盘占用“失踪”问题，先别慌，咱们一步步来分析可能的原因：

首先先把你排查的结果贴出来，方便大家更清楚问题：

# 根目录磁盘占用
cd /
sudo du -xhd1
4,0K    ./srv
2,5M    ./root
248K    ./tmp
304M    ./opt
6,3G    ./home
8,0K    ./media
18M ./etc
4,0K    ./mnt
16K ./lost+found
84K ./snap
4,0K    ./cdrom
6,7G    ./usr
475G    ./var
174M    ./boot
491G    .

# /var目录占用
cd var
sudo du -xhd1
454G    ./log
52K ./spool
153M    ./cache
92K ./tmp
29M ./crash
21G ./lib
176K    ./backups
4,0K    ./opt
4,0K    ./mail
4,0K    ./metrics
2,3M    ./snap
4,0K    ./local
475G    .

# /var/log目录占用
cd log
sudo du -xhd1
4,0K    ./gdm3
4,0K    ./openvpn
8,0K    ./hp
4,1G    ./journal
1,4M    ./installer
24K ./unattended-upgrades
76K ./cups
4,0K    ./speech-dispatcher
26M ./calico
20K ./postgresql
540K    ./apt
4,0K    ./private
32K ./letsencrypt
36K ./sysstat
444K    ./pods
4,0K    ./dist-upgrade
44K ./containers
455G    .

从上面的输出能明显看到，/var/log总占用455G，但所有子目录加起来才4G多，这中间的差距肯定是有“隐形”的占用，下面是几个最常见的排查方向：

• 被进程锁定的已删除文件：Linux里有个特性，如果一个文件被删除，但还有进程在打开它读写，那么磁盘空间不会被释放，du查不到这个文件（因为它已经不在目录结构里了），但df能看到空间被占用。你可以用这个命令找出这类文件：

  sudo lsof | grep deleted
  

  找到对应的进程后，不要直接kill重要进程（比如数据库、web服务），优先尝试优雅重启该服务；如果是无关紧要的进程，再考虑终止它，空间就会自动释放。

• 挂载点覆盖了大文件：比如之前/var/log下有个超大文件，后来你挂载了某个分区到/var/log的子目录（比如/var/log/journal），导致原来的大文件被挂载点覆盖，du遍历的时候看不到它，但实际还是占用磁盘空间。你可以先卸载相关挂载点（比如sudo umount /var/log/journal），然后再用du检查，看看是不是出现了之前被隐藏的大文件。

• 隐藏的超大文件：有时候可能存在以.开头的隐藏文件，du -xhd1默认不会单独列出来（只会算到.的总占用里）。你可以用这个命令查看/var/log下所有文件（包括隐藏文件）的大小：

  sudo ls -laSh /var/log/
  

  或者直接找大于10G的文件：

  sudo find /var/log -xdev -type f -size +10G
  

• 日志轮转配置失效：如果logrotate的配置出问题，比如某个服务的日志没有被按时轮转压缩，就会导致日志文件无限变大。你可以检查/etc/logrotate.conf和/etc/logrotate.d/下的各个服务配置，看看有没有遗漏或者错误。也可以手动强制执行一次日志轮转，看看能不能释放空间：

  sudo logrotate -f /etc/logrotate.conf
  

• 文件系统损坏：如果上面的方法都没用，那可能是文件系统出现了错误，导致磁盘空间计算异常。这种情况需要先卸载分区（或者进入单用户模式），然后执行文件系统检查：

  sudo fsck /dev/xxx  # 替换成/var所在的分区设备名，比如/dev/sda3
  

  注意：执行fsck前一定要备份重要数据，并且确保分区没有被挂载。

先试试上面前几个方法，大概率能找到问题所在，有进展可以再补充信息！

备注：内容来源于stack exchange，提问作者user20656733