☰

磁碟已滿但找不到已使用空間（Ubuntu）

tag-icon • tag-icon ubuntu disk-usage
磁碟已滿但找不到已使用空間（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將顯示佔用的磁碟空間（計算完整的索引節點空間），而du將顯示新增的檔案大小（即，僅顯示這些檔案的內容，而不是包含此內容的索引節點所佔用的空間）
  • 另一種可能性：安裝的檔案系統可能隱藏了一些大型檔案。即，某些檔案可能位於已安裝的檔案系統「下方」（也許您將大量大檔案放入/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哪裡...）/

相關內容