ext3ファイルシステムにはデフラグは本当に要らないのか?

またLinuxの小ネタですが、どうも巷では

ext3・4ファイルシステムはNTFSと違ってフラグメントしないのでデフラグしなくてよい

といった話が出たり消えたりするようです（季節ものの話題）。

ファイルシステムがフラグメントすると何が悪いかというと、I/Oの数（いわゆるIOPS）が増えることと、ストレージ側のキャッシュ効率が悪くなることです。普通のストレージはSCSIコマンドに乗っけたデータを受け付けるわけですが、SCSIコマンドは「一定の連続したブロック」を処理します。40KBのデータが連続していればひとつのSCSIコマンドでカバーできますが、完全にフラグメントしていると(4KBブロックだとして)10回分のコマンド処理が必要になります。

SCSIコマンドのリファレンス（Seagate社）

ストレージ側のコントローラにもSCSIコマンドを処理するためのプロセッサが乗っていて、サーバーの方からやってくるSCSIコマンドを一生懸命処理しているので、これが増えるのは望ましくないわけです。あまり数が多いとストレージ側のプロセッサが処理しきれなくて、いわゆるコントローラのCPU使用率が上がった状態になってしまいます。

ストレージ側のキャッシュもブロック位置の局所性を期待したものとなるので、フラグメントされたファイルだとヒット率も必然的に下がります。

さて、結論を言うとext3・4はごく普通のファイルシステムなので、フラグメントはします。ファイルもフラグメントするし、空き領域もフラグメントします。だからといって、たとえば複数のプロセスが並列にI/Oを出すと、それぞれが順番にブロックを取っていくので片っ端からフラグメントしてしまうのかというとそういうことはなくて、できるだけ連続した領域が割り当たるように工夫されています。

ext3では、ブロックリザベーションという仕組みで、iノードに対して一定の領域のブロックを「予約（仮押さえ）」してくれます（デフォルトで8ブロック、最大で1027ブロック）。つまり、iノードを作ってデータを書いたら、その先の部分をそのファイル用に取り置きしておいて追加のデータが来ればそこお使えるようにする感じでしょうか。ディスク容量が僅少となってなかったりフラグメントが激しくなっていないうちは、連続領域が割り当てられることが期待できます。

ちなみに、（あまり変更の必要はないかもしれないですけど）このリザベーションの量は、ファイル単位でioctl(2)で変更することができます（ただし、一度iノードがメモリから落ちてしまうと設定が消えてしまうようですが）。

EXT3_IOC_GETRSVSZ
EXT3_IOC_SETRSVSZ

ext4だと、このあたりのリザベーションの仕組みはなくなっていて、かわりにdelayed allocation（遅延ブロック割り当て）でカバーされているようですが、これはこれでまた別の問題を引き起こすからなかなか難しいですね。