web-dev-qa-db-ja.com

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

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の知識はそれほど深くは行きません。

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

filesystemdisk-usage
16
nizzle

ディスクスペースが目に見えて大きくなっている場合は、ファイルが削除されている可能性があります。 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ターミナル、ターミネーターなど）からのログファイルです。 lotsで端末ウィンドウを開いている場合、これらのは大きくなる可能性があります（つまり、lots）出力されるもの。

28
muru

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

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

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

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

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

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

したがって、100万ファイルの1バイトファイルは、データ用に1'000'000'000 * size_of_a_block合計スペースに加えて、iノードのサイズの1'000'000'000 * size_of_an_inodeを占有します。 」ファイル。

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

3
Olivier Dulac

/dev/vda1がいっぱいになっている場合、それはJenkinsまたはDocker（またはその他）によって引き起こされている可能性があり、 を実行するにはlsofコマンドを使用する必要があるログを消去し、サイズを設定します 。

0
T.Todua