Linux Blue

ext3 journalメモ

Journaling the Linux ext2fs Filesystemのメモ(1)

Designing a new filesystem for Linux

クラッシュ後のリカバリ時間を短縮することが目的である。
journalingは早いリカバリが実行できる、なぜなら常に私たちは
ディスク上で不具合が発生する可能性があるすべてのデータを
journal内に記録されていることを知ることができるから
結果として、journalをスキャンして、すべてのコミットされたデータを
main FS領域にコピーしもどすことでFSリカバリが実施される。
journalはFSよりもずっと小さいのでとても早く完了する

Journalingは別の利点もある。journaling FSは短期間のデータを新しい場所(
ディスク上の独立した永続したデータ、メタデータ)に保持するという点で従来のFSとは異なる。
これによって、FSは永続したデータを特定の方法で格納することを命令しないので、
ext2などはディスク上のフォーマットを変更することなく、journalingバージョンとして
利用することが可能となる。

Anatomy of a transaction

jouranled FSのもっともなコンセプトはFSの単一更新に相当する"transaction"である。
１つのtransactionはアプリからのリクエストにより単一FSから作成される結果であり、
それ(transaction)はリクエストからのすべてのメタデータ変更の結果を含む。
例えばファイルへのwriteはディスク上のinodeのtimestampとwriteによりファイルが
拡張される場合は、block mapping情報の更新となる。quota情報(空きブロック、未使用
bitmap)も新しくブロックが割り当てられたら更新され、それらすべてはtransactionに
記録される。

transactionには私たちが気づかなければならない隠れた他のオペレーションがある。
transactionはまたFSに存在する内容を読み込み、transaction間で整頓するということだ。
ディスク上のブロックを修正したtransactionは新しいデータを読み、
何を読んだかに基づきディスクを更新するtransactionの後はコミットできない。
2つのtransactionが同じブロックを書き戻さない場合においてさえ、依存関係は存在する：
想像してください、ディレクトリのとあるブロックからfilenameを消しているtransactionがあり、
もう一方のtransactionが他のブロックに同じfilenameを追加しようとしている。
2つのオペレーションはそれらが書くブロックを重複していないかもしれないが、
2つ目のオペーレーションは最初のが成功したときだけ、有効となる(これに違反すると
重複したディレクトリエントリとなる)

Merging transactions

jouranled FSではjournalingは複雑なtransactionからatomicなcommitを保証する
標準的なメカニズムである、databaseの世界からくるたくさんの専門用語とテクノロジーが利用されている.