人文系のマイナー論文で面白いものを紹介する本。芸人さんで、もとはラジオで紹介していたらしい。後日談もあったりして、割と面白かった。こういう趣味もあるんだなあ。

大きな論文誌とかじゃなくて大学の紀要とかからも持ってきていて、かなり雑食でアンテナも広いんじゃないかな。趣味的な研究が多く。それでも最後の湯たんぽコレクターの人の話はすごかった。湯たんぽが欠落した時代があったなんて。

続編も出てるみたいですね。

世間で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系のシリーズは中身がそうなってる奴ですね。こういうのは当然、各社出してくると思います。この論文ではホスト側でやったほうがうまくいくはずなのでその方法を考えたよ、という話。

HotStorage15の論文。

delta compressionの話。以前何かやろうとしたなぁ、delta encodingなつかしー。world enlargeだと思ったらword enlargeだった。

delta encodingで共通部分を見つけるときに、一度見つけたら続きもつながっていることが多く、それを利用してスループットを上げるという話だった。あんまり難しいことを言ってるようには聞こえないが、効果は出ている。edeltaはdelta encodingを高速に処理できるのだ。

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

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

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

これもATC15かな。

ここで言うファイルシステムというのはファイルシステム自体の話ではなくて、もいっこ上の、ファイルツリーの話。いわゆる/ですね。組み込みLinuxの/だとbusyboxを使ったりするけど、ここではそこをGolangで書いてみた、という話。

Golangでそれを書いたからってどうなるわけでもあるまい、と思うでしょ？

それをいい意味で裏切ってくれる内容だった。

このroot fs、バイナリとしてはinitとgoのコンパイラしか含んでいない。あとはソースの形で持っている。コマンドを実行したときに、未コンパイルであればその場でコンパイルされ、実行される。バイナリはキャッシュされる。以前はPerl LinuxてのがあってPerlの処理系とスクリプトで動かすやつがあったらしい。あともちろん主流の、普通のBusyboxベースのやつもある。前者は効率は悪いが柔軟性があって、後者は柔軟性はないが効率が良い。U-rootはその中間を狙った。Golangは動作も高速だしコンパイルも速いからね。マルチプラットフォームへの対応も割と楽。Busyboxは割とLinuxべったりな作りだけど、GolangであればLinuxからの脱出も楽だろう。

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つは既存研究がいくつかある。