多数の大きなファイルを削除した後、大きな遅延で空き領域が増加します

昨日、ホーム/メディアサーバー上の71 GBのファイルを削除しました。
前の
空き容量：117 GB 後の空き容量：126 GB

したがって、71 GBの追加の空き領域がある代わりに、9 GBしかありませんでした。開いているファイルがないことを再確認し、実際に71 GBを削除し、空き領域が9 GBだけ増加したことを確認しました。

私も同期しようとしましたが、効果はありませんでした。

これが起こるのは初めてではありません。確かに、私は何年も時々この行動を見てきました。最初はext3で、今はext4で。
これが発生した場合、ファイルシステムをアンマウントしてから再マウントすることにより、空きスペースを再利用できます。これらの場合、アンマウントにはほとんど時間がかからず、最大2分かかります。

最近では、ビデオレコーダーソフトウェア、家族用の独自のクラウドサーバー、およびこれまで持っていなかったいくつかのサービスが常時使用されているため、ファイルシステムを簡単にアンマウントおよび再マウントすることはできません。そして、アンマウントと再マウントのためだけに夜の3時に起きたくありません。

いいえ、サービスのいずれかが再開不可能な長時間実行タスクを実行するため、「at」ユーティリティは機能しません。したがって、シャットダウンできる適切な瞬間、つまりタスクが完了した瞬間を見つけるために手動状態チェックが必要です。

しかし、今朝、スペースが一晩解放されたことに気付きました。ある種のクリーンアップが行われたかのように見えますが、これはアンマウント時に追加の時間がかかるのと同じことかもしれません。

これまでのところ、大量のデータを削除する場合にのみこの動作に気付きました。一方、それが定期的に発生するかどうかはわかりませんが、その差は気づかないほど小さいです。

ファイルシステムは、ルート（mkfs -m 0）用に予約された0％で作成されました。よるとfsck -f、ファイルシステムが破損していない（私はこれ常にアンマウントと再マウントの間にやっている）、およびテストを拡張SMART診断によると、ハードウェアもOKです。

[編集]

tune2fs 1.42 (29-Nov-2011)  
Filesystem volume name:   bigdata  
Last mounted on:          /bigdata  
Filesystem UUID:          6aebd17a-e064-41dc-9c68-c9a3acbe4f66  
Filesystem magic number:  0xEF53  
Filesystem revision #:    1 (dynamic)  
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize  
Filesystem flags:         signed_directory_hash   
Default mount options:    user_xattr acl  
Filesystem state:         clean  
Errors behavior:          Continue  
Filesystem OS type:       Linux  
Inode count:              121413632  
Block count:              485645568  
Reserved block count:     0  
Free blocks:              29081276  
Free inodes:              121382378  
First block:              0  
Block size:               4096  
Fragment size:            4096  
Reserved GDT blocks:      908  
Blocks per group:         32768  
Fragments per group:      32768  
Inodes per group:         8192  
Inode blocks per group:   512  
Flex block group size:    16  
Filesystem created:       Tue Dec 25 23:42:35 2012  
Last mount time:          Fri Jan  3 17:37:36 2014  
Last write time:          Fri Jan  3 17:37:36 2014  
Mount count:              37  
Maximum mount count:      -1  
Last checked:             Thu Apr 18 17:03:40 2013  
Check interval:           0 (<none>)  
Lifetime writes:          14 TB  
Reserved blocks uid:      0 (user root)  
Reserved blocks gid:      0 (group root)  
First inode:              11  
Inode size:           256  
Required extra isize:     28  
Desired extra isize:      28  
Journal inode:            8  
Default directory hash:   half_md4  
Directory Hash Seed:      be2b977e-5127-4843-9123-fe33b6d7b573  
Journal backup:           inode blocks  

[/編集]

だからここに私の2つの質問があります：

1. ここで何が起きてるの？削除時にすぐにではなく、アンマウント時または遅延で空き領域が解放されるのはなぜですか？
2. アンマウントおよび再マウントせずに、現在スペースを解放するためにできることはありますか？

相互作用する可能性がある2つの要因があります。

• Windowsとは異なり、開いているファイルを削除できます。ストリーミングされている映画を削除すると、ディレクトリから削除されますが、ストリーミングプログラムが閉じるまでファイルとして存在します。ストリーミングソフトウェアが終了すると、スペースが解放されます。このfuser -mコマンドを使用して、開いているファイルがあるプロセスのプロセスIDを見つけることができます。一部のプログラムは、ファイルの処理が完了してもすぐには閉じない場合があります。

• これらは両方ともジャーナルされたファイルシステムです。変更はジャーナルに書き込まれ、コミットされます。変更がコミットされるまでに時間がかかる場合があります。多くの場合、オペレーティングシステムはディスクの変更をキャッシュし、定期的にディスクへの変更のみをコミットします。syncコマンドを実行すると、保留中の変更がディスクにフラッシュされます。このsyncオプションを使用してディスクをマウントすると、ディスクへの速度は向上しますが、ディスクはより強力に機能します。