submit_bioによって提出されたときにIOファイルシステム要求は、共通ブロック層へ進みます。一般的なIOブロック層は、いくつかの前処理操作になり、その目的は、要求が最適なパフォーマンスを確保するために、可能な限り、より合理的な基礎となるディスクデバイスに送信することができることを確実にするためです。IOスケジューリングモジュールでより重要な存在です。あなたはこれらのディスクスケジューリングアルゴリズムです、前にそこCFQ、およびNOOP期限加算を聞いたことがあります。最も使用CFQスケジューリングアルゴリズム。
図に示すように積層構造と様々な装置は、3つの層に関する簡略化された構造をマッピングブロックを無視する場合。ここでは3つの層があるソフトウェアではありませんが、また、ハードウェアを含みます。言うまでもなく、共通のブロック層が、これは主にIO操作の完全な統合とスケジューリングです。ドライバ層、ドライバ層は、IO要求の動作を変換するための、ハードウェアドライバどのである（注：異なるブロックデバイスに違いがあり、装置は必ずしもiSCSIのレジスタ操作を持たない）ハードウェアレジスタです。駆動層のプログラム異なる物理デバイスは、ディスクに直接接続されたSASと同様に、異なるそれはFC-SANのFC-HBAカード接続である場合、駆動層は、FCドライブ（などであるのに対し、駆動層のプログラムは、SASドライブでありますQLogicドライバ）。
図階層化装置
デバイス層は、底部層は、デバイス層は、典型的には、ハードウェアデバイスです。ここで、このようなようにSASカード、SATAカード、FC-HBAカードまたはiSCSI-HBAカード、等のハードウェア、多種多様。時には、それはそれのためにそのようなiSCSIなどのハードウェアデバイス、ではないかもしれない要求がシミュレーションソフトウェア層の一端を介してターゲットデバイスにカードによって送られている間、層があってもよいです。
主なデータ構造とプロセス
2手順の大半は、プログラムのスケルトンに対応するデータ構造データ構造及びアルゴリズムの組成物の一部であり、プログラムのアルゴリズムは、肉および腱です。アルゴリズム関連データ構造によって、それによって完全な全体を形成します。問題は、単純なものから複雑なものまで、コンクリートから抽象的に人間の知識の法則であるので、我々は、データ構造の先頭で始まります。キーデータ構造のデータを理解し、我々はより簡単に全体の論理ブロックIOデバイスを理解することができます。
最も重要なデータ構造のブロックIOデバイスでrequest_queue、すなわち要求キューです。図2に示したデータ構造の模式図を、データ構造自体は、キー部材の一部のみを残し、我々はここで簡略化し、非常に複雑です。図着色部2は、要求及び処理要求を受信するために、それぞれ、関数ポインタです。
図2のリクエストキューデータ構造
理解を容易にするために、我々はここで例を与えます。NBDブロックデバイスでは、例えば、ブロックデバイスはmake_request_fn blk_queue_bioを初期化する初期化されるとき、request_fnがdo_nbd_request初期化されます。SCSIブロックデバイスの場合、request_fnが初期化されscsi_request_fnを。
知識及び結果の上記データ構造の初期化の主要メンバーで、我々は、ブロック・デバイスの全体の処理の詳細を分析することができます。デバイスは簡単なチェックの呼び出しの後、エントリー・ブロックがsubmit_bioある要求します
実際make_request_fnコード入力機能IO処理関数ポインタで見ることができるように、我々は、ポインタが実際に機能blk_queue_bioであることを知っています。従って要求ブロックは、デバイスblk_queue_bio機能によって処理されます。
ディスクのスケジューリングポリシー
Linuxカーネルは、ディスクのスケジューリングポリシーを設計する際に大きな柔軟性を提供します。ディスクスケジューリングポリシーはつまり、ユーザーは自由のディスクスケジューリングポリシーを選択することができ、カーネルにそれらを差し込む登録します。
スケジューリングアルゴリズムを考えることは、要求を求めて処理時間とディスクを最適化するために、主にIOの並べ替え、合併やバッチ処理によって、実際には非常に簡単です。これは、現在のスケジューリングアルゴリズムが原因で機械的なディスクヘッドの位置決め時間のかかるIOの全体の処理時間の大部分の機械的なディスクに対して、実際にはもっとあることに注目する価値があります。もちろん、SSDディスクスケジューリングアルゴリズムのためにも、ビューのIOポイントの固有の特性を必要とする、いくつかの助けを持っています。
図3スケジューリングポリシー構造
図1に示す構造スケジューリングポリシー定義ディスク。3、各変数の意味は、比較的に明らかである本明細書では繰り返しません。本論文では、この変数は、特定の機能を実現するための戦略をスケジュールされ、OPSをelevator_ops変数の型を見て、任意のスケジューリングアルゴリズムは、これらの機能の一部を達成しなければなりません。
スケジューリングポリシーを達成するために完了これらのコールバック経由で。行うためのスケジューリングポリシーの特定の設定どのような物事の機能を理解するために、私たちは一緒にテーブルを入れて、私たちはどのような各機能を実行するために、具体的何の事全部で始まります。スケジューリングポリシーについては、それがここに実現しなければならないすべての関数はありませんが、達成されなければならない*を持つテーブルでのみ機能です。
要するに、コールバック関数の機能は、要求をマージすることができるかどうかを判断し、発行されたマージ操作要求などを行います。もっと上のコールバック、およびスケジューラの分散を使用して、多くの具体的なプロセスでは、より複雑なシーンの使用。したがって、一度クリアなすべてのシーンで導入することは困難です。コールバック関数は、我々の締切スケジューリングポリシーブリーフ例の作用をより直感的に理解するために。
図4は、それが図から分かるように、全ての、わずか16は、コールバック関数9を初期化する初期化コールバック関数が存在しない、期限初期化コールバック関数です。
図4締め切りコールバック
具体的には、我々はシーンをリコールする機能を分析、我々は以前の要求elevator_merge_fn機能を照会するために使用される導入バイオと組み合わせることができます。図5に示すように、全体コールスタック入口blk_queue_bioで、我々は、スケジューラへの入り口である機能、前に導入しました。要求があるかどうかを見つけるために使用される関数呼び出しelv_mergeは合併して返すことができます。コールバック関数が提供さelv_merge正式締切スケジューラと呼ばれています。決意が完了した後、関数は実際の状況に基づいて、要求を返す（または返さない、見つからない）と組み合わさ方向（例えば、前進、後進合体など）、以降の処理は、特定の合成操作です。
5関数呼び出しスタック
ここで使用可能なIOスケジューリングプロセスより複雑な、限られたスペースには、最初に、今日ここに紹介ので。私たちは、その後、IOスケジューリング上の他のコンテンツへのより詳細な紹介に従ってください。