私はこのシナリオを別のコンピュータで何度も実行しました。あなたが私のような状況に直面することを保証することはできませんが、試してみる価値があると思います。

Veracryptと実際には関係のない2つの異なる質問があるようです。これだけコンテナファイルシステムの場合。

1. ディスクがいっぱいです。一部のファイルを削除すると、ディスクはいっぱいのままです。

2. ディスクそうしないでください。満ちる。

1. ディスクがいっぱいです。

ケース（1）はディスクを再マウントして再起動したため、削除されたファイルや説明されていないスペースには依存しません。これにより、削除されたオープンファイルが削除され、必要に応じてfsckが強制されます。

1.1何かを使い続けるディスクがいっぱいです。

もしそうなら、私たちには2つの解決策があります。一つは一部の既存のファイルに追加された内容はまだディスクに書き込まれています。（これは通常私のログファイルで発生します）。プロセスに書き込む必要がある20MBのバックログがありますが、ディスクがいっぱいで書き込めずに15MBのファイルを削除したとします。空き容量はすぐに再充填されます。これを確認する唯一の実用的な方法は、ディスクアカウントを実行し（他のデバイス上のファイルについて）、一部のファイルをls -laR削除してスペースを解放し、アカウントを再実行してから、2つのアカウントを比較することです。もちろん、2番目のファイルの一部のファイル（削除されたファイル）は消えましたが、他のいくつかのファイルも表示されたり、サイズが大きくなったことがわかります。

アカウントに開いているファイルのみを使用してこれを行うことができ、はるかに高速ですが、作成、入力、閉じられたlsofファイルが失われる可能性があります。

du -sk /mnt/disk/*/*/* > /tmp/before.txtたとえば、ディスクマウントポイントから最大3つのフォルダまで、すべてのフォルダのスペースを一覧表示することでこれを実行できます。これにより、サイズが大きくなったフォルダをすばやく消去できます。

1.2 ディスク確かに5％ルート予約のため、フル

2番目の可能性はファイルマネージャです。ルート予約スペースが正しく考慮されていません。。すべてではありませんが、ほとんどのLinuxファイルシステム予約一部のスペース（通常5％）はルート操作に使用され、いくつかの重要なパフォーマンスを向上させます。ルート起動操作でディスクがいっぱいになり、ルート以外のユーザーが残りの使用率が95％以上の一部のファイルを削除すると、ルート以外のユーザーはディスクが完全にいっぱいになっています。

以下を使用して、ファイルシステム全体と空き容量を確認できます。

tune2fs -l /dev/mapper/yourcryptdevicename

5％から1％に変更できます。

tune2fs -m 1 /dev/mapper/yourcryptdevicename

これにより、root以外のユーザーに残っている4％の空き容量が「再び表示されます」。

2. ディスクがいっぱいになってはいけません。

これは、500 GBのディスクに400 GBのファイルを挿入して埋める場合にのみ適用されます。差が 5% 未満の場合は理由 1.1 の影響なので、別途の説明なくこの方法で解決できます。

それ以外の場合、ディスク容量はデフォルトのブロック単位の倍数（4Kの可能性があります）として割り当てられます。これが発生すると、6Kファイルには2つのブロックが必要になります。これを作成すると、ディスク上の8Kの空き容量が失われます。これは時々呼び出されます。空きスペース平均は、ブロックサイズの半分に保持しているファイル数を掛けた値に等しくなります。

したがって、ラップトップからNASにソースツリーとライブラリツリーを同期させると、ラップトップには2Kブロック、NASには4Kブロック、つまり49Gbがあります。実際に使用1,797,479個のファイルがありますが、実行するとdu -sk --apparent-size44GBが得られます。 49GBは、実際には小さなファイルが多くの空き容量を占めるのを防ぐためのext4ファイルシステムのいくつかのトリックのおかげです。これらのトリックのないNASでは、最初からブロックが2倍になり、同じ44GBファイルが56GBを占めます。 SSD全体の価値を拡張すると、おそらく880GBのファイルがあるでしょう。1TB SSDドライブには適していません。。

これが真であることを確認するには、次のように実行します。

tune2fs -l /dev/yourpartition | grep "Block size:"

une2fs出力には、何が起こっているのかを確認するのに役立つ追加情報があります。たとえば、同期している2つのディスクの出力を比較し、特定のファイルを削除してから同じディスクの出力を比較します。

Inode count:              365985792
Block count:              1463919616
Free blocks:              72775504
Free inodes:              176130892

以下から取得した情報Linuxのdfファイルが削除後に正しい空き領域が表示されない、他の回答、Google検索結果、経験と組み合わせられます。

多数のコメント作成者は回答の半分しか提供できません。lsof |grep deleted影響を受けたファイルのみがリストされていますが、上記のIgnacioの言葉を引用すると、次のようになります。

ファイル名を削除しても、実際にファイルが削除されるわけではありません。一部の他のプロセスがファイルを開いたままにしてファイルが削除されるのを防ぎます。ファイルを解放するには、プロセスを再起動または終了します。

使用：

lsof +L1 削除されたファイルを使用してすべてのプロセスを一覧表示します（コメントに基づいてこれを行いましたが、コメントではこれを行う理由はわかりません）。lsofは略語ですファイル記述子リストを開く。ここで重要な言葉は記述子。削除されたファイルを開いたままにしたプロセスを終了するには、ファイル記述子が必要です。これを使用してkill - 15 PIDプロセスを終了できます（PIDは上記の省略記号と共に出力にリストする必要があります）。 [参照：いつ-9プロセスを終了してはいけませんか？?] または、次のように開いているファイル記述子を終了できます。

1. cd /proc/PID/fd：PIDは楕円の中に数字でリストされます。コマンドのPIDをこの数字に置き換えます。 fdは略語ですファイル記述子
2. procコメント作成者が提供したコマンドのバリアントを使用して、ファイルシステムの正しいPIDブランチにあることを確認してください。ls -l |grep deleted
3. これで問題は、stderrとstdoutを次にリダイレクトする>/dev/null 2>&1ことです。(deleted)2>&1空のデバイス。また見なさい:パイプの出力を> / dev / nullにリダイレクトする方法dev/null詳細な説明とリダイレクト。

一部の読者は、最初のリダイレクト演算子の左側に何も記録されていない理由を尋ねるかもしれません。私はファイルディスクリプタディレクトリにあるので、ファイルディスクリプタは左引数であると仮定します。

私はveracryptレイヤーがディスク容量の問題に関連していないと思います。 Veracryptは、ファイルシステムについて何も知らないブロック階層です。 Ext4はブロックデバイスの上に位置するファイルシステムです。ディスク領域を回復しないと、ファイルシステムの問題です。

ブロックサイズ以外の考慮事項（他の回答で議論）は、スパースファイルとは別にコピーされるハードリンクファイルです。両方ともフラグによって管理されますrsync。どちらも選択したフラグによって無視されます。次の2つのコマンドのディスク使用量を比較することでこれを確認できます。

du -hsx /media/veracrypt1
du -hsxl --apparent-size /media/veracrypt1

リンクした質問から、システム全体のバックアップについて話しました。この場合/devと一般的に/tmp。しかし、ここではディレクトリパスを使用しているので、ここではそのパスを使い続けます。

rsync -axHS /media/veracrypt1/ /media/veracrypt2

メモ:

1. スパースフラグは既存のファイルをスパースファイルに置き換えません。これらのファイルを直接処理するか、最初に削除する必要があります。
2. 同様に、rsync同じですがまだハードリンクされていないファイルはすべてハードリンクされません。
3. 元のコマンドでソースディレクトリパスサフィックスを追加する/media/veracrypt2/veracrypt1と、/最初にsourceというサブディレクトリを作成せずにターゲットに直接コピーを実行できます。