Archive for the ‘Ext4’ tag
Ext4, ついに安定版リリース
12/24にLinux kernel 2.6.28がリリースされました。このリリースの目玉としてExt4実装があります。Ext4はExt3と互換性を保ちながらも多くの改良がなされたものになっているようです。kernelnewbies.orgに記載されているNew featureを意訳してまとめてみました。
互換性
既存のExt3ファイルシステムはExt4にリフォーマットすることなく移行可能。具体的には該当ボリュームをReadOnlyでマウントしていくつかコマンド叩くだけでOK。
より大きなファイルシステムサイズ、ファイルサイズのサポート
Ext3からExt4ではそれぞれの制限は以下の通り。
ファイルシステムサイズ：16TB -> 1EB (エクサバイト）
ファイルサイズ：2TB -> 16TB
ちなみにEBとは、 (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB）なぐらい大きい。
無制限のサブディレクトリ数
Ext3からExt4でのサブディレクトリ制限は以下の通り。
320000 -> 無制限
エクステントによる大きなファイル操作の効率化
これまでは「ファイル」のデータはディスクという円盤のいろんなところに「ブロック」としてバラバラと格納されていたが、このような大きなファイルを物理的に連続したブロック（これがエクステント）として格納するこで、特にdelete等の操作を効率化する。
マルチブロックアロケーションによる内部ブロック割当処理の効率化
これまでは連続してデータを書き込む際、ディスク上の空いているブロックを1ブロックずつ探してきて割り当てる、という処理になっていたがこれをブロックアロケータ自身に必要合計ブロック数を認識させることで、単一コールで複数ブロックを割り当てれるようになりオーバヘッドが緩和される。
遅延アロケーションによる性能改善
これまではデータが書き込まれるやいなやブロック割当てを実行していたが、これをしばらく遅らせることで連続データ書き込み時のブロック割当て処理をまとめて行えるようになりその分オーバヘッドが軽減できると同時にフラグメンテーションも抑えることができる。これは前述のエクステント、マルチブロックアロケーションと連携して相乗効果を発揮する仕組みになっている。
Fast fsck
fsckが対象とするinodeを全inodeから使用したinodeのみに絞り込むことでfsckにかかる所要時間を大幅に短縮する（環境によって1/2〜1/20程度に）。ただしinodeを使用したか未使用かを判断するにはfsckをその前後で走らせる必要があることに注意。
Journal checksum
ジャーナルの完全性を高めるためにチェックサム機構を取り入れた。これによって信頼性だけでなく、既存Ext3の2フェーズコミットをシングルコミットとすることができ性能の改善も期待できる（環境によっては20%程度向上の可能性も）。
オンライン・デフラグメンテーション
今回のkernelリリース（2.6.28）ではまだ実装していないが、将来のリリースではこのオンラインでのデフラグ機構が盛り込まれる予定。e4defragと呼ばれるツールで実装する。
inode関連の変更
ディレクトリ作成時にあらかじめinodeを作成しておくことにより、ファイル作成時のinode作成処理にかかるオーバヘッドを軽減する。
タイムスタンプを秒 -> ナノ秒に拡張。
上記にともないinodeのサイズを128バイトから256バイトに変更。
先行ディスク領域割当
アプリケーションがあらかじめ使用予定の領域を確保しておける仕組み。3つの利点があり、1つ目はアプリケーションが独自にこれを行おうとすると、あらかじめ領域を0で埋め尽くさなければ行けないがこれを回避できる。2つ目として、領域をあらかじめ一括して確保できるのでフラグメンテーションを抑制できる。3つ目として、必要な領域がなくなってしまうということがなくなることが挙げられる。
バリア機能がデフォルト有効に
ハードウェアが内部write-cacheをもって独自のキャッシュフラッシュ処理（順番入れ替え）を行うような場合でもジャーナルが確実にデータコミット前にディスクに書き込まれるように制御する。性能を若干犠牲にしてデータの完全性を高めるための選択。ただしマウント時に”mount -o barrier=0″とすることでこのバリアを無効にできる。
フーム、Ext4ではエクステント、マルチブロックアロケーション、遅延割当等を連携させて論理的に連続するデータを物理的にも連続させて管理やI/Oの効率化を計るところにかなり注力しているようです。素晴らしいー。