2003-10-02

_ [Url] 第3回　ジャーナリングファイルシステムが保護する「情報」

信頼性が高いとされるジャーナリングファイルシステムだが、ジャーナルによって何が保護されるのかを理解していないと、とんでもない落とし穴にはまってしまう。今回は、ジャーナリングファイルシステムの総論とそのほかの各種技術について解説する。（編集局）

@IT. 検索しやすいようにとりあえずメモしておこう。

_ [url] 第4回　ext3とトランザクション処理

長い利用実績を誇るext2の互換ファイルシステムext3。このファイルシステムにはどのような特徴があるのか？ そしてどのようにジャーナリングを実現しているのか？ 今回はext3について解説する。（編集局）

次の記事。

JBD と /.journal

うーん Journaling Block Device (JBD) には触れられていないか……。 前にちょっと追い掛けて、果たして正しいのか確信する前にやめてしまったのだけど。

ともあれ前の調べたことメモしておこう。 大嘘を書いている可能性もあるので注意。

記事中に

ext3はジャーナルログの保存のために、デフォルトでルートパーティションに.journalというデータベースを保有している。後で紹介するが、複数のファイルシステムでこのデータベースを共有することもできる。

とあるが、ルートパーティションではなくてそのファイルシステムのルートの書き違いだろう。 また、共有は……本当に出来るのかな？　これについては後で。

まず最初に、/.journal ファイルが使われていたのは既に過去の話だ。 e2fsprogs の RELESE-NOTES には、

E2fsck will automatically relocate the ext3 journal from a visible file (i.e., /.journal) to an hidden inode if the filesystem has been opened read/write. This allows the users to add a journal while the filesystem is mounted, but the next time the system is rebooted, the journal file will disappear. This avoids problems with backups, stupid operators with superuser bits, etc.

とある。

元々 ext3 のジャーナル機構は Journaling Block Device (JBD) と言うシステムを 利用している。JBD はその説明に

((%bq "The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to add journaling capabilities on a block device. The ext3 filesystem code will inform the JBD of modifications it is performing (Call a transaction). the journal handle the transactions start and stop, and in case of crash, the journal can replayed the transactions to put the partition on a consistant state fastly. JBD can handle external journal on a block device.", "Journaling Block Device layer" %))

とあるとおり、ブロックデバイス上にジャーナル情報を保存する汎用APIらしい。 ジャーナルログの保存場所は ext3 ファイルシステムを作ったパーティションや 論理ボリューム内だけではなく、外部のブロックデバイスにも指定できる。

ディフォルトの外部デバイスを使わない方法では、ext3 ファイルシステム内に 予約された（使用中マークをつけた）i-nodeを確保し、ファイルシステムのマウント時に、 その i-node が割り当てたれた実際のブロックデバイス上の位置を割り出して ジャーナル領域として使う。

この予約された i-node は最初 /.journal と言うファイルに結びつけられていた （これは古い fsck によって削除されるのを避ける為ではないかと思うのだけどどうなんだろう？）。 が、ともあれ最近では RELEASE-NOTES にある通りファイル名へのリンクは切られている。

ext3 はジャーナル情報をファイルシステムレイヤ経由で保存する？

だからファイルシステムレベルのキャッシュとか遅延書き込みとかが効いて まともにて動かない──と言う話があったけど、 これは /.journal ファイルが存在していた事による誤解じゃないかと。

JBD に関しては

IBM developerWorks の アドバンスト・ファイルシステム・インプリメンター・ガイド: 第7回 でもほんのちょっとだけ出てきます。

external journal の共有？

２ページ目に

((%bq "■外部ジャーナルファイルの指定 別のデバイスのジャーナルファイルを利用する場合は、初めに外部デバイス側のジャーナルファイルを作成し、それを利用するデバイスを指定する。", "ext3関連コマンド", "http://www.atmarkit.co.jp/flinux/rensai/fs04/fs04b.html"%))

と書いてあるので、ext3 ファイルシステムが出来、その上ににジャーナル 「ファイル」が出来るのかと思ったが、そうではない。

mke2fs -O journal_dev /dev/hda5

とかやると /dev/hda5 全体がジャーナルログのために確保される。 普通に ext{2,3} のスーパーブロックは作られるみたいで、 dumpe2fs で情報を取ることは出来る。 見てみると分かるが Free blocks: 0, Free inodes: 0 になっている。 （ただし普通にファイルシステムを作るのと違って、スーパーブロックの バックアップは作られない。先頭のみ）

そして、

mke2fs -J device=/dev/hda5 /dev/hda4

これをやると /dev/hda4 にファイルシステムが作られ、 ジャーナルデバイスの /dev/hda5 側にそこをジャーナルログとして使っている ext3 ファイルシステムの UUID が書き込まれる。

確かに複数のファイルシステムを一つの journal device に結びつける 事は出来るみたいで、

mke2fs -O journal_dev /dev/sdb3 
mke2fs -J device=/dev/sdb3 /dev/sdb1
mke2fs -J device=/dev/sdb3 /dev/sdb2

と実行すると

[root@localhost root]# dumpe2fs /dev/sdb3 | tail -3
dumpe2fs 1.27 (8-Mar-2002)
Journal number of users:  2
Journal users:            9374d934-765b-4c9f-99fa-2e11b4c97d04
                        f1aaad3c-af37-415c-9e59-ff656712d4a9

と２カ所から使われていることになっている。

でも、

[root@localhost root]# mount -t ext3 /dev/sdb1 /mnt/sdb1 
EXT3-fs: External journal has more than one user (unsupported) - 2
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
     or too many mounted file systems

こんなエラーになってしまってマウントできない。 もしかして kernel が古い(2.4.18) からなのかな？

ext3 から ext2 への変換

確かに互換性がありますが、いきなり ext2 でマウントし直したりせずに、

tune2fs -O ^has_journal /dev/hdaX

で journal があるという情報を消してから

fsck.ext2 -f /dev/hdaX

と一応 fsck をかけた方が良いようです。

もし、journal 情報を消さずに

  • mount -t ext3
  • 電源断
  • mount -t ext2
  • 色々書く
  • umount
  • mount -t ext3

ってやるとどうなるんでしょう。ちゃんとやってくれるのかな

_ [url] 「物理的な音楽の小売りは終わる」／ほか

_ [comp] なんだか日記に書く量ではなくなってきました……

なんだか日記に書く量ではなくなってきました……

その資料を読む限り、基本的に "Journal ファイル" が ext2 上にあるから、まともにジャーナルログが記録されない、と言う話だと思うのですが。

でも、コードを適当に読んでみた限りでは、どうもジャーナルログを書くために ext2 を経由していると思えないのです。JBD の初期化をしている fs/jbd/journal.c を簡単に追い掛けて行くと

  • ext3 は journal に外部デバイスが指定されていないなら superblock に 書かれている journal inode を journal_init_inode に渡す
  • JDB の jounal_init_inode は、渡された inode から (ファイルシステム(VFS?)側の関数を呼んで) 物理デバイスとブロックサイズを割り出し、journal log のサイズを調べる。 最終的に bmap を呼び、物理デバイス上の位置を特定する
  • その得られたブロックのリストに対して JBD による journal を開始する

と言う感じに読めました。 ……ただ、ext3 の bmap が何か特殊なことをやっているようなんですが、 そこら辺まではちゃんと見れていません。それに私にまともな知識がないので、 思い切り外している可能性は結構あります。どうなんでしょう？

コメント (1)

hidetosi
http://www.dd.iij4u.or.jp/~okuyamak/Documents/NetworkFileSystem.Tune.htmlの4章が参考になります