web-dev-qa-db-ja.com

大きなファイルをたくさん削除した後、空き容量が大幅に増加します

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

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

同期も試みましたが、効果がありませんでした。

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

今日、ファイルシステムは、ビデオレコーダーソフトウェア、家族用のowncloudサーバー、およびこれまでになかったいくつかのサービスで常にビジー状態になっているため、簡単にマウント解除および再マウントすることはできません。そして、私は夜の3時に起きて、マウントを解除して再マウントするだけではしたくありません。

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

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

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

ファイルシステムは、ルート用に0％予約されて作成されました（mkfs -m 0）。による fsck -f（私はこれを常にアンマウントと再マウントの間に行っています）、ファイルシステムは破損しておらず、S.M.A.R.T.診断拡張テストによると、ハードウェアも問題ありません。

[編集]

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. ここで何が起きてるの？削除時にすぐにではなく、umountまたは遅延でスペースが解放されるのはなぜですか？
  2. アンマウントおよび再マウントせずに、スペースの解放をトリガーするために今できることはありますか？
ext4ext3
15
Markus N.

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

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

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

9
BillThor