私のディスクスペースを何が食べていますか？
Linux Mint 14 Nadiaを実行しています。 Linuxパーティションには10Gがあります。システムが起動すると、duは80％の使用率を報告します。その後、使用率は100％に達するまでゆっくりと増加し、システムは使用できなくなります。 （それは日または週のオーダーで発生する可能性があります）。再起動後、使用率は80％にリセットされます。
何よりも奇妙なのは、duに変化がないことです。
これらのコマンドの出力を以下に示します（Windowsおよび外部ドライブのパーティションは省略されています）。
# --- Just after reboot ---
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.8G 7.3G 2.0G 80% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 428M 292K 428M 1% /dev
tmpfs 88M 1.3M 87M 2% /run
none 5.0M 0 5.0M 0% /run/lock
none 437M 288K 437M 1% /run/shm
none 100M 12K 100M 1% /run/user
$ Sudo du -x -d1 -h /
186M /opt
512M /var
11M /sbin
556K /root
1.3G /home
613M /lib
8.0K /media
4.6G /usr
16K /lost+found
111M /boot
39M /etc
4.0K /mnt
60K /tmp
9.1M /bin
4.0K /srv
7.3G / # <-- note this
# --- After some time ---
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.8G 9.1G 199M 98% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 428M 292K 428M 1% /dev
tmpfs 88M 1.3M 87M 2% /run
none 5.0M 0 5.0M 0% /run/lock
none 437M 27M 411M 7% /run/shm
none 100M 28K 100M 1% /run/user
$ Sudo du -x -d1 -h /
186M /opt
511M /var
11M /sbin
556K /root
1.4G /home
613M /lib
8.0K /media
4.6G /usr
16K /lost+found
111M /boot
39M /etc
4.0K /mnt
520K /tmp
9.1M /bin
4.0K /srv
7.3G / # <-- note this
（注：休止状態を使用しています。休止状態後も使用率は変わりません。再起動後は80％にリセットされます。）
スペースを食べるものを追跡するにはどうすればよいですか？
私は読んだ この質問 。私はまだ暗闇の中にいます。この動作の原因となっているプログラムを見つけるにはどうすればよいですか？
編集後：見つかりました。スペースは、dmesgによって表示されるカーネルログによって要求されます。私のマシンは1秒あたり5回の割合でエラーを生成するため、いっぱいになります。 （これは このバグ に関連しています。）同様の問題を抱える将来の読者に、duには見られないゆっくりとディスク容量を埋めてください-検索でdmesgを試すことを忘れないでください原因のため。
繰り返し実行
Sudo du -x -d1 -h /
（ディレクトリツリーの下に）スペースが消費されている場所が表示されます。それはおそらく、さらなる調査なしに、どのアプリケーションがそれを引き起こしているのかを説明しています。
非表示のファイル
duにこれらのファイルが表示されない場合は、ファイルが削除されている可能性があります。ファイル（またはその名前：ディレクトリ内のエントリ）は、ファイルがまだ使用されているときに削除できます。このファイルを指す有効なファイル記述子がある限り、それはボリューム上のスペースをカバーします（空のファイルでない場合...）。
cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0
これらのファイルはfindで見つけることができます：
find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n %l\n' 2>/dev/null
それはあなたの問題の原因となる単一の巨大なファイルまたは小さなファイルの束かもしれません。私のシステムには現在、約30個のそのようなファイルがあります（5つのプロセスのみに属します）。 ls -lはこれらのファイルのサイズを示していますが、findからこの値を取得することはできないようです。
プロセスを強制終了した後、スペースはファイルシステム（df）で再び使用可能になります。
のようなものを使う
lsof -s | grep deleted | sort -k 8
削除されたファイルを開いたままにしているプロセスを確認します。重要なフィールドは、2番目（PID）、8番目（最後から3番目、ファイルサイズ）です。
（重複する行に注意を払い、それらを2回カウントしないでください。PIDとファイルパス（最後のフィールド）またはiノード番号（2番目から最後のフィールド）を確認してください。）
その後、原因の可能性が高いプロセスを見つけた場合、その修正方法を確認できます。
find / -size +10000k -print0 | xargs -0 ls -l -h
これを使用して、/（root）から10MB +を超えていっぱいになっているものを再帰的に検索し、xargsのls -lを使用して詳細を表示します。 1000000（2つの追加のゼロ）を書き込むと、たとえば1GB +を取得できます。
du / -h --max-depth=1 | sort -h
Duを使用することもできます。手動で掘り下げてください。
これが起こるときはいつでも、私は常に特定のサブディレクトリから私の焦点を開始します。ほとんどのLinuxディストリビューションが準拠するFHS構造は、これを念頭に置いて設計されています。
最初に/varを調べ、次に/homeを調べます。
$ Sudo du -x -d1 -h /var | sort -hr`
$ Sudo du -x -d1 -h /home | sort -hr`
これらの場所のいずれかにあるサブディレクトリに焦点を絞ることもできます。そこを調べ尽くしたら、私は通常/rootに移動し、最後に/の残りのサブディレクトリに移動します。
Red Hatベースのディストリビューションの場合、yumが更新の実行に使用するキャッシュが大量のスペースを消費している可能性があります。このコマンドを使用して、それをクリアできます。
$ yum clean packages
aptを使用する他のディストリビューションでも、apt-get cleanと同様のことができます。
また、/ディレクトリの上部でこのコマンドを実行します。この場所は、迷惑なログファイルのソースになることがあります。
$ ls -la /
ドットファイルには特に注意してください。たとえば、.blahという名前のもの。
timeshiftは私のディスクを食べていました。
Sudo timeshift -delete--all
50Gbを回復しました。
ほぼ同じ状況です。
私の場合、理由はVMwareでした。同じマシン上の他のVMwareの1つで、ディスク領域を消費しました。そのため、ディスク領域の使用率は100％でした。
近隣のVMwareから大きなファイルを削除した後、それは正しく機能しています。