ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々

先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると：

1. ファイルシステム上に書き込み可能な状態でファイルをオープンする。
2. 一定ペースで、ファイルへ Buffered I/O で書き込み。
3. ファイルをクローズする。

このとき、特定条件下のXFSでは、（２）の段階では全然フラッシュが発生せず、（３）の段階でまとまったフラッシュが発生するのだそうです。

ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション（ミドルウェア）からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linuxでは5秒ごとにメモリ上のダーティーなページがファイルシステム上に反映されるというのですが、今回はそのような動作になっていないようです。

またお話を聞いていると、

• Ext3 でフォーマットされた、ハードディスク上の / では現象が発生しない
• XFSでフォーマットされた、 ioDrive 上の /data (仮) では現象が発生する
• ioDrive + VSL2, ioDrive2 + VSL3 のどちらでも発生する
  ※ VSL = Virtual Storage Layer; ioMemoryシリーズ用のドライバソフトウェア

とのことです。

Linuxカーネルの配布元、リリース、利用するファイルシステム、利用する ioDrive シリーズとドライバやファームウェアのバージョンなどによって食いあわせ的な問題も経験したことがあります。

ただ、今回の場合、ここまでの情報より、そもそもブロックデバイスへのI/Oがきていない（であろう）こと、 VSL2 と VSL3 で問題が再現するということから、個人的には、カーネル側（Linuxのブロックレイヤやファイルシステムドライバ）の挙動なのではないか、と切り分けました。

以下が、今回相談いただいた問題の再現例です（検証は ESXi 上の CentOS 5 で行っており、また ioDrive は利用していません）。



ioDrive を使っているユーザーさんは、こういう細かな問題も乗り越えながら日々運用していらっしゃるんだなあ、と思うと、頭が下がる想いです。


ところで、私は ioDrive をはじめとする ioMemory のベンダーである Fusion-io に務めていますが、いまのポジションでは、このような"カーネル依存"やOSのデザイン上のご相談なども度々いただきます。OS/ミドルウェアなどの動作上の問題：ioMemory の動作上の問題の割合＝４：１、もしくはもっと前者の割合が多いように感じています。

Fusion-io のエンジニアをやっていると、ioMemory をいじっているよりも、関連するソフトウェアを弄っていることのほうが多かったりします。もともと ioMemory を使うユーザーは「ioMemoryの性能を限界まで使いたい」とはちっとも思っていなくて、「 ioMemory を使ってシステムを快適にしたい」「運用を改善したい」という動機であることが多いはずです。

幸いにも、この会社が持っている ioMemory シリーズは、半導体ストレージとしては業界トップクラスの性能ですから、デバイスの性能自体にあまりナーバスになる必要性はありません。お恥ずかしながら、実際、私は ioMemory のIOPSスペックをひとつひとつ憶えていませんし、する必要もありません。 ioMemory のスペック値を憶えても CPU やメモリのパフォーマンス、システムボードの設計で実際に利用できる範囲は下ブレも上ブレ（！）もしますし、トラブルシュートでデバイス側に執着しても解決するものは少なく、システム上でソフトウェアがどう動いているかに注目しなければ、大抵の問題は解決しないと思います。

 私自身がプラスアルファの活動に費やせる時間には限りがありますし、自分の”守備範囲”はお世辞にもそれほど広くないので、限界があります。ですが、自分ができる範囲で、 ioMemory ユーザーにはデバイスだけでなく、関連する”ソフトウェア側の落とし穴”もうまく乗り越えて、確信をもって使ってもらえるようなれば、と思っています。