Linuxディスクがいっぱいになるのに、ファイルの合計が大幅に少なくなるのはどうしてですか？
dfは、16Gパーティションを100％で報告します。ルート上のduは、ファイル内の1Gについて報告します。すべてのディスクスペースはどこに行きましたか？
ファイルはマウントポイントで非表示にできます。
（スケジュールされたプログラム（バックアップ）は、メンテナンスのためにセカンダリボリュームをオフラインにして、失敗するのではなく、そのディレクトリ構造を喜んで再作成している間に実行されている必要があります。）
Dougが説明する無駄なスペースの問題 に加えて、一部のファイルシステムには、合計で限られた数のiノード（一意のファイルID）があり、それらが作成されると、新しいファイルを作成する方法がありません。 df -iを使用して、iノードのどこに立っているかを確認します。
さらに、ext[23]ファイルシステム（およびその他？）がディスクの一部をスーパーユーザーに予約することも可能です。通常、これはほんの数パーセントですが（5は古いシステムでは一般的です）、それよりはるかに高く設定できます。ここでtune2fsを-mオプションとともに使用したいと思います（MacOSおよびおそらく他のUNIXではこれをtunefsと呼びます）。
リンクされていない古いファイルを開いた状態でプログラムを実行している可能性があります。これらのファイルは、これらのプログラムが閉じるまでディスクに保存されますが、ファイルシステムツリーからはリンクされません。
これは、そのようなファイルを削除できないWindowsの動作とは異なることに注意してください。
非常に小さなファイルが多数ありますか？ Linux（およびほとんどのオペレーティングシステム）は、ブロックサイズのチャンク（たとえば4k）でファイルを書き込み、すべてのファイルはそのサイズの倍数を使用します。たとえば、121バイトのファイルがある場合でも、ディスクでは4096バイトが使用されます。そのブロックの残りのスペースは本質的に「無駄」です。
私はこれとまったく同じ問題を抱えていました。バックアップドライブの同期を実行した後、プライマリブートディスクがいっぱいになるという問題がありました。
>rsync -avxHAXW /media/backup1 /media/backup2
この同期の後、私のプライマリディスクがいっぱいになりました....それは私を困惑させました。バックアップではなく、誤ってファイルをブートディスクにコピーしていたことが判明しました2。間違いを修正し、プライマリディスク上の大容量ファイルを削除して、rsyncを再実行しました。バックアップディスクをアンマウントして再マウントした後でも、ブートディスクの容量が不足していました。ブートディスク上の大きなファイルをクリーンアップしてみました。
>find . -type f -print0 | xargs -0 du -s | sort -n | tail -25 | cut -f2 | xargs -I{} du -sh {}
不要になった大きなファイルを削除しました。また、ゴミ箱を空にするようにしました。
>empty-trash
そのすべての作業の後...ディスクはまだいっぱいです。マシンをリブートすることにしました。再起動後、ブートディスクパーティションが100％フルから10％フルになりました。 rsyncプロセスは、ディスクリソースを保持しているバックグラウンドで実行し続けている必要があるようです。このアドバイスをするのは嫌いですが、すべてのディスククリーンアップを実行した後、マシンを再起動して、データにぶら下がっているバックグラウンドプロセスをすべて強制終了し、ディスクが実際に解放されないようにする必要がある場合があります。