死んだはずのソフトウェアに対して昨日2つのコメントをもらった.
1. Transparent Migrationについて
Linuxストレージを運用する際には, ブロックストレージをLVMの管理下に置く場合ある. この時大抵はLinearデバイスを使うわけだが, LinearデバイスからWriteboostデバイスへの移行を透過的に(上位を一旦剥がすなどを必要なしに)行う. この技術はenhanceIOでは行われているようなのでWriteboostでやることがユーザを奪うことに繋がるならばやってもいいと思っている. (あちらのソフトウェアは間違いなく死んだはずだが, ライトブーストが出るまでは一番良いものだったため根強いファンがいる) 実装量が多いので2.2.7からはドロップしたが, 今回+1がついたので2.3ではやろうかなと思っている. +5までついたら確実にやる.
2. ネイティブ4KBセクタへの対応
Mad Scientistであられる報告者(https://www.linkedin.com/in/slicer/)によると, 4KBセクタでフォーマットしたNVMeデバイスをキャッシュに使ったところ, superblock headerからのリードが失敗したということ. この人がどういう動機でライトブーストを使おうとしたのかは知らないが, この種のフィードバックは本当にありがたい. また, ソースコードを実験的に書き換えて動くまでしてるため, 何が問題なのかはっきりしている. オープンソースの醍醐味だと思う.
何を言ってるのかというと, 古巣の日立が出しているドキュメントが分かりやすいのでリンクする: http://www.hitachi.co.jp/Prod/comp/OSD/pc/ha/products/hardware/data/WP-16001-512e-hdd.pdf (ちなみに2016年12月発行なので結構新しい)
まとめる
- セクターというのはHDDの中でデータを管理する単位で, このセクターの量に応じて管理データが増える. 古い時代には512Bセクタから始まり, 今もLinuxカーネルのソースコード上ではSECTOR_SHIFTというのは9(つまり512B)で定義されている
- しかしHDDが大容量化するに従って, 512Bセクタでは管理データが膨大になってきた. それをせめて1/8にする目的で制定された仕様が4KBセクタ
- この4KBはどこから来てるかというとページの管理サイズから来ている. 上位は大体4KBで投げてくるから4KBセクタが効率良かろうということ. 上位のロジックにも絡めている仕様だから, 今後覆る可能性はとても低い
- この4KBセクタは, 上から512B I/Oが来ると約束が違うじゃないかと怒る. だから当初は物理的には4KBセクタだけど論理的には512Bセクタで管理するというエミュレーションを行っていた. これを512eあるいはAFTという
- ライトブーストはここまではサポートしていた
- 今回問題となったのは, ネイティブ4KBセクタというエミュレーションをしないタイプで, 上から512B I/Oが来ると怒る. そして, ライトブーストが内部的に発行するI/Oが512Bだったため怒られが発生した
おれがしなければいけないことは以下の2つ:
- ライトブーストの内部で512BのI/Oをすることをやめて, 4KBに統一する. スーパーブロックへのI/Oは稀であるため, これは512BセクタのHDDに対してもさほど不最適とはならない. ある人はライトブーストに対してセクタを指定するパラメータを追加したいと考えるかも知れないが, 将来的に負債となる512Bセクタへのサポートを4KBサポートと同格に扱うのは悪手. 従って512Bセクタに対しても4KBで発行する. この実装は間違いなく出来る.
- backingかcachingのどちらかが4KBセクタの場合, 上に対して4KBでの発行を強制する. なぜかというと, 例えば5KBで発行された場合, DMではこれを4KBと1KBに分割してDMターゲットに渡して来るからだ. ここで最悪ケースを考える. 1つはbackingに対してひたすら512Bのランダムリードをする場合, もう1つはcachingに対してひたすら512Bのリードキャッシュヒットを行う場合. これらはいずれも発生しうることであり, 事情が各々に閉じている. 従って, 両方の事情を汲んだ設定を行う必要がある. ブロックデバイスにはio_limitsというのがあり, ここに「私の論理ブロックサイズは〜です」と意思表明することが出来るのだが, 今回ライトブーストがそれを裏切ってI/Oを発行したことからも分かるとおり, コンパイル時にこの規約をチェックする仕組みはなく, 裏切りはランタイムにしか分からない. そしてそれはあくまでもお願いのレベルであり, 強制のレベルではない(https://people.redhat.com/msnitzer/docs/io-limits.txt). つまり, 上位がむちゃくちゃなサイズのI/Oをしてくることも考えられることなのだ. しかしここでは, 然るべき設定をすれば上位はそれに従ってくれると考えよう. ほとんどのユーザはライトブーストの上に何らかのファイルシステムをかぶせて使うだろうし, 野良のファイルシステムでなければ規約はコードレベルでチェックされているはずである.
デバイスはないから自分の環境で再現することは出来ないが, 簡単なテストをお願いすることくらいは出来るだろうから出来るだけ早いうちにやりたいと思う. 繰り返しになるがライトブーストは死んでいない. むしろ徐々に興味が広がっている.
興味を持ってくれる人がいる限り, おれはサポートをし続ける.