デベロッパー:Linux How-To 2005年10月07日 01:02 更新
icon ext3ファイルシステムの動作

 Red Hat Linux 7.2でサポートされたext3ファイルシステムは、従来のext2ファイルシステムのうち、将来の予約用のメタデータ部分を使ってジャーナリング機能を実装している。そのためファイルシステムの構造は、ext2ファイルシステムと変わらず、ext2ファイルシステムとしてマウントし、利用することもできる。

 ext3ファイルシステムでは、ディスクに書き込もうとしたときにちょうどFig.2に示したようにいったんその処理をフックし、その手順をジャーナリングの領域に書き込むという形式になっている。そしてジャーナリングの対象となったデータは、5秒おきにディスクへの書き込み処理がされる(言い換えると、ディスクへの書き込みが5秒間遅延することになる)。

 ext3ファイルシステムは、どのような操作をジャーナリングの対象とするのかによって、次の3つのモードがサポートされている。

●journal
 メタデータと実際のデータの両者をジャーナリングの対象とする。不正なシャットダウン後に、一部のデータが不正に残ってしまうようなことはなく、もっとも整合性が高くなるモード。反面、すべての操作がジャーナリングの対象となるから、ディスクへの書き込み速度は遅くなる。

●ordered
 メタデータのみをジャーナリングの対象とする。そして実際のデータは、メタデータを書き込む前にディスク上に書き込むように、書き込み順序を保証する。このモードでは、メタデータが不正なデータを指し示してしまうことがない。そしてメタデータはジャーナリングされるから、不正なシャットダウン後にもメタデータは正しく修復される。よって事実上、ほとんどの整合性を保てる。ただし、メタデータの書き込みは、実際のデータを書き込むまで待たされることになるから、ディスクへの書き込み速度は、やや遅くなる。

●writeback
 メタデータのみをジャーナリングの対象とし、実際のデータの書き込みはジャーナリングの対象としない。このモードでは、メタデータの整合性は保てるが、実際のデータ部分が正しいことは保証しない。すなわち不正なシャットダウン後に、ファイルの一部のゴミが残る可能性がある。反面、ディスクへの書き込みは任意のタイミングで行われるため、orderedモードに比べて高速である。

 デフォルトのモードは、ほとんどの整合性をとることができるorderedモードだ。このモードはバランスがとれていて、事実上、問題なく不整合を回避できる。

モードを変更する

 上記に述べた3つのモードは、マウントする際にオプションを指定することで変更できる。mountコマンドでマウントする場合には、次のようにして指定する。

mount -t ext3 -o data=ジャーナルモード デバイス名 マウント先ディレクトリ

 “-o data=ジャーナルモード”の部分は省略することもできる。省略した場合には、デフォルトであるorderedが使われる。

 たとえばwritebackモードで/dev/sdb1デバイスを/mntにマウントする場合には、次のようにする。

# mount -t ext3 -o data=writeback /dev/sdb1 /mnt

 ext3ファイルシステムがマウントされるときには、dmesgに記述されるので、dmesgコマンドを使えば、どのようにマウントされたのかを知ることができる。

# dmesg
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.8, 25 Aug 2001 on sd(8,17), internal journal
EXT3-fs: mounted filesystem with writeback data mode.

 これらのジャーナルモードは、/etc/fstabファイルに記述することでも設定できる。/etc/fstabファイルに記述する場合には、次のようにする。

/dev/sdb1 /mnt ext3 defaults,data=ジャーナルモード 0 0

 /etc/fstabファイルに記述する場合も“data=ジャーナルモード”の部分は省略でき、省略した場合には、orderedモードでマウントされる。

One Point!上記の/etc/fstabの例において、第5番目のフィールド(dumpコマンドがバックアップする間隔)、第6番目のフィールド(fsckがチェックするマウント回数)は、ともに0を指定してあるが、他の値を指定しても、もちろんかまわない。ただし第6番目のフィールドが示すfsckがチェックするマウント回数については、後に補足する。

icon モードの違いでアクセス速度は違うのか?

 さてこれらの3種類のジャーナルモードの速度差はどの程度あるのか気になるところだろう。そこで簡単なベンチマークテストをしてみた。

 Linuxで動作するファイルシステムのベンチマークテストのプログラムとしては、bonnie++IOzoneなどがある。今回は比較的テストが簡単な、bonnie++を使ってみた。

 今回は、ext3ファイルシステムをjournal、ordered、writebackのそれぞれのモードでマウントし、bonnie++を使って50MBのファイルを読み書きするベンチマークをとった。またext3ファイルシステムは、ext2ファイルシステムとしてマウントできることから、ext2ファイルシステムとしてマウントしたときとの差がどの程度になるのかという点も合わせて計測した。

 なお今回のベンチマークは、手持ちのハードウェアの都合で、実機ではなく、仮想環境を作り出すVMWare上で、Red Hat Linux 7.2を動作させたときの環境になっている。そのためRead時の速度など、一部の値が正しく出ていない。しかし目的は、それぞれのモードの相対的な速度差がどのぐらいであるのかを調べたいだけなので、実機でなくても問題ないだろう。

 実際にベンチマークをとったときの結果は、Table 1に示す。Table 1は、ext3ファイルシステムをそれぞれのジャーナルモードで/mntディレクトリにマウントしたとき、次のコマンドを実行したときの結果である。

# bonnie++ -d /mnt -s50 -r4 -u0

Table 1■ベンチマーク結果

Sequential Output

Per Chr
(K/sec)
3529
14165
12155
16850
Block
(K/sec)
4156
63435
66460
Rewrite
(K/sec)
4172

12961
7090

Sequential Input

Per Chr
(K/sec)
19804
19884
20506
20573
Block
(K/sec)




Random

Seeks
(/sec)
964.9
1576
1540
1575

Sequential Create

Create
(/sec)
1363
1397
1413
2356
Read
(/sec)



Delete
(/sec)
16304
17454
18221

Random Create

Create
(/sec)
1522
1463
1499
2650
Read
(/sec)



Delete
(/sec)
4033
3880
3956
6622

journalモード orderedモード
writebackモード ext2モード

 Table1は、数値が大きいほど高速、小さいほど低速であることを示す。

 この結果から分かるように、journalモードの書き込み速度は極めて低速だ。実際ベンチマークを計測した感想として、体感的にも、この差は明らかなものである。journalモードは、他のモードに比べて書き込み速度が4分の1程度にまで落ちるため、できるだけ使わないほうがよいだろう。

 一方、orderedモードとwritebackモードとの差だが、この差は思ったよりも小さい。すでに説明したように、不正なシャットダウンが生じたときに、orderedモードでは、実際のデータ部分の不整合がほとんどないのに対し、writebackモードではデータ部分の不整合の可能性があることから、この程度の速度差であるならば、安全性重視という意味においてorderedモードを使うほうがよいだろう。

One Point! ただし、Table 1は、ベンチマークというただ1つのプログラムがディスクへのアクセスをしている場合であり、複数のプロセスが同時にディスクにアクセスした場合には、orderedモードとwritebackモードとの速度差が開く可能性がある。なぜならばorderedモードでは、メタデータの書き込みが実際のデータの書き込み後まで遅延されるから、複数のプロセスが同時にディスクにアクセスすると、いくつかのプロセスが処理を待たされる可能性があるためだ。

 ところでext2としてマウントしたときとの差だが、結果を見るとわかるように、メタデータを大幅に操作するファイルの作成や削除といった速度差は、2倍程度の差が出てきている(表下段のSequential CreateおよびRandom Createの部分)。すなわちジャーナリングによる速度低下は、比較的大きいということを意味する。

 しかし一度作ったファイルを読み書きする場合(表上段のSequential Output、Sequential Input、Random)には、速度差は大きくないことから、頻繁にファイルを作るアプリケーションを動かすのでもない限り、パフォーマンスの影響はほとんどないと言えるだろう。

 あえて言うならば、何かの処理をテンポラリファイルに一旦書きだして、それから処理するアプリケーションは、この影響を大きく受けることになる。よってたとえば、/usr/tmp/tmpディレクトリなど一時的なファイルが頻繁に作られ、かつ、データの整合性があまり重要でない場所は、ext3ファイルシステムにはしないほうがよいといえる(もっともパフォーマンスを重視するならば、これらのディレクトリはRAMディスクに配置することが多いだろう)。

icon ジャーナリングのカスタマイズ

 ところでext3ファイルシステムをmke2fsコマンドで作成するときには、ジャーナリングのいくつかのカスタマイズが可能だ。

 前回ext3ファイルシステムを作成するには、mke2fsコマンドを使ったのち、tune2fsコマンドでext3ファイルシステムに変更すると書いたが、これは正しくない。

 正しくは、次のようにmke2fsコマンドに-jオプションを伴うだけでよい。ここでお詫びし、訂正させていただく(もちろんtune2fsコマンドで変換しても、手順が増えるだけであり、実際に何か影響があるというわけではない)。

# mke2fs -j フォーマットしたいブロックデバイス名

 mke2fsコマンドで-jオプションを使ってext3ファイルシステムを構築する際には、さらに-Jオプションを使ってジャーナリングのサイズを変更したり、別の場所にジャーナリングのファイルを設置したりすることもできる。利用できるオプションは、次の2つのいずれかだ(両方を同時に設定することはできない)。

-Jsize=サイズ
 ジャーナリングのサイズを設定する。メガバイト単位。ファイルシステムのブロックサイズの1024倍以上、102400倍以下の範囲で指定する。

-Jdevice=外部ジャーナルデバイス
 ジャーナリングのファイルに別のデバイスファイルを利用する。利用する外部ジャーナルデバイスは、あらかじめ“mke2fs -O journal_dev 外部ジャーナルデバイス”として作成しておく必要がある。

 いずれのオプションもうまく設定すれば、パフォーマンスの向上に貢献する。ext3ファイルシステムは、5秒ごとにジャーナリングのデータをディスクに反映するため、ジャーナリングのサイズは、5秒間分のデータを格納できるだけの領域が必要ということになる。

 しかし不用意な設定は逆にパフォーマンスを低下させる結果にもなりかねないし、5秒間分がどれだけのデータとなるのかはディスクの速度やI/Oデバイスの速度などハードウェアの構成によっても異なるから、どの設定が一番パフォーマンスが良いと一概にいえるわけでもない。よって本稿では、ジャーナリングのカスタマイズについての説明は割愛する。

PREV 2/3 NEXT