要点

  • ボニックの 1994 年の slab allocator 論文は、カーネルオブジェクトを匿名のメモリ塊ではなく型を持つ再利用可能な構造として扱い、後に複数の OS の実装に影響を与えた。
  • 2001 年のジョナサン・アダムズとの論文が示した CPU ごとの magazine と vmem アロケータは、この考えをマルチプロセッサとメモリ以外のリソースへ拡張した。
  • ボニックはマット・アーレンズとともに ZFS を始め、Sun でより大きなチームを率いてストレージプール、コピーオンライト、端から端までの検証、スナップショット、修復を統合した。ただし彼を単独の発明者と呼ぶことはできない。
  • EMC による DSSD の買収とその後の単独製品の終了、そしてボニックが現在 iodyne の共同責任者を務めている事実は、設計の質と取引価値と市場での製品継続が別々の問題であることを示している。

ストレージシステムがエラーを告げずに間違ったブロックを返すことがある

ストレージの基本的な約束は単純です。プログラムが後でデータを要求したとき、書き込んだものが返ってくるべきだというもの。従来の構成では、責任はファイルシステム、ボリュームマネージャ、コントローラ、ディスクに分散します。各層が成功を報告していても、チェーン全体としては古いデータや誤った場所へ書かれたデータ、破損したデータを返していることがあり得ます。

ZFS はブロックのチェックサムを親ブロックに格納するため、期待されるアイデンティティが、それを検証する対象の内容とは別にポインタツリーを伝わります。読み出し時には、デバイスが操作の成功を報告していても、システムは結果を期待値と比較します。ミラーまたは RAID-Z に正しいコピーがあれば、代替を読み出して検証し、正しいデータを返し、破損したコピーを修復できます。さらに scrub は、アプリケーションがデータを必要とする前に、割り当て済みデータを走査して潜在する破損を探します。

この仕組みが ZFS の整合性の評判を説明する一方で、その限界も定めます。チェックサムは差異を検出できますが、すべてのコピーが間違っていればデータを再生成できません。冗長性は、独立したバックアップ、検証済みの復旧手順、物理的な配置設計の代わりにはなりません。管理ミス、正当な権限を持つランサムウェア、災害、連鎖する障害は、設計上の保証を超える可能性があります。

ボニックの貢献は、サイレント障害を検出可能にし、検証と修復を通常の処理経路に組み込んだことです。データ喪失の危険を消したわけではありません。良いアーキテクチャの価値は、保証がどこで終わるかを明示することにあります。

ZFS の前に、カーネルオブジェクト生成コストを下げた

カーネルは絶えず、ファイル、接続、プロセス、仮想メモリのための構造を生成します。これらのオブジェクトには型とサイズ、不変条件、初期化コストがあります。生メモリを要求してオブジェクトを組み立て、使い終わるたびに破棄するという作業を、システム全体の規模で考えると小さな仕事の積み重ねが巨大な負担になります。

ボニックが 1994 年に記述した slab allocator は、メモリを slabs に整理し、オブジェクトのカテゴリごとにキャッシュを維持します。コンストラクタが必要な状態を初期化し、デストラクタが解放を担い、空きオブジェクトは再利用のために残ります。これによりカーネルは型情報とライフサイクルを保持し、局所性、断片化、デバッグ、アカウンティングを改善できます。

最初の実装は SunOS と Solaris 固有のものでした。Linux や FreeBSD などは独自の実装と判断を発展させたため、すべての近代的アロケータをボニックに帰することはできません。キャッシュはメモリを消費し、古い状態を保持し、圧力下で調整を必要とします。持続的な影響は、生成コスト、ロック競合、局所性、ライフサイクルを一体の設計の一部にしたことです。

CPU ごとの magazine がアロケータをマルチプロセッサ対応にした

グローバルなキャッシュは、多くのプロセッサが同一のロックを奪い合うとボトルネックになります。2001 年のMagazines and Vmemで、ボニックとジョナサン・アダムズは CPU ごとの小さなローカルグループを提案しました。頻繁な操作は局所的に実行され、共有ストアとの交換はバッチで行われます。

vmem はこの層化されたアプローチを、アドレス空間、識別子、その他のリソースへ拡張しました。arena がより下位のアロケータからリソースを輸入するため、システムはすべてのオブジェクトを中央で同期する代わりに、グループと所有関係を管理します。

局所性には代償があります。オブジェクトが一方の CPU に滞留しながら他方で必要になることがあり、バランス調整とメモリ圧力は依然として問題です。測定結果は当時のハードウェアとワークロードに依存していました。永続的なアイデアは、公開インターフェースが失ってしまう情報を保持することにあります。

ZFS はストレージ層を再構築するというチームの決定から始まった

ボニックとマット・アーレンズは 2001 年に Sun で ZFS を始め、その後ビル・ムーアと多数のエンジニアが加わりました。ボニックがプロジェクトを率い、公の場で最も多く説明した人物ではありますが、実運用のファイルシステムにはディスクフォーマット、キャッシュ、ツール、ドライバ、テスト、そして長年にわたる集団的な修復が含まれます。

従来の方法では、RAID またはボリュームを作成し、事前に分割し、硬い成長前提のもとでファイルシステムを構築する必要がありました。ZFS はファイルシステムとボリューム管理を pool の周りに統合しました。vdev が容量を追加し、dataset がそれを動的に消費します。quota、reservation、snapshot、その他の属性が単一のモデルに収まります。

日々の運用が単純になったぶん、初期のトポロジー選択がより重要になります。vdev の構成は冗長性、性能、拡張性、障害時の挙動を決め、後から自由に組み替えられるわけではありません。Sun は 2004 年にシステムを発表し、2005 年に OpenSolaris で提供され、2006 年に Solaris 10 で出荷されました。

歴史的な意義は単一の機能ではなく、pool、copy-on-write、checksum、snapshot、RAID-Z、cache、管理を一貫した整合性のモデルに統合したことにあります。

copy-on-write がツリー全体をコミットの単位にした

同じ場所への書き込みは、停電時にメタデータを二つの状態の間に置くことがあります。ZFS は新しいブロックを新しい場所に書き、親を更新し、トランザクショングループの新しい root へ原子的に移行します。古いバージョンは新しいバージョンが完了するまで一貫したまま残ります。

snapshot は古いブロックへの参照を保持し、clone はデータを共有してから書き込みに応じて分岐します。代償は追加の書き込み、断片化、確保された空き容量です。さらにこの保証は、ハードウェアとコントローラが書き込み順序とデータ永続性を守ることに依存します。

システムは追加の構造を費やして、どのバージョンが完全か、どのブロックが期待されるか、どの状態に頼れるかという知識を得ます。この知識が物理層を不要にするわけではありません。

checksum と修復が「成功した読み出し」の意味を変えた

ZFS はデバイスが成功を報告した操作まで検証します。チェックサムが不一致なら別のコピーを試し、正しいコピーが見つかれば破損したコピーを修復できます。scrub はこれを周期的な保守に変え、冗長性が存在する限り破損を検出し続けます。

検出と修復と完全な復旧は別々の能力です。ランサムウェアは正しいチェックサムを持つ暗号化データを書き込めます。複数のコピーが同時に壊れることもあります。同じ障害ドメイン内のバックアップは独立とは言えません。運用者はどこにコピーがあるか、設計された冗長性が尽きた後に残る手段は何かを知っている必要があります。

RAID-Z と ARC と scrub が整合性を日々の運用に組み込んだ

RAID-Z は copy-on-write とパリティストライプを使って従来の write hole を回避しますが、小さな書き込みのコスト、再構築、連鎖障害は残ります。ディスクが大きくなるほど、修復中に二次障害が起きるまでの時間が延びます。

ARC は新しさと再利用の間でデータのバランスを取ります。セカンダリキャッシュが階層を延長できますが、いかなるキャッシュもすべてのワークロードで遅い媒体を速くするわけではなく、メモリ圧力とメタデータの負荷を測る必要があります。

scrub、resilver、snapshot の削除、replication は I/O、CPU、ネットワークを消費します。保守のための余裕は容量の一部であり、無駄ではありません。常に限界まで稼働している pool は、復旧が必要なときに最も弱いことがあります。

ボニックはまた、分かりやすい運用語彙の普及にも貢献しました。pool、vdev、transaction group、scrub です。この語彙は採用を容易にしましたが、その前提条件から切り離されたスローガンになり得ます。

OpenSolaris は終わったが、設計は生みの親を超えて生き延びた

Oracle は 2010 年に Sun を買収し、クローズドな Solaris ZFS の系統はオープンなコードから分岐しました。OpenZFS は 2013 年に設立され、illumos、FreeBSD、Linux などの間で調整を行っています。現在のプロジェクトは Sun の仕事の系譜にありますが、大きく変化し、ボニックの管理下にはありません。

この継続性は、設計が組織を超えて生き延び得ることを示していますが、摩擦のない道のりではありませんでした。CDDL は Linux カーネルの GPL と単純には両立せず、プラットフォームごとに機能の採用時期は異なり、feature flags は pool の移動に影響します。

公開リポジトリだけでは十分ではありません。メンテナー、テスト、資金、リリースが必要です。ガバナンス自体が組織的な障害領域になります。OpenZFS はボニックの遺産の一部ですが、現在はそれを運営する人々の責任です。

DSSD が示したこと: 野心的なアーキテクチャでも製品競争には負け得る

ボニックはマイク・シャピロ、ビル・ムーアとともに DSSD を設立し、データベースと分析向けのラック規模の flash システムを構築しました。EMC は 2014 年にこれを買収し、2017 年に D5 を単独製品として廃止しました。

これにより、決定的な成功物語という見方は終わります。速さ、独創性、資金は永続的な居場所を保証しません。移行、コスト、認証、サポート、販売チャネル、買い手の優先順位、NVMe やクラウドの経済性が、ベンチマークと同じほどの重みで結果を決め得ます。

公開された情報からは、単一の原因を特定したり創業者の資産規模を推定したりすることはできません。買収と製品の終了だけが確かです。DSSD は技術的価値、取引価値、商業的継続性を切り分ける例になっています。

iodyne は同じ問いをプロ用メディアに適用するものであり、ZFS を再現するものではない

ボニックとシャピロは 2018 年に iodyne を設立し、共同責任者を務めています。同社はビデオ・音声チーム向けに、高速で暗号化・冗長化された NVMe ストレージを構築しています。

継続性は思想的なものです。実際のワークフローの中での性能、保護、修復です。iodyne は「箱に入った ZFS」でも DSSD の直接の延長でもありません。規模、インターフェース、市場、仕組みは異なります。

製品ページが示すのは公表された機能であって、監査済みの信頼性、売上、シェアではありません。メディア制作では、障害が編集と納品を止め、暗号化が資産を守り、ユーザーの作業が続かなければ速さに価値はありません。統合によってサポートは単純化する一方、依存は単一の事業者に集中します。

運用が信頼性モデルの一部になった

ZFS の pool は、かつてミスを生み出していた管理的な境界を減らしました。dataset、quota、reservation、snapshot、replication は、ばらばらのツールの連鎖ではなく単一のポリシーを共有します。

しかし責任は消えていません。dataset は pool の容量を消費し、snapshot はブロックを確保し、replication は稼働する宛先と復旧先があって初めて意味を持ちます。二つの論理コピーが同一のコントローラ、電源、firmware の欠陥を共有することもあります。論理モデルを現実の障害領域に結び付けなければなりません。

zfs listの整然とした出力は、組織がアプリケーションを復旧できること、データベースの一貫性を保てること、復号に必要な認証情報を見つけられることを証明しません。論理的な視点は運用を容易にしますが、復旧テスト、物理的な依存関係、アプリケーションの依存関係の理解の代わりにはなりません。

アロケータとファイルシステムが、保守を第一級の責務にした

キャッシュには充填と調整が必要で、pool には検査、再構築、複製が必要です。これらの作業はユーザーと資源を争いますが、信頼の継続を決めます。使われていないリソースこそが、次の障害が起きる前に修復を可能にする余裕かもしれません。

これはソフトウェアにも当てはまります。OpenZFS にはテスト、互換性、リリースが必要であり、iodyne には販売後の firmware、ホストソフトウェア、ハードウェアの保守が必要です。発明がシステムを生み、保守がそれをインフラに変えます。

技術的リーダーシップは、他人がその中で働ける境界を設けることだった

ボニックのリーダーシップは重要であり、かつ集団的なものでした。アーレンズ、ムーア、アダムズ、Sun のチーム、そして後続のメンテナーを見えるままに保つ必要があります。caches、arenas、pools、datasets、transaction groups のような抽象化は、共通のモデルを保ちながら仕事を分割することを可能にしました。

歴史的な権威は現在の責任の代わりにはなりません。OpenZFS のコードは現在のメンテナーが決め、iodyne のリーダーシップはシャピロと共有されています。関係者を明示することは、今どこに決定と保守と責任があるかを明確にします。

ライセンスとガバナンスが障害分離のもう一つの形になった

企業は戦略を変え得ます。オープンコードは、Sun 以降も複数のグループが ZFS を追い続けることを可能にしました。しかし組織的な冗長性が機能したのは、権利と知識と実際にリリースする能力を同時に持っていたからです。

メンテナーのいない二つのフォークは、同じコントローラの背後にある二つのディスクより丈夫ではありません。企業とボランティアが資源を提供すると同時に、依存も生みます。OpenZFS は技術的にも組織的にも生き延びました。

繰り返される手法は、薄い層が捨てる情報を保持すること

汎用アロケータはサイズしか見えませんが、slab は型とライフサイクルを見ます。ストレージ層は成功した読み出ししか見えませんが、ZFS は期待されるアイデンティティを持つブロックを見ます。製品はスループットを報告しますが、運用は修復、暗号化、継続性を扱います。

追加の情報にはコストがあり、共有障害領域を広げることもあります。良い設計とは、最も多くの構成要素を隠すことではなく、組織が理解し修復できる境界を見えるようにすることです。

ZFS はストレージ市場での比較の単位を変えた

volumes、filesystem、checksum、snapshot、修復を統合することで、ZFS は経路全体の比較を迫りました。XFS、Btrfs、APFS、ReFS、Ceph、商用アレイを前にして重要なのは、特性のリストではなく、整合性のモデル、トポロジー、サポート、出口経路です。

普遍的な勝者は存在しません。商用製品は検証済みのハードウェアと契約を提供し、オープンコードは透明性と移植性を提供し、分散システムは規模とネットワーク依存を加え、専用デバイスは lock-in の増大と引き換えに workflow を改善します。

障害領域の考えが、メモリとストレージと企業の生存を結び付ける

障害領域は、一枚のディスク、ラック、グローバルな lock、あるいは企業やベンダーであり得ます。magazines は単一ロックへの集中を減らし、checksum はデバイスへの盲目的な信頼を減らし、OpenZFS は単一企業への依存を減らします。

冗長性はリスクの層の中に存在しなければなりません。単一の controller の背後にあるディスク、失われた単一の鍵の下にあるコピー、メンテナーのいない branches は、丈夫さの外観しか提供しません。単純さは共通の運命を隠し得ます。相関を明示し、独立した復旧を検証しなければなりません。

誠実な遺産とは絶対的な保証ではなく、より良い問いである

slab allocator はカーネルオブジェクトを変え、magazines と vmem は割り当てを広げ、ZFS は運用と整合性を統合し、OpenZFS は組織的な移行を通過し、DSSD は商業的な限界を示し、iodyne は別の市場で同じ課題に取り組んでいます。

ボニックは、共創者、プロジェクトリーダー、アーキテクトと呼ぶのが正しく、唯一の作者でも現行の OpenZFS の支配者でもありません。ZFS は多くの破損を検出しますが正しいコピーを必要とします。copy-on-write はハードウェアに依存し、RAID-Z はバックアップの代わりにならず、scrub は次の読み出しを保証しません。

評価の試金石は、現在のシステムが彼の仕事を不可欠にした問いに答えられるかどうかです。アロケータはオブジェクトについて何を知っているか。ブロックの検証用の期待値はどこに格納されるか。どの状態が完全か。コピーは本当に独立しているか。冗長性が尽きた後、誰が復旧するのか。さらに、完全な計測の欠如、ZFS への貢献の正確な配分、iodyne についての監査済みデータがないことは、結論の中に保たれなければなりません。この正確さ自体が同じ規律の一部です。