博士

やっほー、ロボ子！ Cognition AIがDevinのワークロードを強化するために、VMハイパーバイザーを構築したらしいのじゃ！

ロボ子

それはすごいですね、博士！ VMを使う理由は何だったんですか？

博士

セキュリティ上の完全な分離が必要だったり、Dockerの中でDockerを実行する必要があったかららしいぞ。なかなか複雑なことをしてるのじゃな。

ロボ子

なるほど。それで、`otterlink`という技術でVMの起動時間を10倍も短縮したんですね！ EC2のスナップショットが30分以上かかっていたのが数秒になったというのは驚きです。

博士

そうそう！ さらに高速化のために、VMディスクのブロックレベルの差分を即座に作成するファイル形式`blockdiff`を構築して、オープンソース化したらしいぞ！

ロボ子

`blockdiff`が必要だった理由は何でしょう？

博士

開発環境の再利用、スリープからの復帰時間短縮、ディスクのロールバックのためらしいぞ。特に開発環境の再利用は便利そうじゃな。

ロボ子

`blockdiff`の設計目標は、コンパクトなスナップショットファイル、瞬時のスナップショット作成、VMへのオーバーヘッドなし、シンプルな実装、とのことですね。

博士

その通り！ `blockdiff`は、ファイルAとBの差分ブロックのみを保存するらしいぞ。他のソリューションの限界も考慮されているみたいじゃ。

ロボ子

バイナリdiffの計算が遅かったり、OverlayFSがDockerとの連携に問題があったり、ZFSが信頼性の問題やパフォーマンスの懸念があったり、qcow2がメタデータのみの操作ではなかったり、ということですね。

博士

`blockdiff`はLinuxカーネルのCoW（Copy-on-Write）実装を利用して、ファイルの内容ではなく、ファイルシステムのメタデータ（ファイルエクステントマップ）を操作するらしいぞ。

ロボ子

ファイルエクステントマップは、ファイル内の論理ブロックとハードドライブ上の物理ブロックのマッピングを示すんですね。

博士

`blockdiff`のファイル形式（.bdiff）は、ヘッダーと差分ブロックのデータで構成されていて、ベースイメージに対するVMディスクのスナップショットを作成して、スナップショットを適用して新しいディスクイメージを作成する、と。

ロボ子

スナップショットの作成と適用は、ファイルメタデータ操作のみのため高速なんですね！

博士

その通り！ `blockdiff`は、スパースファイルのコンパクト化にも利用可能らしいぞ。応用範囲が広いのは良いことじゃ。

ロボ子

今後の課題は、VM実行中のディスクのロールバック、開発環境ディスクのインテリジェントなキャッシュ、メモリのスナップショットとロールバックの効率的な実装、とのことですね。

博士

Cognition AIは、なかなか面白いことに取り組んでいるのじゃな。`blockdiff`のソースコードはGitHubで公開されているから、ロボ子も見てみると良いぞ！

ロボ子

ありがとうございます、博士！ 早速チェックしてみます。

博士

しかし、これだけ高速にスナップショットが作れるなら、私も自分の脳みそのスナップショットを撮って、バックアップしておきたいのじゃ。そうすれば、うっかり大事なことを忘れても安心だぞ！

ロボ子

博士、それだと、スナップショットを取りすぎて、容量が足りなくなるかもしれませんね…。