読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) 揮発バッファ(type=0)での並列I/O

http://akiradeveloper.hatenadiary.com/entry/2013/12/21/111842

において, 不揮発バッファ(type=1,2)を利用すれば, ディスクへのI/Oが並列化出来るであろうことは述べた. しかし, 仮にバッファが揮発であっても, write barrierへのACKのみを整列化すればよいということが分かる.

flush daemonの処理は以下

  1. キューからflush jobを一つ取り出す
  2. 同期write(!= sync)する
  3. last_flushed_segment_idをインクリする.
  4. segmentをcompleteする
  5. rambufをcompleteする
  6. flush jobに繋がれている永続化命令にACKする

2と3の間に, 「自分のsegment idの一つ前までちゃんと永続化されているまで待つ」というwaitを入れる. これ自体は新しく追加して, 6のあとでインクリする.

現実的には, 先に刈り取ったものがディスクI/Oも早くACKするに決まってるので, 実際にはそこで待つ確率はほぼゼロ.

他の考察との衝突もあるので, 並列I/O自体を導入するかどうかは満場一致とはならない. 例えば, 「ある瞬間にフラッシュされようとしているセグメントはたかだか一つである」という制約を加えることによって信頼性を高められる可能性がある. 並列I/Oを実装する方が将来性や技術的な深みという点では面白いことは明らかである(マルチキューとも相性がいい. Linuxが進もうとしている方向性に合致する). 問題は, そのために失うものが, ハードに対する自明な仮定によってカバー出来るか. このキャッシュを実運用する場合には, キャッシュには信頼性の点でそこそこまともなSSDを使うことを仮定しても良いだろうから, 的外れなくらいうんこなSSDを使う場合どうするんだこれじゃ破綻するだろ!というツッコミに対しては, 「じゃあそれで運用どうぞ」で返して十分.

http://lkcl.net/reports/ssd_analysis.html

の結論によると, IntelSSDは電断時にも予備電源の力によってキャッシュ上のデータをちゃんと書き出してくれるようなので, IntelのDC用を仮定すれば楽勝... しかしこれに限定したくはない.

writeboostとしては, 「セグメントはatomicに残して欲しい」「少なくとも, 1つのセグメントについて, LBAの高い方だけを残すということはやめて欲しい」という要望がある(後者は, メタデータが完全ならばデータ領域のハッシュ値によってatomicでないことを判定出来ないこともない <- 出来ればしたくないが. メタデータが古いのにデータのみが書き換わってると, ディスクからログをリプレイ出来なくなる可能性が高い).