Category: Storage
世間でAlphaGoが凄いことになってるエポックメーキングな日にこれ書くのもアレだけど。 USENIX FAST16の論文のメモ。Tintriとdockerが組み合わさったら何が起きる？ ストレージのせいでコンテナのデプロイが遅いという問題を解決した。具体的にはTintri用のdockerのストレージドライバを作った。コンテナのデプロイを測定するhellobenchってのを開発したらしい。これはgithubに落ち
USENIX FAST16の論文のメモ書きです。BetrFS 0.1というのがあったが、それをベースに0.2を作ったという話。 WOD(write optimized dictionary)というのがあって、文字通り書き込みに最適化されたディレクトリなんだけど、これまで削除、リネーム、シーケンシャル書き込みが遅かった。それをlate-binding journaling, zoning, range deletionの3つで解決した。 journalingというのはファイルシステム用語で、一度ジャ
これも魅力的なタイトルですね。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はピッチを狭めて書き込んでいるの
コード → 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型のものはデータロストしてもユーザの手元のマスターデータと同期しているだけだ
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には
OSDI14の論文。 SSDが登場してから、いろんな処理をオフロードする試みがなされてきた。Atomic Operationやアロケーション、FSの権限チェックなど。だが実際のところこのような機能はSSDのベンダしか追加できないし、デバイス側がコードを信頼しなければならないという問題があった。まあそれは普通の話だよね。 それを解決するのがこのWillow。will allowでwillowらしい。これでサ
これは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。←これで説明になっ