この春、すでにディスクの速度をチェックする方法やRAIDとは何かなど、いくつかの導入トピックについて説明しました。それらの2番目では、ZFSのさまざまなマルチディスクトポロジのパフォーマンスを引き続き調査することさえ約束しました。これは、AppleからUbuntuに至るまで、あらゆる場所で実装されている次世代のファイルシステムです。

さて、今日はZFS、好奇心旺盛な読者を知るための最高の日です。OpenZFS開発者のMatt Arensによる控えめな評価によると、「それは本当に複雑です」ということに注意してください。

しかし、数値に到達する前に-確かにそうですが-すべてのバリアントvosmidiskovoy ZFS構成について、 ZFSがデータをディスクに保存する方法について説明する必要があります。

Zpool、vdev、デバイス

このフルプール図は、3つの補助vdevs、各クラスに1つ、およびRAIDZ2ための4つが含まれています。

そこ不適切のプールを作成する理由は通常ありませんVDEVの種類とサイズが- 。しかし、あなたがしたい場合は、これをやってから何も防止できます

本当にZFSファイルシステムを理解するために、実際の構造を注意深く見る必要があります。まず、ZFSは従来のレベルのボリューム管理とファイルシステムを組み合わせます。次に、書き込み時にトランザクションコピーメカニズムを使用します。これらの機能は、システムが通常のファイルシステムやRAIDアレイと構造的に非常に異なることを意味します。理解する必要がある基本的なビルディングブロックの最初のセット：ストレージプール（zpool）、仮想デバイス（vdev）、および実デバイス（デバイス）。

zpool

zpoolストレージプールは、最上位のZFS構造です。各プールには1つ以上の仮想デバイスが含まれています。次に、それぞれに1つ以上の実デバイス（デバイス）が含まれます。仮想プールは自律ブロックです。 1台の物理コンピューターに2つ以上の個別のプールが含まれている場合がありますが、それぞれは他のプールから完全に独立しています。プールは仮想デバイスを共有できません。

ZFSの冗長性は仮想デバイスのレベルではありますが、プールのレベルではありません。プールレベルでは、冗長性はまったくありません。vdevドライブまたは特別なvdevが失われると、プール全体が失われます。

最新のストレージプールは、キャッシュまたは仮想デバイスログの損失に耐えることができますが、停電やシステムクラッシュの際にvdevログを失うと、ダーティデータを少量失う可能性があります。

ZFSの「データバンド」（ストリップ）がプール全体に記録されるという一般的な誤解があります。本当じゃない。 Zpoolは楽しいRAID0ではありません。複雑な変更可能な配布メカニズムを備えた楽しいJBODです。

ほとんどの場合、エントリは使用可能なスペースに応じて使用可能な仮想デバイスに分散されるため、理論的にはすべてが同時に満たされます。 ZFSの以降のバージョンでは、vdevの現在の使用（破棄）が考慮されます。一方の仮想デバイスが他方よりも大幅にロードされている場合（たとえば、読み取りロードのため）、最高の空き容量係数が存在するにもかかわらず、一時的に書き込みがスキップされます。

最新のZFSレコード配布方法に組み込まれているリサイクル検出メカニズムは、異常に高い負荷の期間中のレイテンシを削減し、スループットを向上させることができますが、これは簡単なブランチではありません1つのプールで低速のHDDと高速のSSDを思わず混在させる。そのような等しくないプールは、最も遅いデバイスの速度で、つまりまるで完全にそのようなデバイスで構成されているかのように動作します。

vdev

各ストレージプールは、1つ以上の仮想デバイス（仮想デバイス、vdev）で構成されています。次に、各vdevには1つ以上の実デバイスが含まれます。ほとんどの仮想デバイスはデータを簡単に格納するために使用されますが、CACHE、LOG、SPECIALなど、いくつかのヘルパーvdevクラスがあります。これらのvdevタイプはそれぞれ、単一デバイス、RAIDz1、RAIDz2、RAIDz3、またはミラーの5つのトポロジーのいずれかを持つことができます。

RAIDz1、RAIDz2、およびRAIDz3は、古いものがRAIDダブル（対角）パリティと呼んでいるものの特別なバリエーションです。 1、2、および3は、各データ帯域に割り当てられるパリティブロックの数を示します。パリティ用に個別のディスクではなく、仮想RAIDzデバイスはこのパリティをディスク間で均等に分散します。 RAIDzアレイは、パリティブロックと同じ数のディスクを失う可能性があります。彼が別のものを失った場合、彼は失敗し、彼と一緒にストレージプールを取ります。

ミラーリングされた仮想デバイス（ミラーvdev）では、各ブロックはvdevの各デバイスに格納されます。最も一般的な2ワイドミラーですが、ミラーには任意の数のデバイスを含めることができます。大規模なインストールでは、読み取りパフォーマンスとフォールトトレランスを向上させるために、トリプルミラーがよく使用されます。 vdevミラーは、vdev内の少なくとも1つのデバイスが動作し続けている間、障害に耐えることができます。

単一のvdevは本質的に危険です。このような仮想デバイスは単一の障害に耐えることはできません。ストレージまたは特別なvdevとして使用されている場合、その障害によりプール全体が破壊されます。ここで、非常に注意してください。

CACHE、LOG、およびSPECIAL仮想アプライアンスは、上記のトポロジのいずれかを使用して作成できます。ただし、SPECIAL仮想アプライアンスを失うとプールが失われることになるため、過度のトポロジを強くお勧めします。

端末

これは、おそらくZFSで理解するのに最も簡単な用語です。文字通り、ブロックランダムアクセスデバイスです。仮想デバイスは個々のデバイスで構成され、プールは仮想デバイスで構成されることに注意してください。

ディスク-磁気またはソリッドステート-は、vdevビルディングブロックとして使用される最も一般的なブロックデバイスです。ただし、/ devにハンドルがある任意のデバイスが適しているため、ハードウェアRAIDアレイ全体を個別のデバイスとして使用できます。

シンプルなrawファイルは、vdevを構築できる最も重要な代替ブロックデバイスの1つです。スパースファイルからプールをテストする -プールコマンドをチェックし、このトポロジのプールまたは仮想デバイスで使用可能なスペースを確認する非常に便利な方法。

ほんの数秒でスパースファイルからテストプールを作成できます。ただし、後でプール全体とそのコンポーネントを削除することを忘れないでください。

サーバーを8つのディスクに配置し、10 TBのディスク（約9300 GiB）を使用することを計画しているとします。トポロジは、ニーズに最適です。上記の例では、ほんの数秒でスパースファイルからテストプールを構築します。8つの10 TBドライブからのRAIDz2 vdevが50 TiBの有用な容量を提供することがわかりました。

別の特別なクラスのデバイスは、SPARE（スペア）です。ホットスワップ可能なデバイスは、従来のデバイスとは異なり、1つの仮想デバイスだけでなく、プール全体に属します。プール内の一部のvdevに障害が発生し、スペアデバイスがプールに接続されて使用可能な場合、影響を受けるvdevに自動的に参加します。

影響を受けるvdevに接続した後、スペアデバイスは、欠落しているデバイスにあるはずのデータのコピーまたは再構築の受信を開始します。従来のRAIDではこれを再構築と呼び、ZFSでは「再構築」と呼びます。

交換用デバイスが故障したデバイスを永久に交換するわけではないことに注意することが重要です。これは、vdevの低下が観察される時間を短縮するための一時的な置き換えにすぎません。管理者が故障したvdevデバイスを交換した後、冗長性はこの永続的なデバイスに復元され、SPAREはvdevから切断され、プール全体のスペアとして機能するように戻ります。

データセット、ブロック、およびセクター

ZFSを使用する過程で理解する必要がある次のビルディングブロックのセットは、それほどハードウェアではなく、データがどのように編成および格納されるかです。全体的な構造の理解を維持しながら詳細を積み重ねないように、ここではメタスラブなどのいくつかのレベルをスキップします。

データセット

最初にデータセットを作成すると、利用可能なすべてのプール領域が表示されます。次に、クォータを設定し、マウントポイントを変更します。マジック！

Zvolは大部分が単なるデータセットであり、そのファイルシステムレイヤーはありませんが、ここでは完全に通常のext4

ファイルシステムに置き換えます。ZFSデータセットは、標準のマウント済みファイルシステムとほぼ同じです。通常のファイルシステムと同じように、一見すると「別のフォルダ」のように見えます。ただし、従来のマウントされたファイルシステムと同様に、各ZFSデータセットには独自の基本プロパティのセットがあります。

まず、データセットには割り当てが割り当てられている場合があります。インストールされている場合zfs set quota=100G poolname/datasetname、マウントされたフォルダーに/poolname/datasetname100 GiBを超える書き込みはできません。

各行の先頭にスラッシュが存在する-存在しないことに注意してください。各データセットには、ZFS階層とシステムマウント階層の両方で独自の場所があります。 ZFS階層の先頭にスラッシュはありません。プールの名前から始め、次に1つのデータセットから次のデータセットへのパスから始めます。たとえば、クリエイティブ名を持つプール内の親データセットの下にpool/parent/child名前が付けられたデータセットの場合。デフォルトでは、データセットのマウントポイントは、ZFS階層の名前と同じで、先頭にスラッシュが付いています。名前のプールはとしてマウントされ、データセットはにマウントされ、子データセットはにマウントされます。ただし、データセットのシステムマウントポイントは変更できます。示す場合childparentpool

pool/poolparent/pool/parentchild/pool/parent/child

zfs set mountpoint=/lol pool/parent/child、その後、データセットはとpool/parent/childしてシステムにマウントされ/lolます。

データセットに加えて、ボリューム（zvols）についても言及する必要があります。ボリュームはデータセットとほぼ同じですが、実際にはファイルシステムがなく、単なるブロックデバイスです。たとえば、zvol名前で作成しmypool/myzvol、ext4ファイルシステムでフォーマットしてから、このファイルシステムをマウントすることができます。これでext4ファイルシステムができましたが、すべてのZFSセキュリティ機能がサポートされています。これは1台のコンピューターではばかげているように見えるかもしれませんが、iSCSIデバイスをエクスポートするときのバックエンドとしてはるかに意味があります。

ブロック

ファイルは1つ以上のブロックで表されます。各ブロックは1つの仮想デバイスに保存されます。通常、ブロックサイズはrecordsizeパラメータと同じですが、メタデータまたは小さなファイルが含まれている場合は2 ^ ashiftに減らすことができます。

私たちは本当に、本当にしているあなたが小さすぎるashiftをインストールする場合は、巨大なパフォーマンスの被害について冗談を言っていない

プールZFSでは、メタデータを含むすべてのデータは、ブロックに格納されています。各データセットの最大ブロックサイズは、プロパティrecordsize（レコードサイズ）で定義されます。レコードのサイズは異なる場合がありますが、データセットに既に書き込まれているブロックのサイズや場所は変わりません。新しいブロックが書き込まれるときにのみ有効です。

特に指定がない限り、現在の記録サイズはデフォルトで128 KiBです。これは一種の難しい妥協であり、パフォーマンスは理想的ではありませんが、ほとんどの場合ひどいものではありません。Recordsize4Kから1Mまでの任意の値に設定recordsizeできます（追加の設定を使用して、さらに多くの値を設定できますが、これはめったに推奨されません）。

どのブロックも1つのファイルのデータのみを参照します。2つの異なるファイルを1つのブロックにまとめることはできません。各ファイルは、サイズに応じて、1つ以上のブロックで構成されます。ファイルサイズがレコードサイズよりも小さい場合、より小さなブロックに保存されます。たとえば、2 KiBファイルのブロックは、ディスク上の4 KiBセクターを1つだけ占有します。

ファイルが十分に大きく、いくつかのブロックを必要とする場合、このファイルを含むすべてのレコードはサイズを持ちますrecordsize -最後のレコードを含み、その主要部分が未使用スペースであることが判明する場合があります。

Zvolボリュームにはプロパティがありません。recordsize 代わりに同等のプロパティがありますvolblocksize。

セクター

最後の、最も基本的な構成要素はセクターです。これは、基本ユニットに読み書きできる最小の物理ユニットです。数十年間、ほとんどのディスクは512バイトのセクターを使用していました。最近、ほとんどのドライブは4 KiBセクター用に構成され、一部のドライブ（特にSSD）では8 KiBセクター以上に構成されています。

ZFSには、セクターサイズを手動で設定できるプロパティがあります。これはプロパティashiftです。シフトが2の累乗であることはやや混乱しています。たとえばashift=9、2 ^ 9、または512バイトのセクターサイズを意味します。

ZFSは、新しいブロックデバイスが新しいvdevに追加されるときに、各ブロックデバイスに関する詳細情報をオペレーティングシステムに要求し、理論的にはこの情報に基づいてシフトを適切に自動的に設定します。残念ながら、多くのディスクはWindows XPとの互換性を維持するためにセクターサイズを偽っています（他のセクターサイズのディスクを理解できませんでした）。

つまり、ZFS管理者はデバイスの実際のセクターサイズを把握し、手動でインストールすることを強くお勧めします。ashift。シフトが小さすぎると、読み取り/書き込み操作の数が天文学的に増加します。つまり、512バイトの「セクター」を実際の4 KiBセクターに書き込むとは、最初の「セクター」を書き込んでから4 KiBセクターを読み取り、2番目の512バイトの「セクター」で変更し、新しい4 KiBセクターに書き込むということです。各エントリ。

現実の世界では、このようなペナルティはSamsung EVO ashift=13SSDを上回りますが、SSD は動作する必要がありますが、これらのSSDはセクターサイズに依存しているため、デフォルトで設定されていますashift=9。経験豊富なシステム管理者がこの設定を変更しない場合、このSSDは通常の磁気HDD よりも低速です。

比較のため、大きすぎるサイズashift事実上罰則はありません。生産性が実際に低下することはなく、未使用スペースの増加は限りなく小さくなります（または圧縮を有効にするとゼロに等しくなります）。したがって、512バイトセクターを実際に使用するドライブをインストールするashift=12かashift=13、将来に自信を持ってドライブすることを強くお勧めします。

このプロパティは、多くの人が誤って考えているように、プールではなくashift各vdev仮想デバイスに設定され、インストール後も変更されません。新しいvdevをプールに追加するときに誤ってノックダウンした場合は、このプールを低パフォーマンスのデバイスで取り返しのつかない形で汚染し、原則として、プールを破棄して最初からやり直す以外に方法はありません。vdevを削除しても、壊れたセットアップからあなたを救うことはありませんashiftashift！

— ,

, , « » « »,

, — , ,

コピーオンライト（CoW）は、ZFSを非常に優れたものにする基本的な基盤です。基本的な概念は単純です。従来のファイルシステムにファイルの変更を依頼した場合、要求どおりに機能します。録音中にコピーを行うファイルシステムに同じことを依頼すると、「良好」と表示されますが、それはあなたにあります。

代わりに、コピー書き込みファイルシステムは、変更されたブロックの新しいバージョンを書き込み、次にファイルメタデータを更新して、古いブロックとのリンクを解除し、書き込んだばかりの新しいブロックを関連付けます。

古いユニットの取り外しと新しいユニットのリンクは1回の操作で行われるため、中断することはできません。この後に電源をリセットすると、新しいバージョンのファイルが作成され、以前に電源をリセットすると、古いバージョンが作成されます。いずれの場合も、ファイルシステムに競合はありません。

ZFSへの書き込み時のコピーは、ファイルシステムレベルだけでなく、ディスク管理レベルでも行われます。これは、ZFSがレコード内のスペース（RAIDの穴）の影響を受けないことを意味します。これは、システムがクラッシュする前にストリップが部分的にしか記録できず、再起動後にアレイが損傷した現象です。ここで、ストリップはアトミックであり、vdevは常に一貫しており、ボブはあなたの叔父です。

ZIL：ZFSインテントログ

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

書き込み操作には、同期（同期）と非同期（非同期）の2つの主なカテゴリがあります。ほとんどのワークロードでは、書き込み操作の大部分は非同期です。ファイルシステムでは、それらを集約してバッチで配信できるため、断片化が減少し、スループットが大幅に向上します。

同期録音はまったく別の問題です。アプリケーションが同期書き込みを要求すると、ファイルシステムに次のように通知します。「これを今すぐ不揮発性メモリにコミットする必要があり、それまではこれ以上何もできません。」したがって、同期レコーディングはすぐにディスクにコミットする必要があります。これにより、断片化が増加したり、帯域幅が減少したりする場合は、そうする必要があります。

ZFSは同期レコードを通常のファイルシステムとは異なる方法で処理します。ZFSはそれらを通常のストレージにすぐにアップロードするのではなく、ZFSインテントログ（ZFSインテントログ）と呼ばれる特別なストレージ領域に記録します。トリックは、これらのレコードもメモリに残り、通常の非同期書き込み要求とともに集約され、後で完全に通常のTXG（トランザクショングループ、トランザクショングループ）としてストレージにダンプされることです。

通常の操作では、ZILは記録され、再度読み取られることはありません。しばらくすると、ZILからの録音がRAMから通常のTXGの主ストレージに固定されると、ZILから切断されます。 ZILから何かが読み取られるときの唯一のことは、プールをインポートするときです。

ZFSがクラッシュした場合-オペレーティングシステムがクラッシュしたり停電したりした場合-ZILにデータがあると、次のプールのインポート中にこのデータが読み込まれます（緊急システムの再起動時など）。 ZILにあるものはすべて読み取られ、TXGグループに結合されて主ストレージにコミットされ、インポートプロセス中にZILから切断されます。

vdevヘルパークラスの1つは、LOGまたはSLOG（セカンダリLOGデバイス）と呼ばれます。彼は1つのタスクを持っています-メインのvdevストレージにZILを格納する代わりに、ZILを格納するための非常に高い書き込み耐性を持つvdevデバイスを、できればはるかに高速にプールに提供することです。 ZIL自体はストレージの場所に関係なく同じように動作しますが、LOGを使用するvdevの書き込みパフォーマンスが非常に高い場合、同期書き込みはより高速になります。

LOGを含むvdevをプールに追加しても、非同期書き込みのパフォーマンスは向上しません -を使用してZILへのすべての書き込みを強制zfs set sync=alwaysしたとしても、ログがない場合と同じ方法で同じ速度でTXGのメインリポジトリに関連付けられます。直接的なパフォーマンスの改善は、同期記録の遅延のみです（ログ速度が高いほど操作が高速化されるためsync）。

ただし、すでに多数の同期書き込みが必要な環境では、vdev LOGは間接的に非同期書き込みと非キャッシュ読み取りを高速化できます。ZILレコードを別のvdev LOGにアップロードすると、プライマリストレージでのIOPSの競合が少なくなり、すべての読み取りおよび書き込み操作のパフォーマンスがある程度向上します。

スナップショット

書き込みコピーメカニズムは、アトミックZFSスナップショットおよび増分非同期レプリケーションの不可欠な基盤でもあります。アクティブファイルシステムには、すべてのレコードを現在のデータでマークするポインターツリーがあります。スナップショットを作成するときは、このポインターツリーのコピーを作成するだけです。

アクティブなファイルシステムでレコードが上書きされると、ZFSは最初にブロックの新しいバージョンを未使用のスペースに書き込みます。次に、古いバージョンのブロックを現在のファイルシステムから切り離します。ただし、一部のスナップショットが古いブロックを参照している場合でも、変更されません。古いブロックは、このブロックにリンクしているすべてのスナップショットが破棄されるまで、実際には空き領域として復元されません。

レプリケーション

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

スナップショットの仕組みを理解したら、レプリケーションの本質を簡単に把握できます。スナップショットはレコードへのポインタのツリーにすぎないため、スナップショットを作成すると、zfs sendこのツリーとそれに関連付けられているすべてのレコードが送信されます。我々はこれを渡す場合zfs sendにはzfs receive、対象物への、それはブロックの実際の内容とターゲット・データ・セットにブロックを参照するポインタの木の両方を書き込みます。

すべてが2番目にさらに面白くなりzfs sendます。これで2つのシステムがあり、それぞれにが含まれていてpoolname/datasetname@1、新しいスナップショットを撮影しますpoolname/datasetname@2。したがって、ソースプールにはとがdatasetname@1ありdatasetname@2、ターゲットプールにはこれまでのところ最初のスナップショットしかありませんdatasetname@1。

ソースとターゲットの間で共通のスナップショットがあるのでdatasetname@1、私たちはそれに加えてインクリメンタル zfs sendを行うことができます。システムzfs send -i poolname/datasetname@1 poolname/datasetname@2に通知すると、2つのポインタツリーが比較されます。にのみ存在するポインタは@2、明らかに、新しいブロックを参照しているため、これらのブロックの内容が必要です。

リモートシステムでは、増分処理もsend同じくらい簡単です。まず、ストリームsendに含まれるすべての新しいエントリを記録し、次にこれらのブロックへのポインターを追加します。ほら、@2新しいシステムで！

ZFS非同期インクリメンタルレプリケーションは、rsyncのような以前の非スナップショット方式よりも大幅に改善されています。どちらの場合も、変更されたデータのみが送信されますが、rsyncは最初に読み取る必要がありますディスクからすべてのデータを両側からチェックして、量を比較します。これとは対照的に、ZFSレプリケーションは、ポインタツリーと、一般的なスナップショットで表されていないブロックのみを読み取ります。

インライン圧縮

コピーオンライトメカニズムは、組み込みの圧縮システムも簡素化します。従来のファイルシステムでは、圧縮に問題があります。変更されたデータの古いバージョンと新しいバージョンの両方が同じスペースにあります。

ファイルの真ん中にあるデータの一部を、0x00000000から始まるゼロのメガバイトとして開始すると考えると、ディスク上の1つのセクターに圧縮するのは非常に簡単です。しかし、このメガバイトのゼロを、JPEGや疑似ランダムノイズなどの非圧縮データのメガバイトで置き換えるとどうなりますか？突然、このメガバイトのデータは1つではなく、4 KiBの256セクターを必要とし、ディスク上のこの場所には1つのセクターのみが予約されます。

変更されたレコードは常に未使用スペースに書き込まれるため、ZFSにはそのような問題はありません。元のブロックは4 KiBセクターを1つだけ占有し、新しいレコードは256になりますが、これは問題ではありません。ファイルの「中央」から最近変更されたフラグメントが未使用スペースに書き込まれます。サイズが変更されたかどうかに関係なく、ZFSの場合、これは通常の状況です。

組み込みのZFS圧縮はデフォルトで無効になっており、システムはプラグインアルゴリズムを提供します。現在、LZ4、gzip（1-9）、LZJB、ZLEなどがあります。

LZ4は、かなり遅いCPUでも、ほとんどのユースケースで非常に高速な圧縮と解凍およびパフォーマンスの向上を提供するストリーミングアルゴリズムです。
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE-ゼロレベルエンコーディング、ゼロレベルエンコーディング。通常のデータにはまったく触れませんが、一連の大きなゼロを圧縮します。完全に非圧縮性のデータセット（JPEG、MP4、または他の既に圧縮された形式など）に役立ちます。これは、非圧縮性のデータを無視しますが、結果のレコードの未使用領域を圧縮するためです。

ほとんどすべてのユースケースでLZ4圧縮をお勧めします。非圧縮データに遭遇するための性能ペナルティは非常に小さく、性能利得の典型的なデータのためには重要です。Windowsオペレーティングシステム（新たにインストールされているOS、まだ内部のデータなし）の新規インストール用の仮想マシンイメージをコピーするcompression=lz427％高速化とより渡されたcompression=none中で、この2015年のテスト。

ARC-適応置換キャッシュ

ZFSは、独自の読み取りキャッシュメカニズムを使用する唯一の最新のファイルシステムであり、オペレーティングシステムのページキャッシュに依存せずに最近読み取ったブロックのコピーをRAMに格納します。

独自のキャッシュに問題がないわけではありませんが、ZFSはカーネルと同じ速さで新しいメモリ割り当て要求に応答できないため、malloc()ARCが現在占有しているRAMが必要な場合、新しいメモリ割り当て呼び出しは失敗する可能性があります。ただし、少なくとも現時点では、独自のキャッシュを使用する十分な理由があります。

MacOS、Windows、Linux、BSDなど、よく知られている最新のオペレーティングシステムはすべて、LRUアルゴリズム（Least Recently Used）を使用してページキャッシュを実装しています。これはプリミティブアルゴリズムであり、読み取りのたびにキャッシュブロックを「キューの上に」上げ、必要に応じて「ダウンキュー」ブロックをプッシュして、新しいキャッシュミス（キャッシュからではなくディスクから読み取られるはずのブロック）を上に押します。

通常、アルゴリズムは問題なく機能しますが、作業データセットが大きいシステムでは、LRUは簡単にスラッシングを引き起こし、頻繁に必要なブロックを混雑させて、キャッシュから再度読み込まれないブロックのためのスペースを作ります。

アーク -「重み付けされた」キャッシュと見なすことができる、それほど単純ではないアルゴリズム。キャッシュされたブロックを読み取るたびに、それは少し「重く」なり、クラウドアウトが難しくなります。さらに、ブロックアウトした後も、一定期間追跡されます。絞り出された後、キャッシュに読み戻す必要があるブロックも「重く」なります。

これらすべての結果、はるかに大きなヒット率を持つキャッシュが作成されます。キャッシュ内のヒット（キャッシュからの読み取り）とミス（ディスクからの読み取り）の間の比率です。これは非常に重要な統計です-キャッシュヒット自体が桁違いに速く処理されるだけでなく、キャッシュミスもより速く処理できます。これは、キャッシュヒットが多いほど、同時ディスク要求が少なくなり、処理する必要のある残りのミスの遅延が少なくなるためです。ドライブ。

結論

ZFSの基本的なセマンティクス（書き込み時のコピーのしくみ、およびストレージプール、仮想デバイス、ブロック、セクター、ファイル間の関係）を調査した後、実際のパフォーマンスと実際の数値について説明します。

次のパートでは、ミラーリングされたvdevとRAIDzを使用したプールの実際のパフォーマンスを、相互に比較し、以前に調べた従来のLinuxカーネルRAIDトポロジと比較します。

最初は基本（ZFSトポロジ自体）のみを検討したかったのですが、この後は、L2ARC、SLOG、特別割り当てなどの補助vdevタイプの使用を含む、より高度なZFSチューニングとチューニングについて説明する準備が整います。

ZFSの基本：ストレージとパフォーマンス