根分区显示2T已占满但实际仅用63GiB，如何排查缺失的1.8T空间？

你遇到的这个问题其实很典型，从你给出的lsof输出就能直接找到答案：那些标记为(deleted)的文件，就是吃掉你1.8T空间的元凶！

为什么会出现这种差异？ #

• df统计的是文件系统层面的已用空间，只要文件对应的磁盘块还没被系统回收，就算作占用空间；
• ncdu -x /扫描的是当前存在于文件系统目录结构中的可见文件，那些已经被删除但仍被进程持有的文件，因为已经不在目录树里了，所以ncdu扫不到，但磁盘空间还没被系统释放，这就导致了两者的巨大差异。

看你贴的lsof结果，比如/var/log/lightdm/lightdm.log (deleted)、/home/xxxx/somefile.swp (deleted)这些文件，虽然你已经删除（或者程序自动清理）了，但对应的进程还在运行，还握着这些文件的句柄，系统就不会回收它们占用的磁盘空间。

怎么解决？ #

第一步：确认已删除占用文件的总大小

先跑这个命令，计算所有这类文件的总占用量，看看是不是刚好接近1.8T：

sudo lsof -nP | grep '(deleted)' | awk '{sum += $7} END {print sum/1024/1024/1024 " GiB"}'

第二步：释放空间的几种方法

1. 重启对应的进程
   找到占用大文件的进程（比如你的结果里的lightdm、gvim、code-8b61这些），直接关闭重启它们，进程退出后，系统会自动释放这些文件的磁盘空间。比如：

   • 关掉VS Code再重新打开
   • 重启pulseaudio服务：sudo systemctl restart pulseaudio
   • 如果是lightdm相关的，可能需要重启桌面环境，或者直接重启机器（最彻底）

2. 不重启进程，直接释放空间
   如果你不想重启进程，可以通过进程的文件描述符清空文件内容。比如看lsof输出里的lightdm 3111 3122 gmain root 6w REG ... /var/log/lightdm/lightdm.log (deleted)，这里的6w是文件描述符（fd=6），进程ID是3111，那么可以执行：

   sudo cat /dev/null > /proc/3111/fd/6
   

   这样就能直接释放这个文件占用的空间，不用重启进程。不过要注意，有些进程可能依赖这个文件的状态，操作前最好确认不会影响服务运行。

3. 最彻底的方法：重启机器
   如果你嫌一个个找进程麻烦，直接重启系统，所有进程都会退出，系统会自动回收所有已删除但被占用的文件空间，重启后再用df /看看，空间应该就恢复正常了。

其他排查补充（以防万一） #

虽然你的情况已经指向了已删除文件，但如果上面的方法没用，可以再检查这个点：有没有其他挂载点覆盖了根分区下的大文件？比如之前你可能把某个大分区挂载到/var，后来卸载了，但/var目录下原来的大文件还留在根分区里。不过你用了ncdu -x /（-x表示不跨分区扫描），所以这个可能性很低，但可以用这个命令再确认下根分区里的超大文件：

sudo find / -xdev -type f -size +10G -print

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