磁盘空间丢失
我最近运行了一个程序，每次创建大约100到200 of的临时文件。当它运行时，我现在经常没有磁盘space...but，我真的没有。
当我运行df -h时，我得到：
Filesystem Size Used Avail Use% Mounted on
udev 32G 0 32G 0% /dev
tmpfs 6.3G 2.9M 6.3G 1% /run
/dev/mapper/data-root 912G 693G 174G 81% /
tmpfs 32G 178M 32G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/loop2 163M 163M 0 100% /snap/chromium/1362
/dev/loop1 241M 241M 0 100% /snap/chromium/1373
/dev/nvme1n1p1 467M 228M 205M 53% /boot
/dev/loop4 56M 56M 0 100% /snap/core18/1932
/dev/loop0 374M 374M 0 100% /snap/anbox/186
/dev/loop5 98M 98M 0 100% /snap/core/10126
/dev/loop6 98M 98M 0 100% /snap/core/10185
/dev/loop7 147M 147M 0 100% /snap/code/47
/dev/loop3 143M 143M 0 100% /snap/code/48
/dev/loop8 166M 166M 0 100% /snap/electron-mail/26
/dev/loop9 61M 61M 0 100% /snap/gmail-desktop/16
/dev/loop10 55M 55M 0 100% /snap/gtk-common-themes/1502
/dev/loop11 93M 93M 0 100% /snap/insomnia/105
/dev/loop12 93M 93M 0 100% /snap/insomnia/109
/dev/loop13 177M 177M 0 100% /snap/postman/127
/dev/loop14 11M 11M 0 100% /snap/helm/302
/dev/loop16 92M 92M 0 100% /snap/go/6633
/dev/loop15 141M 141M 0 100% /snap/slack/30
/dev/loop17 92M 92M 0 100% /snap/go/6439
/dev/loop18 174M 174M 0 100% /snap/postman/128
/dev/loop19 113M 113M 0 100% /snap/gmail-desktop/12
/dev/loop20 163M 163M 0 100% /snap/gnome-3-28-1804/145
/dev/loop21 170M 170M 0 100% /snap/spotify/42
/dev/loop22 164M 164M 0 100% /snap/spotify/41
/dev/loop23 9.9M 9.9M 0 100% /snap/helm/292
/dev/loop24 138M 138M 0 100% /snap/slack/29
/dev/loop25 9.7M 9.7M 0 100% /snap/kubectl/1634
/dev/loop26 168M 168M 0 100% /snap/electron-mail/27
/dev/loop27 56M 56M 0 100% /snap/core18/1885
/dev/loop28 9.7M 9.7M 0 100% /snap/kubectl/1647
/dev/loop29 63M 63M 0 100% /snap/gtk-common-themes/1506
/dev/loop30 162M 162M 0 100% /snap/gnome-3-28-1804/128
tmpfs 6.3G 24K 6.3G 1% /run/user/120
tmpfs 6.3G 124K 6.3G 1% /run/user/1001
/dev/sda1 932G 664G 268G 72% /media/work/WD Elements SE 25FE正如您所看到的，我有~912‘s的/，这说明我已经使用了693 G。但事实并非如此。参见下面，显示我几乎没有使用500‘m
当我运行sudo lsof +L1时，我得到了https://pastebin.com/WD5qTEYW (列出的任何文件看起来都不有趣，也就是说，没有一个文件与我正在运行的程序创建的tmp文件相关)。
我也尝试过添加touch /forcefsck和重新启动，看起来fsck没有在引导上运行，不管出于什么原因。我还尝试将fsck添加到grub配置中，结果相同，它没有运行：
>> sudo tune2fs -l /dev/mapper/data-root|grep check
Last checked: Sun Nov 24 23:35:00 2019所以，在谷歌上搜索了一遍又一遍之后，我已经没有想法了。有人能弄清楚这是怎么回事吗？
这是我的操作系统信息。
NAME="Pop!_OS"
VERSION="20.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 20.04 LTS"HDD是一个Samsung 970 EVO Plus 1 TB PCIe NVMe M.2 (2280) Internal Solid State Drive (SSD) (MZ-V7S1T0)
回答 1
Unix & Linux用户
发布于 2020-11-03 09:37:03
我最近运行了一个程序，每次创建大约100到200 of的临时文件。当它运行时，我现在经常耗尽磁盘空间./dev/mapper/data-root 912G 693G 174G 81%
您有174 of的免费，但您需要高达200 of，所以您将耗尽磁盘空间。你得腾出地方来。
但我真的不是。
是的，你是。数字在上面。
意思是我用了693克。但事实并非如此。参见下面，显示我几乎没有使用500‘m
不，df的数字是准确的。没有比这更真实的了。
该屏幕截图显然只计算用户帐户中可读的文件，因为它没有显示一个无法读取的/root和/lost+found的数字。因此，您有435 go的帐户可读性，加上~258 go，这不是。如果您想知道什么是使用该空间，您需要深入了解管理员的权利。以管理员身份运行该GUI工具(sudo baobab)或运行
sudo du -x -h / | sort -h >du.txt其他并发症是可能的。 (特别是，您应该确保有5%的空白，即不要将磁盘填充到95%以上)，但是首先您需要信任正确的数字(来自df的数字)，而不是部分数字。
https://unix.stackexchange.com/questions/617756
复制相似问题
腾讯云开发者
