比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。
I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序（物理ディスクに反映される順番）をまもらせる仕組みといえます。
ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。
そもそも、急な電源断でもファイルシステムの不整合が起こらないために、ext3やext4では「ジャーナル」と呼ばれるデータの「書き込み記録」が用意されています。ですのでこのジャーナルが正しく記録されていれば、ファイルシステムの不整合が起こらないはずなのですが、ハードディスクにキャッシュメモリが内蔵される事で、正しくジャーナルを書き出せない可能性が出てしまうのです。
ハードディスク装置にキャッシュが内蔵されると、書き込みでfsync()を実行しても、実際のディスクではなくキャッシュに書き込んだ時点でfsync()が返ってしまいます。
キャッシュに溜まったデータはいずれ実際のディスクに反映されますが、この反映途中で電源断が発生すると、物理ディスクには意図しない部分の（OSからの書き込みとは異なる順序で）データが反映されてしまう可能性があるわけです。
ファイルシステムのジャーナルは、ジャーナルが対応しているデータが反映される「前」に必ずディスクに書き込まれる必要がありますが、上のような電源断があると、データの方だけディスクに書き込まれて、ジャーナルのデータがロストしてしまう可能性があります。そうするとファイルシステムが不整合になってしまいますね。
※この説明はかなり端折って書いてしまっています。詳しい考え方については下記のblogエントリが分かりやすいです。
-
Understanding Linux block IO barriers | Lifting the Earth using Linux
この不整合を防ぐために、デフォルトでバリアが有効になっているわけですが、これがどの程度速度に影響があるかはアプリケーションによって異なります。例えばRHEL 6のマニュアルには以下のような記述があります。
-
Chapter 20. Write Barriers
Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower.
fsync()を何度も実行したり、ファイルの作成と削除を多数行う場合は遅くなるとありますね。I/Oバリアを有効にすると、fsync()の前後にH/Wキャッシュへのフラッシュ命令が発行されるようになりますので、その分処理に時間がかかるようになります。
RDBの性能への影響がどの程度あるかについては、データを持っていないので良くわからないのですが、並行で書き出せば早くすむはずの書き出し処理（DB2だとバッファープールに溜まったダーティーなデータを表スペースに書きだす処理）を、順序を守って書き出す事になるわけですから、性能へのペナルティはあると考えるべきでしょうね。
例えばDB2 10.1+Redhat Enterprise Linux 6の場合について、DB2/Linuxのwikiには以下のような記載があります。
-
Red Hat Enterprise Linux (RHEL) 6 - DB2 10.1 - Information Management
You are recommended to disable I/O barrier at mount time using the -o nobarrier option for mount on ext3 and ext4 file systems.
このようにI/Oバリアをオフにする事が推奨されていますね。
DB2 10+SLES 11にも同じことが書かれていますので、こういった新しいディストリビューションでDB2を使う場合はI/Oバリアをオフにすると良いようです。
もちろんデータに不整合が発生してはいけないのですが、おそらくCOMMITした際にはDB2はトランザクションログをハードウェアのキャッシュまで含めてフラッシュしているため、ファイルシステム側で考慮してもらわなくても問題ないのでしょう。（DB2の挙動を確認したわけではないので、想像なのですが）
ext4でI/Oバリアをオフにするには、mount時にオプションbarrier=0かnobarrierを指定します（
どちらでも良いようですが、RHELのマニュアルにはnobarrierと書かれていますし、SLESのマニュアルにはbarrier=0と書かれています）。
その他、XFSやreiserfsにもバリア機能が用意されています。
おそらくこのI/OバリアをOFFにしたほうが良いというのは、他の多くのRDBでも共通だと思われます。
例えばMySQLについては、（MySQLで超有名な)松信さんのプレゼン資料で"xfsはI/Oバリアがデフォルトで有効なので消すこと"と書かれています。(p.23)
-
Linux/DB Tuning (DevSumi2010, Japanese)
