ZFSを開く

SunでZFSを設計したとき、彼らはルールブックを捨て、他のUNIXライクなシステムに直接対応するものがないものを作成しました。 David Chisnallは、従来のストレージモデルに加えられた変更、システムに組み込まれている基本、およびそれらがすべてどのように適合するかを調べました。







数年ごとに、誰かが将来どのくらいのプライベートコンピューターリソースが必要になるかを予測します。 後で、誰もが彼らがどれほど素朴であるか自分自身を笑います。 ZFSの設計において、Sunはこのエラーを回避しようとしました。



全世界が64ビットファイルシステムに移行するにつれて、Sunは128ビットファイルシステムを導入しています。 このような大きなサイズが必要になることはありますか？ すぐではありません。 惑星地球の質量は約6 * 10 ^ 24 kgです。 対応する水素の質量を取得すると、3.6 * 10 ^ 48個の原子が得られます。 128ビットのファイルシステムは、2 ^ 128、または10 ^ 38ブロックの情報配置にインデックスを付けることができます。 各原子が1ビットの水素として保存されるリポジトリを構築する場合（制御ロジックに必要なスペースはカウントしません）、各原子が4Kの128ビットファイルシステムを持っている場合、地球の質量を超える約300,000個のデバイスを構築できますデータ割り当て単位。 ZFSスペースの限界に達する前に、大陸規模のハードドライブを構築します。



それでは、128ビットのファイルシステムには何かポイントがありますか？ そうでもない。 ただし、現在の傾向が続く場合、今後5〜10年で64ビットファイルシステムの制限に到達し始めます。 おそらく、スペースがなくなる前に置換を引き起こす可能性のある他の予期しない制限には80ビットのファイルシステムで十分でしょうが、ほとんどのコンピューターでは、128ビットの番号よりも80ビットの番号で操作する方が困難です。 そのため、Sunは128ビットシステムをリリースしました。

鈍い独立

ディスク（またはネットワーク）にデータを書き込むときは、バイト順に注意する必要があります。 1台のマシンにのみデータをダウンロードして保存する場合、マシンのレジスタの内容を表示に関係なく書き出すことができます。 データの共有を開始すると問題が始まります。 バイトより小さいものは問題ありません（VAXを使用する幸運な場合を除く）が、大容量のボリュームでは明確に定義されたバイト順を使用する必要があります。



最も一般的な2つの注文は、ジョナサンスウィフトのガリバー旅行記の卵哲学者に名前が付けられています。 「ビッグエンディアン」表記法は、バイトを1234の形式で配列し、「リトルエンディアン」コンピューターは4321の順序でそれらを保存します。 。



ほとんどのファイルシステムは、特定のアーキテクチャで動作するように設計されています。 ただし、後で別のアーキテクチャに移植された場合でも、各ファイルシステムは、ファイルシステムアーキテクチャに格納されているバイト順でメタデータを格納する傾向があります。 AppleのHFS +は、このプラクティスの良い例です。 HFS +がPowerPCで発生したため、ファイルシステムのデータ構造はビッグエンディアン形式で保存されています。 Intel Macでは、ディスクにデータをロードまたは書き込むたびにバイト順を入れ替える必要があります。 x86チップ上のBSWAP命令を使用すると、すばやくフリップできますが、いずれにしても、これはパフォーマンスにはあまり良くありません。



Sunは、SPARC64およびx86-64アーキテクチャでSolarisの販売とサポートを開始したとき、バイトオーダーに関しては興味深い立場にありました。 SPARC64はビッグエンディアンで、x86-64はリトルエンディアンです。 Sunがどのソリューションを選択したとしても、Sunがサポートする他のアーキテクチャよりもファイルシステムの1つを遅くします。



サンソリューション？ 選択しないでください。 ZFSの各データ構造は、コンピューターが書き込んだバイト順で、使用されたバイト順を示すフラグとともに書き込まれます。 OpteronのZFSパーティションはリトルエンディアンになり、UltraSPARCが制御するパーティションはビッグエンディアンになります。 ディスクを2台のマシン間で分割しても、すべてが機能します。書き込みが多いほど、自然な読み取りに最適化されます。

レベル構造の明白な違反

ZFSは、Linuxカーネルメーリングリストで「レベル構造のひどい違反」と説明されていました。 これは完全に正確ではありません。ZFSは伝統的なUNIXの意味でのファイルシステムではありませんが、通常のファイルシステムの拡張セットを提供する特定のレイヤーのセットである可能性があります。 この時点で、オーディエンスのVMS管理者は、自分自身に満足してつぶやくことができます。「UNIXがついに本物のファイルシステムを手に入れました。 たぶん、彼は最終的に工業使用の準備ができているでしょう。」



3つのZFSレイヤーと呼ばれます：インターフェイスレイヤー、トランザクションオブジェクトレイヤー、およびフェデレーションストレージレイヤー。 スタックを下って行くと、これらのレイヤーはファイルシステムリクエストをオブジェクトトランザクションに変換し、トランザクションを仮想ブロックデバイスを使用した操作に変換し、最後に仮想操作を実際の操作に変換します。



後で見るように、このスタックの一部はオプションです。

パーティションマネージャー。

ZFSスタックの一番下には、フェデレーションストレージレイヤーがあります。 この層は、既存のシステムのパーティションマネージャーと同様の役割を果たします。



ミラーリングまたはRAID-Zのいずれかのオプションを使用してデバイスを組み合わせて作成された各仮想デバイス（vdev）。 vdevを作成したら、それらをストレージプールに結合します。 このアプローチは、ある程度の柔軟性を提供します。 迅速なアクセスが必要なデータや安全に保存する必要があるデータがある場合は、高度にミラーリングされたプールとRAID-Zプールを作成し、最適なファイルシステムにファイルシステムを作成できます。 ファイルシステムをvdevで継続的にホストしないでください。 上のレベルのストレージスペースの連続したブロックのように見える場合がありますが、通常は近くにあります。



ZFS設計の重要なアイデアの1つは、パーティションの作成はディレクトリの作成と同じくらい簡単であるべきだということでした。 たとえば、これにより、ZFSでクォータを適用することが可能になり、各ユーザーにホームディレクトリ用の個別のセクションが与えられ、ストレージプール内で動的に成長します。



他のパーティションマネージャーとは異なり、ZFSはI / O計画を定義します。 各トランザクションには、システムのvdevレベルでスケジューラが処理する特定の優先度と時間枠があります。

オブジェクト層

ZFSの中間層は、トランザクションオブジェクトの層です。 このレイヤーの基礎はデータ管理ユニット（DMU）であり、多くのZFSブロック図では、このレイヤーに表示されるのはDMUのみです。 DMUは最上層のオブジェクトを提供し、アトミック操作を可能にします。



ファイルの書き込み中に電源障害が発生した場合は、fsck、scandiskなどを実行している可能性があります。 最終的に、おそらくいくつかの破損したファイルがあります。 これらがテキストファイルである場合は、幸運かもしれません。 損傷は簡単に修復できます。 そうでない場合、ファイルの構造が混在していると、ファイル全体が失われる可能性があります。 データベースアプリケーションは、トランザクションメカニズムを使用してこの問題を解決します。 彼らは何かをディスクに書き、「それをやる」と言って、それをします。 その後、ログに「私はこれをやった」と書きます。 プロセスのどこかで問題が発生した場合、データベースは単に操作が開始される前の状態にロールバックする場合があります。



多くの新しいファイルシステムは、ファイルシステムレベルのデータベースと同じことを行うジャーナリングを使用します。 ジャーナリングの利点は、ファイルシステムの状態が常に一貫していることです。 停電後は、ディスク全体をスキャンするのではなく、ログを再生するだけで済みます。 残念ながら、この整合性はファイルには適用されません。 ユーザーアプリケーションから2つの書き込み操作を実行すると、一方が完了し、もう一方が完了しない可能性があります。 このモデルはいくつかの問題を引き起こしています。



ZFSはトランザクションモデルを使用します。 多数のレコードを作成することでトランザクションを開始できますが、それらはすべて正常に完了するか、すべて失敗します。 これは、ZFSがコピーオンライトメカニズムを使用しているために可能です。 ZFSは、データを書き込むたびに、このデータをスペアディスクスペースに書き込みます。 次に、「これは新しいバージョンです」と言って、メタデータを更新します。 書き込みプロセスがメタデータ更新ステージに到達しない場合、古いデータは上書きされません。



コピーオンレコード効果の1つの側面は、永続的なスナップショットを作成できることです。 FreeBSDのUFS2やIRIXのXFSなどの一部のファイルシステムは、すでにスナップショットをサポートしているため、これは新しい概念ではありません。 標準テクノロジーは、スナップショットセクションの作成です。 スナップショットを1回作成すると、各記録操作は、オリジナルをスナップショットセクションにコピーして記録を実行するシーケンスに置き換えられます。 このアプローチは非常に高価であることを思い出すのは不要です。



ZFSでは、スナップショットを作成するために必要なのは、セクションリンクの数を増やすことだけです。 各書き込み操作は既に非破壊的であり、起こりうる唯一のことは、メタデータ更新操作が古い場所へのリンクを削除できないことです。 このメカニズムを使用することのもう1つの側面は、スナップショットが独自の権限を持つファーストクラスのファイルシステムであることです。 他のセクションと同じ方法でスナップショットに記録できます。 たとえば、ユーザーごとにファイルシステムのスナップショットを作成し、他のユーザーに影響を与えることなく、ユーザーが目的の操作を実行できるようにすることができます。 この機能は、Solarisゾーンと組み合わせると特に便利です。

ファイルシステムのふりをする

これらはすべてオブジェクトベースのトランザクションストレージシステムを備えているのに優れていますが、誰が使用するのでしょうか。 私のアプリケーションはすべて、UNIXファイルシステムに非常によく似たものと通信したいと考えています。 そして、ZPLのZPL、POSIXレイヤーが登場します。 ZPLは、POSIXファイル操作（読み取り、書き込みなど）と基礎となるDMU操作の間で変換します。 彼は、ディレクトリ構造の管理を担当し、ACL（アクセス制御リスト）の使用を許可しています。



ZPLに加えて、ZFSには、ZVOLと呼ばれるインターフェイス層に別のモジュールがあります。 このレイヤーは、より簡単な変換を実行します。 POSIX準拠のファイルシステムの外観を作成する代わりに、ZFSストレージプールに依存する既存のファイルシステムの実装に役立つ未処理のブロックデバイスのように見えます。 FreeBSDポートは、最初にZVOLデバイスの上にある既存のUFS2ファイルシステムを使用します。 AppleがHFS +メタデータをサポートできるようにするために、AppleポートはZVOLの上でHFS +を使用すると思われます。



このレイヤーでの今後の作業には、興味深い機会がいくつかあります。 ZFSはすでにトランザクションをサポートしているため、このレイヤーでSQLまたは同様のインターフェイスを使用できる可能性があります。 ファイルシステム作成の低コストに基づいて、各ユーザーはその場でデータベースを作成し、POSIXレイヤーによって提供されるものよりもはるかに柔軟なインターフェイスを取得できます。 Microsoft WinFSの問題（ファイルに基づかないアプローチを全員にサポートさせるのは難しすぎる）は、ツールが現在のファイルシステムを置き換えるのではなく増加するため、適用されません。

彼女は何をしていないのですか？

現在、ZFSの最大の欠点は暗号化の欠如です。



NTFSにはファイルベースの暗号化があり、ほとんどのパーティションマネージャーにはブロックレベルの暗号化メカニズムがあります。 幸いなことに、この問題は認識されており、ZFSは圧縮に使用されるのと同じメカニズムを使用できます。



明確に定義されたクォータもサポートされていません。 最大サイズの拡張可能なパーティションを作成できますが、ユーザーがパーティションに作成できるファイルの最大数を設定することはできません。

RAIDの最後の言葉？

ZFSの最もエキサイティングな機能の1つはRAID-Zです。 現代のハードドライブは、やや退屈なインターフェースを持つデバイスです。 これは、読み取りまたは書き込み可能な固定サイズのブロックの配列です。 RAIDは通常ブロック層のように実装されることが多いため（多くの場合、ハードウェアレベルで、オペレーティングシステムに対して透過的です）、RAIDデバイスもこのインターフェイスを提供します。 3つのディスクがあるRAID-5アレイでは、ブロックを書き込むとブロックがディスク1に保存され、XORブロックの結果はそれぞれディスク2または3のいずれかになります。これにより、2つの関連する問題が発生します。

• 運がよければ、1つのディスクへのアトミック書き込み操作を保証できますが、ディスクのグループへのアトミック書き込みを取得することはほとんど不可能です。 最初のブロックの書き込みとチェックサムの間に何かが壊れた場合、システムはすべてのディスク上のこのブロックインデックスのナンセンスを含みます。 最新のRAIDコントローラーは、データが安全に保存されたことの確認がディスクから受信されるまで、不揮発性RAMにレコードを保存することにより、この問題を回避します。
• 上記のシナリオでは、ディスク1に1つのブロックを書き込むには、ディスク2からブロックを読み取ってディスク3にチェックサムを保存する必要があります。各書き込みの途中で余分な読み取り操作を行うと、コストが高くなります。

それでは、RAID-Zの違いは何ですか？ まず、RAID-ZアレイはRAIDアレイほど愚かではありません。 彼はそこに何が保存されているかをある程度認識しています。 重要なコンポーネントは、可変ストライプ幅（！）です。 既存のRAID実装では、1バイト（奇数バイトはそれぞれディスク1に、各偶数バイトはディスク2に、各パリティバイトはディスク3に書き込まれます）、またはブロックサイズです。 ZFSでは、ストライプのサイズはレコードのサイズによって決まります。 ディスクに記録するたびに、ストライプ全体を記録します。



この構造は、上記の両方の問題を解決します。 ZFSはトランザクション型であるため、ストライプは正しく書き込まれ、メタデータが更新されるかされません。 中間記録中にハードウェアに障害が発生した場合、記録が失敗したことを意味しますが、ディスク上の既存のデータは影響を受けません。 簡単に言えば、ストライプには書き込まれているデータのみが含まれているため、記録するためにディスクから何かを読み取る必要はありません。



RAID-Zは、新しいZFSレイヤー構造でのみ可能です。 ドライブがクラッシュしたときにRAID-5パーティションを復元し、「各ドライブのインデックス0のすべてのビットのXORは0になるので、不足しているドライブには何が含まれますか？」と言うことができます。 RAID-Zでは、これは不可能です。 代わりに、ファイルシステムのメタデータを確認する必要があります。 ブロックデバイスであるRAIDコントローラーはこれを行うことができません。 追加のボーナスの1つは、ハードウェアRAIDコントローラーが、回復を要求されたときに、ドライブを再作成する必要があることです。使用されなかったブロックでも、RAID-Zは使用済みブロックのみを復元する必要があります。



RAID-Zの一部ではありませんが、ZFSにはデータ損失の問題の解決に役立つ別の機能が含まれています。各ブロックにはSHA256ハッシュが含まれているため、ディスクコントローラーがこれに気付かなくても、ディスク上の破損したセクターはエラーを含むものとして表示されます。 これは、既存のRAID実装に対する利点です。 たとえば、RAID-5を使用すると、パーティション全体を回復できますが、ディスク上の単一セクターが破損した場合、ディスク全体が既存のエラーを報告する場合があります。 RAID-Zパーティションは、どのドライブにエラーがあるか（ブロックがハッシュと一致しないドライブ）を示し、別のドライブからデータを復元できます。 これは、ディスクが破損している可能性があることを早期に警告する役割も果たします。



このすべての可変ストライプサイズを使用すると、ストライプサイズが単一のブロックよりも小さい場合に何が起こるか疑問に思うかもしれません。 答えは簡単です。ZFSはパリティを計算する代わりに、単にデータをミラーリングします。



ZFSで私が非常に興味深いと感じたことが1つあります。ランダム読み取りのコストが低いブロックデバイスでより良く機能するということです。 まるで設計者が理解しているのは、ハードドライブではなくフラッシュドライブを持っているかのようです。

どうすれば入手できますか？

オペレーティングシステムでZFSを使用できますか？ [Open] Solarisのユーザーにとっては、答えはイエスです。他のユーザーにとっては、そうかもしれません。 Windowsを使用している場合は、おそらくそうではありません。 Linuxの場合、状況はやや複雑です。 OpenSolaris実装はCDDLライセンスの下でリリースされており、GPLとの互換性はありません。 Linuxでこのファイルシステムをサポートするには、2つの方法があります。 1つ目は完全に独自の実装を行うことです。これには多大な労力が必要になるため、近い将来には起こりそうにありません。 もう1つの方法は、ZFSをFUSEに移植し、ユーザープロセスとして実行することです。 この作業はすでに進行中ですが、結果はカーネルレベルで実装されたバージョンよりもはるかに遅く、ブートパーティションでは使用できないようです。 ZFSサポートが必要なUbuntuユーザーは、OpenSolarisカーネルとGNUユーザー環境を使用するNexentaに切り替えることができます。



CDDLがファイルごとのライセンスである限り、プロジェクトの一般ライセンスに影響を与えず、「このプロジェクトのすべてのコンポーネントはこれらの条件に適合するライセンスで保護する必要がある」ことを示すライセンスを持たない多数のプロジェクトで使用できます。 。 これには、FreeBSDとDragonFlyBSDが含まれます。どちらもポート開発があり、MacOS XはZFSサポート付きで出荷される予定です。