ディスクが徐々にいっぱいになりますが、目に見えるファイルサイズの変更はありません

df

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

その77％は昨日は60％でしたが、数日で100％になります。

私は今しばらくの間ファイルサイズを監視しています：

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

私は毎日（ほぼ）同じ数字を私に与えています。その14Gの合計は、ディスクサイズの半分未満です。残りはどこに行くのですか？

私のLinuxの知識はそれほど深くは行きません。

ここにファイルが表示されない可能性はありますか？他の方法でスペースを割り当てることは可能ですか？

ディスクスペースが目に見えて大きくなっている場合は、ファイルが削除されている可能性があります。Windowsでは、何かによって開かれたファイルを削除しようとすると、エラーが発生します。Linuxでは、ファイルは削除済みとしてマークされますが、データはアプリケーションが許可されるまで保持されます。場合によっては、これは自分でクリーンアップするためのきちんとした方法として使用できます -アプリケーションがクラッシュしても、一時ファイルのクリーンアップは妨げられません。

削除された、まだ使用されているファイルを見るには：

lsof -b 2>/dev/null | grep deleted

削除されたファイルが多数ある場合があります-それ自体は問題ではありません。削除された単一のファイルが大きくなるのは問題です。

再起動するとこれが修正されますが、再起動したくない場合は、関連するアプリケーション（lsof出力の最初の列）を確認し、適切なものを再起動するか閉じます。

次のようなものが表示された場合：

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

アプリケーションと削除されたファイルが同じ場合、おそらくアプリケーションがアップグレードされたことを意味します。大量のディスク使用の原因としてこれらを無視することができます（ただし、バグ修正が適用されるようにプログラムを再起動する必要があります）。

のファイル/dev/shmは共有メモリオブジェクトであり、ディスク上の多くのスペースを占有しません（せいぜいiノード番号）。これらは無視しても安全です。指定さvteXXXXXXれたファイルは、VTEベースのターミナルエミュレーター（GNOMEターミナル、ターミネーターなど）からのログファイルです。出力されるものがたくさんある（そしてたくさんのことを意味する）ターミナルウィンドウを開いている場合、これらは大きくなる可能性があります。

muruによる優れた答えに追加するには：

• dfはディスク上のサイズを示し、
• duはファイルコンテンツの合計サイズを示します。

たぶん、duでは見られないのは、多くの小さなファイルの出現です...（最後の列を見て、df -iiノード（つまり、ファイル）の数が残業時間を大幅に増やすかどうかを確認してください）

たとえば、1'000'000（1,000,000）個の小さな1バイトファイルがある場合、du合計1'000'000バイトとしてカウントされます。1Mb（...純粋主義者、うんざりしないでください）

ただし、ディスク上では、各ファイルは2つの要素で構成されています。

• 1つのiノード（ファイルのデータを指す）、およびそのiノード自体は16kb（！）
• また、各ファイルのデータ（=ファイルのコンテンツ）はディスクブロックに置かれ、それらのブロックには複数のファイルのデータを含めることはできません（通常...）。したがって、1バイトのデータは少なくとも1ブロックを占有します。

したがって、100万ファイルの1バイトファイルは1'000'000'000 * size_of_a_block、データ用の合計スペース1'000'000'000 * size_of_an_inodeとiノードのサイズを占有します。これは、100万の「1バイト」ファイルに対して数Gbのディスク使用量に相当します。

1024バイトのブロックがあり、さらに256バイトのiノードサイズがある場合、1'000'000ファイルはdu約1Mbとして報告されますが、ディスク上では約1.25Gbとしてカウントされます（図をdf参照）。（または、各iノードも1つの専用ディスクブロック上になければならない場合は2Gbでさえあります。それが当てはまるかどうかはわかりません）

/dev/vda1いっぱいになっている場合、JenkinsまたはDocker（またはその他）が原因である可能性があり、ログlsofを消去してそのサイズを設定するためにコマンドを使用する必要がある場合があります。