ext4のボトルネック除去：I/Oバリアを解除せよ
あ、あけましておめでとうございます。
新年早々何を考えてか、部屋から一歩も出ずに引き篭もり正月なんぞを喜んで享受し、記事を更新している白烏です。
初詣？ 元旦は混むのでもう少し時間をおいてから行きます。神社の神様も、元旦に一度に願い事のトランザクション詰まれまくっても、一度に解決できないでしょうしね。
前回の記事で最後に書いたI/Oバリアの話です。
この話を説明するには、ディスクへのコミットと言う概念を理解する必要があります。
コミット(commit)というとDBを思い浮かべるのが恐らく一般的(え、一般じゃない？)だと思います。そのコミットと同じニュアンスであると理解していただいてかまいません。
ええ、大雑把な理解ですからその程度で今回は構いません。
※コミット：あるデータの一連的処理を恒久的なものにする
このコミットは、ディスク上でも行わなくてはなりません。
多くのジャーナリングファイルシステム(Journaling file system)では、ジャーナルという概念が非常に重要になっています。このジャーナルを利用するためにジャーナリングファイルシステムを採用しているわけですしね。
さて、このジャーナルをディスクに書くというのが実は問題になります。ディスクには通常、ライトキャッシュ(write cache)が実装されてます。このキャッシュの解決は、ディスクに一任されているわけだから大変だ。
多分の嘘を含んだ絵で説明しましょうか。
この図で描かれるように、データはライトキャッシュが一旦受け止めます。
ファイルを保存する場合は、ファイルに関するジャーナルを生成し、そのジャーナルが書き込まれた後にコミットされる必要があります。
でも、ライトキャッシュから本当にデータを保持しているエリアへの書き込み順序は、システムが臨んでいる通りになるとは限りません。キャッシュの解決は既に別のところに一任されてしまっているからです。
最終的に全部DISK上に書き込まれてしまえば問題はないのですが、ジャーナルの書き込みとコミットが逆転してしまい、更にその間でマシンの電源が落ちてしまったらどうなるでしょうか。
状態とジャーナルに記述された状態が不整合を起こしてしまいますね。
これを解決するには、必ず「ジャーナルを書き込む」→「書き込みが完了したのを確認してからコミットを行う」を守らせる他ありません。 その機能が、I/Oバリアと呼ばれる機能です。
ただ、ここまでの説明を読んでいただければ分かるように、I/Oバリアは重要だけどコストが掛かる仕組みです。実際に、性能を犠牲にする機能であると説明されています。
性能を犠牲にしているから「さあ外そう」と安易に考えてしまいがちですが、I/Oバリアはジャーナルの整合性のためには重要な機能です。
外すには、以下の条件がそろう必要があります。
- バリアを外すことのリスクを理解している
- マシンの電源断に備える仕組みを有している
リスクは今理解してもらえたと思っています。
電源断は、通常サーバであれば無停電電源装置(UPS)を使用する必要があります。 このUPSはとても高い。個人で買うとなると溜息と涙が出る程度に高い。
でも今回SSDを乗せたマシンは何だったでしょうか。
ええ、Netbookですね。ノートパソコンには、必ずと言って良い程にバッテリが搭載されています。バッテリが切れそうになり前に、ちゃんと通常手順でシャットダウン出来るのであれば、この条件は容易に満たせます。
と言うことで、 本題の設定の方へ。
今回も /etc/fstab を編集します。
このようになっている場合
#<file system> <mount point> <type> <options> <dump> <pass> UUID=hogehoge / ext4 discard,errors=remount-ro 0 1
このように編集します
#<file system> <mount point> <type> <options> <dump> <pass> UUID=hogehoge / ext4 barrier=0,discard,errors=remount-ro 0 1
この barrier=0 が、バリアを解除する意味合いになります。尚、デフォルトで1(有効)ですが、明示的に1を宣言することも可能です。
編集が終わったら保存して再起動してもらえれば、I/Oバリアが解除された状態でディスクがマウントされます。
保護機能を外しているのだと言うことは理解してください。
尚、これらのbarrierがどのように作用して、どのような結果をもたらすのかは、ベンチマークの結果を交えて次回の記事でお送りしたいと思います。
ではでは
