磁盘已满但找不到已用空间(Ubuntu)

磁盘已满但找不到已用空间(Ubuntu)

我有一个带有 30GB 驱动器的小型英特尔 NUC。我的问题是该驱动器已满,但找不到原因。

df报告以下内容

Filesystem     1K-blocks      Used Available Use% Mounted on
udev              899412         0    899412   0% /dev
tmpfs             189284      2676    186608   2% /run
/dev/sda2       28414508  27751116         0 100% /
tmpfs             946404         0    946404   0% /dev/shm
tmpfs               5120         4      5116   1% /run/lock
tmpfs             946404         0    946404   0% /sys/fs/cgroup
/dev/loop0           128       128         0 100% /snap/bare/5
/dev/loop1         56832     56832         0 100% /snap/core18/2128
/dev/loop2         56832     56832         0 100% /snap/core18/2246
tmpfs             946404         0    946404   0% /tmp
/dev/loop3        314880    314880         0 100% /snap/makemkv/381
/dev/loop4         66688     66688         0 100% /snap/gtk-common-themes/1515
/dev/loop5         63360     63360         0 100% /snap/core20/1169
/dev/loop6         63360     63360         0 100% /snap/core20/1081
/dev/loop7         33280     33280         0 100% /snap/snapd/13270
/dev/loop8        317184    317184         0 100% /snap/makemkv/385
/dev/loop9         33280     33280         0 100% /snap/snapd/13640
/dev/loop10        66816     66816         0 100% /snap/gtk-common-themes/1519
/dev/sda1         306584      5356    301228   2% /boot/efi
tmpfs             189280         4    189276   1% /run/user/1000

计算得出大约 14GB 的已用磁盘空间。

跑步sudo lsof | grep REG | grep -v "stat: No such file or directory" | grep -v DEL | awk '{if ($NF=="(deleted)") {x=3;y=1} else {x=2;y=0}; {print $(NF-x) " " $(NF-y) } }' | sort -n -u | numfmt --field=1 --to=iec | tail -10

给了我一个列表,其中包含一些重要的流程:

5,5M  /usr/lib/php/20190902/fileinfo.so
6,8M  /usr/lib/jellyfin/bin/libcoreclr.so
8,0M  /var/log/journal/6296b00d07874d0a9533eed0efb81840/user-1000.journal
8,2M  /usr/lib/jellyfin/bin/System.Private.Xml.dll
8,3M  /usr/lib/locale/locale-archive
8,9M  /usr/lib/jellyfin/bin/System.Private.CoreLib.dll
10M  /usr/lib/udev/hwdb.bin
24M  /snap/snapd/13640/usr/lib/snapd/snapd
27M  /usr/lib/x86_64-linux-gnu/libicudata.so.66.1
64M  /memfd:pulseaudio

运行后sudo du -sh / --exclude=disks --total总共给我带来了 13GB 的空间。

所以,基本上我不知道如何找出系统报告为填充我的驱动器的某个地方丢失的~16GB。

该报告实际上就是这样运行的

cd ~/ && touch example && echo "FooBar" > example
-bash: echo: write error: No space left on device

提前谢谢你,而且,任何想法都是一个好主意,基本上有一个目前无法使用的设备,我的选择已经很少了(基本上是干净的重新安装/为不应该使用更多的设备购买更大的SSD超过 20GB)

答案1

尝试找到填充“/”分区的东西的一些可能性:

  • lsof -nP +L1 # 应列出所有已删除(未链接)但仍由进程打开的文件,因此仍占用 dist
  • 另请参阅该答案:https://unix.stackexchange.com/a/68532/27616其中提供了一些额外的信息和可以尝试的事情
  • 另一种可能性:检查(使用 df -ih /)该文件系统中是否没有“数百万”小文件/:每个文件至少占用“少量”磁盘(通常是因为它至少占用 1 个 inode,其大小取决于文件大小和文件系统)。这可以加起来......如果占用的最小磁盘空间是 512 字节,则拥有 100 万个每个 1 字节的文件仍将占用 5.12 亿字节而不是 100 万字节。df将显示占用的磁盘空间(计算完整的 inode 空间),而du将显示添加的文件大小(即,仅显示这些文件的内容,而不是包含此内容的 inode 占用的空间)
  • 另一种可能性:安装的文件系统可能隐藏了一些大文件。即,某些文件可能位于已安装的文件系统“下方”(也许您将大量大文件放入/tmp 目录(文件系统中的那个/,然后用作挂载点来挂载/tmp文件系统)?如果您在/tmp文件系统未安装时将内容放入其中,则可能会发生这种情况。要检查这一点,您可以在 Linux 中/以只读方式重新挂载(使用自由循环设备)(例如:将其挂载在/mnt/readonlyroot/挂载点下),然后使用 浏览该内容du -hs /mnt/readonlyroot,并与du -hxs /#进行比较-x,防止 du 下降到另一个文件系统安装在下面/,例如/tmp文件系统)。
    • 命令在某个挂载点下以只读方式挂载(第二次)/:你可以(从我的记忆中......我现在无法在Linux上检查):
      • mkdir -p /mnt/rootreadonly/创建目录挂载点(具有讽刺意味的是,它将位于“/”文件系统内部......)
      • mount -o loop -o ro /dev/sda2 /mnt/rootreadonly(为了使“/”文件系统显示为只读。我在此处指定 sda2,因为您显示“/”文件系统位于问题中的“/dev/sda2”中。阅读此答案的其他人应该首先检查输出查看他们的文件系统来自mount哪里...)/

相关内容