世間でAlphaGoが凄いことになってるエポックメーキングな日にこれ書くのもアレだけど。

USENIX FAST16の論文のメモ。Tintriとdockerが組み合わさったら何が起きる？

ストレージのせいでコンテナのデプロイが遅いという問題を解決した。具体的にはTintri用のdockerのストレージドライバを作った。コンテナのデプロイを測定するhellobenchってのを開発したらしい。これはgithubに落ちているので、誰でも使える。そこにいる貴方にもだ。

dockerやGoogle Borgといったコンテナ技術は起動が速いという特長があるはずだが、やはりイメージのやりとりというのはそれなりにコストがかかる。起動するときにpullしてくるわけだけど、このコピーが重いのに起動中はデータのごく一部しか使っていない。データの内容としてはdedupがよく効くデータセットだったりする。そのへんはちゃんと分析してあるという印象。

USENIX FAST16の論文のメモ書きです。BetrFS 0.1というのがあったが、それをベースに0.2を作ったという話。

WOD(write optimized dictionary)というのがあって、文字通り書き込みに最適化されたディレクトリなんだけど、これまで削除、リネーム、シーケンシャル書き込みが遅かった。それをlate-binding journaling, zoning, range deletionの3つで解決した。

journalingというのはファイルシステム用語で、一度ジャーナル領域にログを書いて、後で本物の位置に書き出すという方式。Linuxでもext4はデフォルトでメタをジャーナリングして、データは直接本物の位置に書き出すというやり方。data=journalにすると、データもジャーナリングする。ジャーナリングの欠点は書き込み量が倍になること。stable storageへの書き込み完了を返す時間を早めたいからジャーナル領域にログ書きするわけだけど、実際にファイルシステムの構造を効率よく保つためにはログ書きのままだと都合が悪い。なので、別の本物の領域を割り当てて書き出すという作業が必要になる。

これも魅力的なタイトルですね。Garth GibsonのところのCMUの人。Shingled Diskまだまだ熱いですからね。

Caveat-Scriptorはラテン語でlet the writer bewareという意味らしい。それでも意味がわからないんだけど、書き込む側が何らかの負担をするという意味みたい。

Host-Managed software for Caveat-Scriptor shingled disks is allowed to write anywhere, but if it fails to respect these distance parameters, it may destroy data.

とのこと。Shingled Diskはピッチを狭めて書き込んでいるので、両側から書き込まれると真ん中が消えてしまう。つまり基本的にシーケンシャルに書き込まなければならない。たまに飛んでもいいけど、制約があったりする。普通はディスクのファーム側に制約を満たしつつうまくやってくれる(SSDのファームと非常に似た処理をする)層をつける。ここでログ構造にしてLSM treeみたいにするのが一般的と言えると思います。いま売られているSeagateのArchive系のシリーズは中身がそうなってる奴ですね。こういうのは当然、各社出してくると思います。この論文ではホスト側でやったほうがうまくいくはずなのでその方法を考えたよ、という話。

コード → https://github.com/wuxb45/lsm-trie-release

USENIX ATC15の論文。これはタイトルだけで読みたくなる論文ですね。LSMで、trieですよ。

LSMは普通はtreeですよね。Log Structured Merged Treeという古くからある有名なデータ構造。私も何度か実装しました。追加がシーケンシャルwriteになるので高速になり、けっこう便利なのですよね。一方でtrieというのはインデックスがエッジに含まれるtreeで、これも非常に古くからあるデータ構造。組み合わせたらどんな素敵なんだろう、という話。

USENIX ATC15に出ていた論文。

Dropbox系のサービスを複数使ってreliableなストレージにする話。と聞くとアホらしい話にしか聞こえないが、実際はどうか？ 似たようなセコい話をどこかで見たような記憶もある。実際サービス停止したりデータロストしたりしているので、そういう状況でもうまく使いたいという話です。ただDropbox型のものはデータロストしてもユーザの手元のマスターデータと同期しているだけだから、Dropbox側が壊れたってデータがなくなるわけじゃないんだよなぁ。だからちょっとくらいロストしてもいいって感じで運用してるんじゃないかと思う。

Analysis of the ECMWF Storage Landscape

ECMWF(European Centre for Medium-Range Weather Forecasts、ヨーロッパ中期予報センター)のストレージを分析したもの。データが100PBあって、年45%増えている。ECFSというアーカイブ向けのものとMARSというDB的なAPIで扱うオブジェクトストアを併用している。ECFSは14.8PBで基本テープに0.34PBのディスクでキャッシュしている。MARSもテープで54PB。1PBのキャッシュ(が2個？)。MARSにはHPCのソフトからアクセスされる。あまり深い興味を引かれず、途中までしか読まなかった。

OSDI14の論文。

SSDが登場してから、いろんな処理をオフロードする試みがなされてきた。Atomic Operationやアロケーション、FSの権限チェックなど。だが実際のところこのような機能はSSDのベンダしか追加できないし、デバイス側がコードを信頼しなければならないという問題があった。まあそれは普通の話だよね。

それを解決するのがこのWillow。will allowでwillowらしい。これでサードパーティのプログラマが処理を追加できるようにした。4つ問題があって、そのうちの3つに重点している。残りの1つは既存研究がいくつかある。

これはShingled Diskの話。だいたいShingled Diskのすべてのことが書いてあるように見える。Best Paper受賞作。まあFASTのBest Paperという評価はアテにならないことがほとんどだが…

Shingled Diskは書き込みに制限をかけることで、ディスクの書き込み幅を狭くできるという目からウロコの技術。ずいぶん昔からあったはずだが、最近になってSSDの影響でファームの技術が上がってきたため、やっと実用化に至った。

NetAppの論文。

ストレージの話ではなくて、NFSのキャプチャをするに当たって、性能を出すためにどう工夫したのか、という話。性能向けのプログラミング技術の参考になればと思う。一般論として、キャプチャの人はいろいろ頑張るからね。

libtaskでパイプライン処理。当然zero copy、dedup用にチェックサム計算も行う。使ったチェックサムは512Bごとに64bitのやつ。書き出しは圧縮してストレージを節約。

読んだ感想を、ちょっと実況風に。

HACFS。Hadoop HDFSのErasure Codeの話。Erasure Codeってのは、知ってる人も多いと思うけど、高度なパリティみたいなもんですね。一部が壊れても復元できるようにしている。例えば身近なところだとQRコードとか、一部が読み取れなくても情報が伝わるようになってたりするでしょ？ ああいう種類のコード化の名前がErasure Code。←これで説明になってる？？