私は最近、毎回約100〜200GBの一時ファイルを生成するプログラムを実行しています。現在、実行中は定期的にディスク容量が不足していますが、実際にはそうではありません。
私が実行すると、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
ご覧のとおり、〜912GBがあり、/
693Gを使用したことがわかります。しかし、これは事実ではありません。下の写真を見ると、500GBのみ使用したことが確認できます。
走ると手にsudo lsof +L1
入るhttps://pastebin.com/WD5qTEYW(表示されているファイルの中に興味深いものはありません。つまり、そのファイルのどれも、私が実行しているプログラムによって生成されたtmpファイルとは関係ありません。)
また、追加して再起動しようとしましたが、touch /forcefsck
何らかの理由で起動時にfsckが実行されないようです。また、同じ結果でgrub構成にfsckを追加しようとしましたが、実行されません。
>> 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"
ハードドライブはSamsung 970 EVO Plus 1 TB PCIe NVMe M.2 (2280) Internal Solid State Drive (SSD) (MZ-V7S1T0)
答え1
私は最近、毎回約100〜200GBの一時ファイルを生成するプログラムを実行しています。実行中にディスク容量が不足することが頻繁に発生します。
/dev/mapper/data-root 912G 693G 174G 81% /
174GBを使用できますが、最大200GBが必要なため、ディスク容量が不足します。スペースを作らなければなりません。
しかし、私は本当にそうではありません。
はい。数字が上にあります。
693Gを使っているそうですね。しかし、これは事実ではありません。下の写真を見ると、500GBのみ使用したことが確認できます。
いいえ、の数字はdf
正しいです。これ以上の事実はありません。
/root
スクリーンショットには読めないファイルの数は表示されないため、明らかにユーザーアカウントで読めるファイルのみがカウントされます。/lost+found
したがって、アカウントで読み取り可能なスペースは435 GB、読み取り不可能なスペースは約258 GBです。スペースを使用することが何であるかを知りたい場合は、管理者権限でナビゲートする必要があります。 GUIツールを管理者(sudo baobab
)として実行するか、以下を実行します。
sudo du -x -h / | sort -h >du.txt
他の合併症も発生する可能性があります(特に5%の余裕を持たなければなりません。つまり、ディスクを95%以上充填しないでください。)最初に、df
部分番号ではなく正しい番号(の番号)を信頼する必要があります。