(57)【特許請求の範囲】
【請求項１】
ファイル・システム・ヒントを生成および通信する方法であって、
ファイル・システム層からＩ／Ｏリクエストを受信するステップと、
前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査するステップと、
前記ファイル・システム・コンテキスト情報の属性を判別するためにファイル・システム層へアクセスするステップと、
前記ファイル・システム層から前記ファイル・システム・コンテキスト情報の前記属性を受信するステップと、
前記ファイル・システム・コンテキスト情報の前記属性を分析するステップと、
前記ファイル・システム・コンテキスト情報の前記属性の分析に基づいて少なくとも１つのヒントを生成するステップであって、前記少なくとも１つのヒントは、前記ヒントと関連するＩ／Ｏリクエスト・データの相対的な重要度を示し、前記少なくとも１つのヒントは、相対的に重要なＩ／Ｏリクエスト・データを相対的に高速の記録媒体へ記録することを指示するために使用されるように構成されるものである、ヒントを生成するステップと、
前記少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信するステップ
とを備え、
前記少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する前記ステップは、
前記少なくとも１つのヒントを、前記Ｉ／Ｏリクエストの少なくとも１つのブロックの少なくとも１つの不使用フィールドへ添付するステップと、
前記Ｉ／Ｏリクエストを前記低位レベルのストレージ・タイヤへ送信するステップと
を更に備える方法。
【請求項２】
請求項１に記載の方法であって、前記ファイル・システム・コンテキスト情報は、ファイル・システム・メタデータと、ファイル・システム・アクセス・パターンと、ファイル・システムｉノード（インデックス・ノード）と、ファイル・システムｖノード（仮想インデックス・ノード）と、ファイル・システム・スーパー・ブロックと、ジャーナリング・ファイル・システムのトランザクション・ログと、グループ記述子テーブルと、ブロック・ビットマップと、ｉノード・ビットマップと、ｉノード・テーブルと、ｉノード・メタファイルとのうちの少なくとも１つを含む、方法。
【請求項３】
請求項１に記載の方法であって、前記ファイル・システム・コンテキスト情報は少なくともファイル・システム・スーパー・ブロックを含む、方法。
【請求項４】
請求項１に記載の方法であって、前記ファイル・システム・コンテキスト情報は少なくともファイル・システム・メタデータを含む、方法。
【請求項５】
請求項１に記載の方法であって、前記ファイル・システム・コンテキスト情報は、ファイル・システムｉノード（インデックス・ノード）とファイル・システムｖノード（仮想インデックス・ノード）とのうちの少なくとも１つを含む、方法。
【請求項６】
請求項５に記載の方法であって、前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する前記ステップは、
前記Ｉ／Ｏリクエストの少なくとも１つのブロックのフィールドと、フラグと、状態とのうちの少なくとも１つを、ファイル・システム・コンテキスト情報に関して検査するステップ
を更に備える、方法。
【請求項７】
請求項５に記載の方法であって、前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する前記ステップは、
前記Ｉ／Ｏリクエストの少なくとも１つのブロックがスーパー・ブロックを含むか否かを検査するステップ
を更に備える、方法。
【請求項８】
請求項５に記載の方法であって、前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する前記ステップは、
前記ファイル・システムｉノードおよび前記ファイル・システムｖノードが、それぞれ、メタｉノード（メタ−インデックス・ノード）およびメタｖノード（メタ−仮想インデックス・ノード）であるかを検査するステップ
を更に備える、方法。
【請求項９】
請求項１〜８の何れか一項に記載の方法であって、ファイル・システム層からＩ／Ｏリクエストを受信する前記ステップは、
前記ファイル・システム層のバッファ・キャッシュから、またはファイル・システムｉノード（インデックス・ノード）・キャッシュから、Ｉ／Ｏリクエストを受信するステップであって、この受信は前記ファイル・システム層とブロック層との間で行われるものである、ステップ
を更に備える、方法。
【請求項１０】
請求項１〜９の何れか一項に記載の方法であって、
前記Ｉ／Ｏリクエストと関連する少なくとも１つの論理ブロック・アドレスに対して、前記少なくとも１つのヒントをハッシュ・テーブルに記憶するステップ
を更に備える方法。
【請求項１１】
請求項１〜１０の何れか一項に記載の方法であって、前記低位レベルのストレージ・タイヤは、低位レベルのストレージ・ドライバと、低位レベルのストレージ・コントローラと、低位レベルのストレージ・システムとのうちの少なくとも１つを含む、方法。
【請求項１２】
ファイル・システム・ヒントを生成および通信するために、システム・トポロジへ付加されるように構成された装置であって、
システム・トポロジのファイル・システム層、ブロック層、および低位レベルのストレージ・タイヤと通信するように構成されたフィルタ・ドライバ
を備え、
前記フィルタ・ドライバは、ヒント・エンジンおよび通信コンポーネントを備え、前記フィルタ・ドライバは、少なくとも、
前記ファイル・システム層からＩ／Ｏリクエストを受信し、
前記Ｉ／Ｏリクエストをファイル・システム・コンテキスト情報に関して検査し、
前記ファイル・システム・コンテキスト情報の属性を判別するために前記ファイル・システム層へアクセスし、
前記ファイル・システム層から、前記ファイル・システム・コンテキスト情報の前記属性を受信し、
前記ファイル・システム・コンテキスト情報の前記属性を分析し、
前記ファイル・システム・コンテキスト情報の前記属性の分析に基づいて少なくとも１つのヒントを生成し、
前記少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する
ようにさらに構成され、
前記少なくとも１つのヒントは、前記ヒントと関連するＩ／Ｏリクエスト・データの相対的な重要度を示し、前記少なくとも１つのヒントは、相対的に重要なＩ／Ｏリクエスト・データを相対的に高速の記録媒体へ記録することを指示するために使用されるように構成され、
前記フィルタ・ドライバは更に、
前記少なくとも１つのヒントを、前記Ｉ／Ｏリクエストの少なくとも１つのブロックの少なくとも１つの不使用フィールドへ添付し、
前記少なくとも１つのヒントを添付した前記Ｉ／Ｏリクエストを前記低位レベルのストレージ・タイヤへ送信するように構成される装置。
【請求項１３】
請求項１２に記載の装置であって、前記ファイル・システム・コンテキスト情報は、ファイル・システムｉノード（インデックス・ノード）とファイル・システムｖノード（仮想インデックス・ノード）とのうちの少なくとも１つを含み、前記フィルタ・ドライバは更に、
前記Ｉ／Ｏリクエストの少なくとも１つのブロックのフィールドと、フラグと、状態とのうちの少なくとも１つを、ファイル・システム・コンテキスト情報に関して検査し、
前記Ｉ／Ｏリクエストの前記少なくとも１つのブロックがスーパー・ブロックを含むか否かを検査し、
前記ファイル・システムｉノードおよび前記ファイル・システムｖノードが、それぞれ、メタｉノード（メタ−インデックス・ノード）およびメタｖノード（メタ−仮想インデックス・ノード）であるかを検査する
ように構成される、
装置。
【請求項１４】
請求項１２または請求項１３に記載の装置であって、前記低位レベルのストレージ・タイヤは、低位レベルのストレージ・ドライバと、低位レベルのストレージ・コントローラと、低位レベルのストレージ・システムとのうちの少なくとも１つを含む、装置。
【請求項１５】
ファイル・システム・ヒントの生成および通信の方法をコンピュータ・デバイスに行わせるためのコンピュータ・コードを記録するコンピュータ読取可能な記録媒体であって、
前記コンピュータ・コードは、
ファイル・システム層からＩ／Ｏリクエストを受信する動作と、
前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する動作と、
前記ファイル・システム・コンテキスト情報の属性を判別するために前記ファイル・システム層へアクセスする動作と、
前記ファイル・システム層から、前記ファイル・システム・コンテキスト情報の前記属性を受信する動作と、
前記ファイル・システム・コンテキスト情報の前記属性を分析する動作と、
前記ファイル・システム・コンテキスト情報の前記属性の分析に基づいて少なくとも１つのヒントを生成する動作と、
前記少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する動作と
をコンピュータ・デバイスに行わせるものであり、
前記少なくとも１つのヒントは、前記ヒントと関連するＩ／Ｏリクエスト・データの相対的な重要度を示し、前記少なくとも１つのヒントは、相対的に重要なＩ／Ｏリクエスト・データを相対的に高速の記録媒体へ記録することを指示するために使用されるように構成され、
前記少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する前記動作は、
前記少なくとも１つのヒントを、前記Ｉ／Ｏリクエストの少なくとも１つのブロックの少なくとも１つの不使用フィールドへ添付する動作と、
前記Ｉ／Ｏリクエストを前記低位レベルのストレージ・タイヤへ送信する動作と
を更に備える記録媒体。
【請求項１６】
請求項１５に記載の記録媒体であって、
前記ファイル・システム・コンテキスト情報は、ファイル・システムｉノード（インデックス・ノード）とファイル・システムｖノード（仮想インデックス・ノード）とのうちの少なくとも１つを含み、
前記Ｉ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する前記動作は更に、
前記Ｉ／Ｏリクエストの少なくとも１つのブロックのフィールドと、フラグと、状態とのうちの少なくとも１つを、ファイル・システム・コンテキスト情報に関して検査する動作と、
前記Ｉ／Ｏリクエストの前記少なくとも１つのブロックがスーパー・ブロックを含むか否かを検査する動作と、
前記ファイル・システムｉノードおよび前記ファイル・システムｖノードが、それぞれ、メタｉノード（メタ−インデックス・ノード）およびメタｖノード（メタ−仮想インデックス・ノード）であるかを検査する動作と
を含む、
記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ファイル・システムのヒント及び／又はアプリケーション駆動のヒントの導出、生成、および通信の方法および装置に関する。ファイル・システムのヒントは、ファイル・システム層により発せられたＩ／Ｏリクエストから傍受したファイル・システム・コンテキスト情報に基づいて生成されて、低位レベルのストレージ階層へ通信される。
【背景技術】
【０００２】
現在のキャッシュ・ベースのストレージ・システムは、ファイル・システムが認識可能なコンテキスト情報を有効に決定することや導出することができない。タイヤ２（tier-2、階層２）キャッシュのような非常に低位のレベルで動作するキャッシュ・ベースのストレージ・システムのような、現在のキャッシュ・ベースのストレージ・システムは、ファイル・システムのＩ／Ｏのコンテキストや、ファイル・システムのＩ／Ｏに対する近接性(proximity）を欠いている。コンテキストの欠如および近接性の欠如のため、現在のキャッシュ・ベースのストレージ・システムは、受信しているデータの重要度に基づいてデータ・アクセシビリティ（accessibility）を改善する能力を欠いている。更に、現在のキャッシュ・ベースのストレージ・システムは、ファイル・システムのＩ／Ｏのコンテキストや、ファイル・システムのＩ／Ｏに対する近接性を欠いているので、アプリケーションのデータ・アクセス・パターンについての情報を得る能力を必然的に欠いている。
【０００３】
非常に低位のレベルでは、階層化されたストレージ・システムや、下位レベルのストレージ・システムまたはデバイスのストレージ・コントローラは、アプリケーションやファイル・システムのデータ・アクセス・パターンを認識しない。低位レベル（例えば、低位レベルのストレージ・システム（例えば、低位レベルのＲＡＩＤストレージ・システム）が属するレベルなど）は、ファイル・システムやアプリケーションからアクセスされているデータのタイプについての情報を直接的に得る手段を有さない。低位レベルのストレージ・システムは、タイヤ２キャッシュの階層化されたストレージ・システムとして動作することができる。しかし、ホスト側のキャッシュ情報は、低位レベルのストレージ・システムのキャッシュへは渡されない。
【０００４】
現在、アプリケーションに特定の情報（特定アプリケーション情報）を低位レベルのストレージ・システムへ送るまたは渡すための機構はない。
【０００５】
従って、上記の問題に対処するための方法および装置を提供することが望ましい。
【発明の概要】
【０００６】
従って、本発明は、ファイル・システムのヒント（ファイル・システム・ヒント）を生成して通信するための方法を含む。この方法は、ファイル・システム層からＩ／Ｏリクエストを受信し、このＩ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査するステップを含む。また、この方法は、ファイル・システム・コンテキスト情報の属性を判別するためにファイル・システム層へアクセスし、ファイル・システム層からファイル・システム・コンテキスト情報の属性を受信するステップを含む。方法は、更に、ファイル・システム・コンテキスト情報の属性を分析し、ファイル・システム・コンテキスト情報の属性の分析に基づいて少なくとも１つのヒントを生成するステップを含む。ヒントは、ファイル・システム・コンテキスト情報の属性により決定されるデータの重要度を示すことができ、ヒントと関連するデータの相対的な重要度は、そのデータが相対的に高速の記憶媒体に記憶されるべきか又は相対的に低速の記憶媒体に記憶されるべきかを決定する。更に、方法は、少なくとも１つのヒントを低位レベルのストレージ・タイヤ（ストレージ階層）へ送信するステップを含むことができる。
【０００７】
更に、本発明は装置を含む。装置は、ファイル・システム・ヒントを生成および通信するために、システム・トポロジへ付加できるように構成される。装置は、少なくとも、システム・トポロジのファイル・システム層、ブロック層、および低位レベルのストレージ・タイヤと通信するように構成されたフィルタ・ドライバを備える。フィルタ・ドライバは、少なくとも、ヒント・エンジンおよび通信コンポーネントを含む。更に、フィルタ・ドライバは、少なくとも、
ファイル・システム層からＩ／Ｏリクエストを受信し、
そのＩ／Ｏリクエストをファイル・システム・コンテキスト情報に関して検査し、
そのファイル・システム・コンテキスト情報の属性を判別するためにファイル・システム層へアクセスし、
ファイル・システム層から、ファイル・システム・コンテキスト情報の属性を受信し、
ファイル・システム・コンテキスト情報の属性を分析し、
ファイル・システム・コンテキスト情報の属性の分析に基づいて少なくとも１つのヒントを生成し、
その少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する
ように構成され、少なくとも１つのヒントは、Ｉ／Ｏリクエストに関連するものであり、少なくとも１つのヒントは、ファイル・システム・コンテキスト情報の属性により決定されるデータの重要度を示すものであり、ヒントと関連するデータの相対的な重要度は、そのデータが相対的に高速の記憶媒体に記憶されるべきか又は相対的に低速の記憶媒体に記憶されるべきかを決定するものである。
【０００８】
本発明の実施形態は、コンピュータ読取可能な記録媒体を含み、その記録媒体は、ファイル・システム・ヒントの生成および通信の方法をコンピュータ・デバイスに行わせるためのコンピュータ・コードを記録するものであり、コンピュータ・コードは、
ファイル・システム層からＩ／Ｏリクエストを受信する動作と、
そのＩ／Ｏリクエストを、ファイル・システム・コンテキスト情報に関して検査する動作と、
そのファイル・システム・コンテキスト情報の属性を判別するためにファイル・システム層へアクセスする動作と、
ファイル・システム層から、ファイル・システム・コンテキスト情報の属性を受信する動作と、
ファイル・システム・コンテキスト情報の属性を分析する動作と、
ファイル・システム・コンテキスト情報の属性の分析に基づいて少なくとも１つのヒントを生成する動作と、
少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信する動作と
をコンピュータ・デバイスに行わせるものであり、
少なくとも１つのヒントは、ファイル・システム・コンテキスト情報の属性により決定されるデータの重要度を示すものであり、ヒントと関連するデータの相対的な重要度は、そのデータが相対的に高速の記憶媒体に記憶されるべきか又は相対的に低速の記憶媒体に記憶されるべきかを決定するものである。
【０００９】
上記の全体的な説明および下記の詳細な説明の双方とも、例示的であり説明のためのものであり、本発明を限定することを意図していない。明細書に関連する添付の図面は、本発明の実施形態を示すものであり、一般的な説明と共に本発明の原理を説明するためのものである。
【００１０】
本発明の様々な目的および利点は、当業者であれば、添付の図面を参照することにより、より良く理解できる。
【図面の簡単な説明】
【００１１】
【図１】図１は、現在実施されているシステム・トポロジにおけるユーザ空間およびカーネル空間の層を示す。
【図２】図２は、ヒント提供のために構成されたシステム・トポロジのフロー図である。
【図３】図３は、ヒント・エンジンを含むフィルタ・ドライバのブロック図である。
【図４】図４は、ファイル・システム・ヒントのために構成されたファイル・システム層およびフィルタ・ドライバにおけるＩ／Ｏリクエストのフロー図である。
【図５】図５は、アプリケーションのヒントのために構成されたファイル・システム層およびフィルタ・ドライバにおけるＩ／Ｏリクエストのフロー図である。
【図６】図６は、ヒントの通信の第１手法のフロー図である。
【図７】図７は、ヒントの通信の第２手法のフロー図である。
【図８】図８は、ヒントの処理のフロー図である。
【図９】図９は、ファイル・システム・ヒントの生成および通信の方法を示す。
【発明を実施するための形態】
【００１２】
以下に、添付の図面に示されている主題の実施形態について詳細に説明する。本発明の範囲は、特許請求の範囲により定められるものであり、代替、変更、および等価の様々な例は、本発明の範囲内にある。説明の明瞭性に関して、ここで説明する実施形態と関連する技術分野で知られている技術的材料は、説明を不明瞭にしないように、詳細に記載していない。
【００１３】
本発明の実施形態は、ヒンティング（hinting、ヒント提供）に関するものである。ヒンティングは、特定のホストまたはアプリケーションについての情報が低位レベル、例えば、低位レベルのストレージ・タイヤへ渡されることを可能とする。ヒンティングは、低位レベルでは入手できない情報が、キャッシング（caching、キャッシュ処理）をより効率的に実施するために使用されることを可能とする。例えば、ヒンティング情報は、キャッシングや自動タイヤリング（auto-tiering、自動階層化処理）を改善するために使用することができる。ヒンティングは、低位レベルへ渡される様々なメタデータ情報の加重平均（重み付け）を可能とする。更に、ヒンティングは、ファイル・システムやアプリケーションのデータ・アクセス・パターンを低位レベルへ渡すことを含む。それにより、低位レベルは、ヒンティングから得られたデータの特性に基づいて、より効率的または適切に動作を行うことや応答することができる。例えば、ヒントは、低位レベルのストレージ・コントローラ（例えば、ＭｅｇａＲＡＩＤ（登録商標）ストレージ・コントローラ）や、ドライバや、システムや、関連するソフトウェアやファームウェアに対してアドバイザ（助言情報）やディレクタ（指導情報）として供給される。
【００１４】
ヒンティングは、ファイル・システムに特定のヒンティング（特定ファイル・システム・ヒンティング）、および／またはアプリケーションに特定のヒンティング（特定アプリケーション・ヒンティング）を含む。特定ファイル・システム・ヒンティングは、他のアプリケーションから独立して行うことができる。特定アプリケーション・ヒンティングは、１以上の個別のアプリケーションからのサポートを含み得る。また、ヒンティング・ソリューションは、デフォルトのアプリケーションのヒンティング・アルゴリズム／機構をオーバーライドすることができるＡＰＩを露出させることができ、それらのＡＰＩは、アプリケーションが、より特定的なヒントを提供すること及びヒントについての制御をより良くすることを可能にする。更に、一組の一般的なＡＰＩを使用可能とし、アプリケーションがヒントを低位のレベルへ渡すためにＡＰＩを使用できるようにする。
【００１５】
本発明の実施形態は、ファイル・システムのアーキテクチャへアクセスし、ファイル・システムやファイル・システムのアーキテクチャを変更せずに、ファイル・システム・コンテキスト情報を得る。更に、本発明の実施形態は、ファイル・システム非依存型（agnostic）またはほぼ非依存型である。ファイル・システムに依存しない（ファイル・システムを認識しない）ことにより、本発明の実施形態は、ファイル・システムの特定のフォーマットや言語に依存せずに、様々なタイプのファイル・システムに対して動作することが可能とされる。更に、本発明の実施形態は、領域のアクセス・パターンおよびデータのタイプを考慮するので、アプリケーションのコンテキスト情報を得ることができる。従って、実装形態および実施形態は、ファイル・システム・ヒントおよびアプリケーション駆動のヒント（アプリケーション駆動ヒント）の双方または一方を生成して通信するように構成される。
【００１６】
図１は、現在実施されているシステム・トポロジ１００を示す。システム・トポロジ１００は、典型的には、ユーザ空間１１０およびカーネル空間１２０を含む。データベース／ユーザ・アプリケーション１１２は、典型的には、ユーザ空間１１０に存在する。データベース／ユーザ・アプリケーションは、ユーザ空間１１０からカーネル空間１２０へのＩ／Ｏリクエストを行う。データベース／ユーザ・アプリケーションのリクエストは、シーケンシャルまたは非シーケンシャルのＩ／Ｏリクエストを含むことができ、また、ランダムのＩ／Ｏリクエストを含むことができる。システム・トポロジの異なる実施形態では、ユーザ空間１１０に、更なるコンポーネントや、ハードウェアや、ソフトウェアや、層（レイヤ）を含む場合もある。
【００１７】
カーネル空間１２０は、ユーザ空間１１０の下で動作する。カーネル空間１２０は、ダイレクトＩ／Ｏ（direct I/O）１２２、システム・コール・インターフェース１２４、１以上の仮想ファイル・システム１２６、１以上のファイル・システム１２８、ブロック層１３０、複数のＬＢＡ（論理ブロック・アドレス）を含むリクエスト１３２、およびＳＣＳＩ層１４０を含む。システム・トポロジの別の実施形態では、カーネル空間１２０に、更なるコンポーネントや、ハードウェアや、ソフトウェアや、層（レイヤ）を含む場合もあり、例えば、ストレージ・コントローラ（例えば、１５２）およびストレージ・システム１５０を含む。
【００１８】
ダイレクトＩ／Ｏ１２２は、Ｉ／Ｏリクエストをブロック層１３０へ送る。Ｉ／Ｏリクエストは、特定のアプリケーションに関するデータを含み得る。
【００１９】
システム・コール・インターフェース１２４は、カーネル空間１２０で要求されたサービスのために、ユーザ空間１１０で実行されるアプリケーションとの間でコールやＩ／Ｏリクエストを送信や受信するように構成される。
【００２０】
仮想ファイル・システム１２６は、ファイル・システム（例えば、１２８）の最上部に抽象化層（アブストラクション・レイヤ）を備える。仮想ファイル・システム１２６は、複数の様々なタイプの物理ファイル・システム（例えば、１２８）を許容するように構成される。例えば、仮想ファイル・システム１２６は、ＶＭｗａｒｅの製品で実施できる。ファイル・システム１２８は、ファイルやデータを組織化するように構成される。ファイル・システム１２８はファイルおよびデータを含み、そのファイルおよびデータはメタデータを含み得る。ファイル・システム１２８は、Ｉ／Ｏリクエストをブロック層１３０へ送信し、ブロック層１３０のＩ／Ｏリクエストは、ユーザ・データ、ファイル・システム・メタデータ、他のデータ、および他のメタデータのうちの少なくとも１つを含む。
【００２１】
ファイル・システム層のファイル・システムおよび仮想ファイル・システム層の仮想ファイル・システムは、データ（例えば、ファイル）およびメタデータを含む。メタデータは、幾つかのデータ構造についての情報を含むことができる。ファイルは、ｉノード（インデックス・ノード）またはｖノード（仮想インデックス・ノード）と関連し得る。ｉノードまたはｖノードは、整数により識別できる。ｉノードまたはｖノードは、ファイルおよびディレクトリ（例えば、フォルダ）についての情報を記憶する。例えば、ｉノードまたはｖノードは、ファイル・タイプ、ファイル所有者、アクセス・モード（例えば、読出し（リード）、書込み(ライト)、許可など）などについての情報を含む。
【００２２】
ブロック層１３０は、ファイル・システム１２８およびダイレクトＩ／Ｏ１２２からＩ／Ｏリクエストを受信するように構成できる。同様に、ファイル・システム１２８およびダイレクトＩ／Ｏ１２２は、ブロック層１３０へアクセスするように構成される。ブロック層１３０は、ＳＣＳＩ層１４０と通信できるように接続される。ブロック層１３０は、ＳＣＳＩ層１４０を介してストレージ・システム１５０およびストレージ・コントローラ１５２へ１以上のリクエストを送信するように構成される。
【００２３】
ＳＣＳＩ層１４０は、ＳＡＳ（シリアル・アタッチドＳＣＳＩ）接続性（連結性）またはファイバ・チャンネル接続性を含む。ＳＣＳＩ層１４０は、ブロック層１３０をストレージ・システム１５０へ、通信できるように接続する。更に、ＳＣＳＩ層１４０は、複数のデバイスや層やシステム、例えば、ホスト・システム、ストレージ・システム、ストレージ・コントローラ、コントローラ、伸長器（エキスパンダ）、ストレージ・ネットワーク、コンピュータ・ネットワーク、他のブロック層などを、通信できるように接続する。
【００２４】
ストレージ・システム１５０は、１以上のストレージ・デバイス、例えば、ハード・ディスク・ドライブ（ＨＤＤ）やソリッド・ステート・デバイス（ＳＳＤ）の組み合わせを含むことができる。ストレージ・システム１５０は、ストレージ・コントローラ１５２を含む。ストレージ・システム１５０は、低位レベルのストレージ・システムであり得る。低位レベルのストレージ・システムは、ＲＡＩＤストレージ・システムおよびＲＡＩＤタイヤード（tiered、階層化された）・ストレージ・システムを含むことができる。
【００２５】
ストレージ・システム１５０は、統合された、または統合可能な、または接続された、または関連したストレージ・コントローラ１５２を含む。ストレージ・コントローラ１５２は、読出し／書込み（リード／ライト）のＩ／Ｏリクエストの送信および受信などのようなストレージ・タスクを、効率的に処理、転送、調整、および管理するように構成される。ストレージ・コントローラは、コンピュータ読出可能な記録媒体に記録されたコードを含むソフトウェアやファームウェアを含む。ストレージ・コントローラのソフトウェアやファームウェアは、ストレージ・コントローラ・タスクを実行および処理するように構成される。
【００２６】
図２は、ヒント・エンジン２６０を含むシステム・トポロジ２００を示す。図１の場合と同様に、システム・トポロジ２００は、ユーザ空間１１０、カーネル空間１２０、データベース／ユーザ・アプリケーション１１２、ファイル・システム１２８、ブロック層１３０、ＳＣＳＩ層１４０、ストレージ・システム・ドライバ１４２、ストレージ・システム１５０、およびストレージ・コントローラ１５２を含む。更に、ファイル・システム１２８は、ファイル・システムｉノード（インデックス・ノード）キャッシュ２２９Ａおよびバッファ・キャッシュ２２９Ｂを含む。また、システム・トポロジ２００は、ヒント・エンジン２６０を含む。
【００２７】
好適な実施形態では、ストレージ・システム１５０は、タイヤード・ストレージ・システムまたはタイヤードＲＡＩＤ（Redundant Array of Independent Disks）ストレージ・システムを含み、例えば、ＭｅｇａＲＡＩＤ（登録商標）ストレージ・システムを含む。タイヤード・ストレージ・システムまたはタイヤードＲＡＩＤストレージ・システムは、１以上のＨＤＤや、１以上のＳＳＤや、１以上の他のストレージ・デバイスを含む。タイヤード・ストレージ・システムまたはタイヤードＲＡＩＤストレージ・システムは、更に、１以上のメモリ、１以上のキャッシュ、および１以上のプロセッサ、ならびにソフトウェアやファームウェアを含む。好適な実施形態では、ストレージ・コントローラ１５２は、ＭｅｇａＲＡＩＤ（登録商標）ＣａｃｈｅＣａｄｅソフトウェアの１つのバージョン（例えば、ＭｅｇａＲＡＩＤ（登録商標）ＣａｃｈｅＣａｄｅ  Ｐｒｏ  ｖ．２．０）を実行するＭｅｇａＲＡＩＤ（登録商標）ＣａｃｈｅＣａｄｅストレージ・コントローラを用いて構成できる。更に、ストレージ・システム・ドライバやストレージ・コントローラ・ドライバ（例えば、１４２）は、ストレージ・コントローラ１５２やストレージ・システム１５０とインターフェースするように構成され、ストレージ・システム・ドライバ１４２は、ＳＣＳＩ層１４０と接続されたデバイスやシステムに存在する。代替例として、ストレージ・システム・ドライバ１４２は、ストレージ・コントローラ１５２に配置することもできる。ストレージ・システムおよびストレージ・コントローラは、タイヤード・ストレージ・システムに構成され、ホットな（重要な／アクセス頻度の高い）データは、ＳＳＤのようなアクセス速度の速いタイプのストレージに記憶され、コールドな（あまり重要でない／アクセス頻度の高くない）データは、ＨＤＤのようなアクセス速度があまり速くないタイプのストレージへ記憶されるようにする。
【００２８】
更に図２を参照する。ヒント・エンジン２６０は、ファイル・システム１２８の層からブロック層１３０へ渡されるＩ／Ｏリクエストからヒントを受信、導出、または傍受するように構成される。ヒント・エンジン２６０により傍受されてヒントの導出に用いられるＩ／Ｏリクエストは、ファイルの読み出し、書き込み、添付、削除、移動、コピーなどのリクエストを含む。ヒント・エンジン２６０は、ブロック層１３０の中または上に存在する。例えば、ヒント・エンジン２６０は、ファイル・システム１２８の層とブロック層１３０との間に存在する。ヒント・エンジン２６０は、ファイル・システム・コンテキスト情報に関してＩ／Ｏリクエストを検査するように構成される。ファイル・システム・コンテキスト情報は、例えば、ファイル・システム・メタデータ、ファイル・システム・アクセス・パターン、ファイル・システムｉノード（インデックス・ノード）、ファイル・システムｖノード（仮想インデックス・ノード）、ファイル・システム・スーパー・ブロック、特別な重要性および影響を有するか又はファイル・システムのレイアウトを反映するジャーナリング・ファイル・システム・ブロック（グループ記述子テーブル、ブロック・ビットマップ、ｉノード・ビットマップ、ｉノード・テーブルなど）のトランザクション・ログ、および特別な重要性および影響を有するか又はファイル・システムのレイアウトを反映するメタファイル（ｉノード・メタファイルなど）のうちの少なくとも１つを含む。
【００２９】
システム・トポロジ２００のデータベース／ユーザ・アプリケーション１１２は、読出し／書込みリクエストを用いてアプリケーション・ヒントを渡す。例えば、アプリケーションは、ユーザ空間１１０からカーネル空間１２０の層（例えば、ファイル・システム１２８の層、仮想ファイル・システム層１２６、システム・コール・インターフェース１２４、ブロック層１３０など）への読出し／書込みリクエストの送信中、送信前、または送信後にアプリケーション・ヒントを渡す。アプリケーション・ヒントは、読出し／書込みリクエストの一部として渡されるか、または、読出し／書込みリクエストの前または後に送信される１以上の別個の信号、送信、通知、またはメッセージで構成される。
【００３０】
図３は、フィルタ・ドライバ３００の実施形態を示す。フィルタ・ドライバ３００は、ヒント・エンジン２６０および通信コンポーネント３３０を含む。フィルタ・ドライバのヒント・エンジン２６０は、ファイル・システム・ヒント３１０およびアプリケーション駆動ヒント３２０のうちの少なくとも１つを導出するように構成される。
【００３１】
フィルタ・ドライバ３００、またはフィルタ・ドライバ３００のヒント・エンジン２６０は、ファイル・システム・ヒント３１０を生成するように構成される。フィルタ・ドライバ３００またはヒント・エンジン２６０は、ファイル・システム１２８から送信される読出し／書込みリクエストをスヌープ（監視）、傍受（インターセプト）、または受信することにより、ファイル・システム１２８から情報を得るように構成される。次に、ヒント・エンジン２６０は、ファイル・システム１２８から得た情報から、ファイル・システム・ヒント３１０を生成または導出する。
【００３２】
フィルタ・ドライバ３００、またはフィルタ・ドライバ３００のヒント・エンジン２６０は、アプリケーション駆動ヒントを生成するように構成される。ヒント・エンジン２６０またはフィルタ・ドライバ３００は、通信のためにアプリケーションが使用しているＩ／Ｏコントロール（ｉｏｃｔｌ）を決定すること又はＡＰＩ（アプリケーション・プログラム・インターフェース）を露出させることにより、アプリケーション駆動ヒント３２０を生成する。
【００３３】
フィルタ・ドライバは、ファイル・システム・ヒント３１０およびアプリケーション駆動ヒント３２０のうちの少なくとも１つをストレージ・システム（例えば、１５０）へ送るまたは渡すように構成された通信コンポーネント３３０を含む。通信コンポーネント３３０は、ストレージ・システム（例えば、１５０）へ、ヒント（即ち、ファイル・システム・ヒントおよび／またはアプリケーション駆動ヒント）のみを送るように、又は主にヒントを送るように構成される。代替例として、フィルタ・ドライバ３００の通信コンポーネント３３０は、ヒントを、通常のリクエスト（例えば、読出し／書込みのＩ／Ｏリクエスト）の一部として、または通常のリクエストに含めて送るように構成される。更には、通信コンポーネントは、ヒントをストレージ・システムへ送るまたは渡すように、および標準の読出し／書込みリクエストを送るまたはリレーするように構成することもできる。例えば、フィルタ・ドライバ３００の通信コンポーネント３３０は、ヒントを、読出し／書込みリクエストの前、最中、または後に、または読出し／書込みリクエスト内に含めて、送るまたは渡すように構成される。更に別の幾つかの実施形態では、Ｉ／Ｏリクエストのブロックの使用されていないフィールドへ、１以上のヒントが添付、挿入、注入、または配置され、それにより、１以上のヒントを、Ｉ／Ｏリクエストの一部としてストレージ・システム（例えば、１５０）へ渡すまたは送る。
【００３４】
幾つかの実施形態では、Ｉ／Ｏリクエストに、使用されていないフィールドが無い場合や、適切なサイズまたは容量の使用されていないフィールドが無い場合、ヒントは、後続のメッセージでストレージ・システム１５０へ渡されるか、または後続のＩ／Ｏリクエストの使用されていないフィールドで渡される。ヒントが、後続のメッセージで渡される場合、または後続のＩ／Ｏリクエストの使用されていないフィールドに配される場合、ヒントは、関連するオフセット・インジケータを含むか、またはヒントにオフセット・インジケータが付随する。オフセット・インジケータは、ヒントの関連する読出しＩ／Ｏリクエストと、ヒントの関連する読出しＩ／Ｏリクエストからヒントをオフセットさせた（ずらせた）時間量またはＩ／Ｏリクエスト数とのうちの少なくとも１つを示す。次に、ストレージ・システムまたはストレージ・コントローラは、Ｉ／Ｏリクエストおよび関連するヒント（１以上）またはヒントの一部を受信したときに、後続の分離されていたヒントを、組立、結合、または関連させて適切なＩ／Ｏリクエストの形にする。
【００３５】
図４は、Ｉ／Ｏリクエストおよびファイル・システム・ヒントに関するフロー図を示し、このフロー図で示す処理は、ステップ４０１〜４０６で示すステップの幾つか又は全てを含む。以下に示すステップ４０１〜４０６の順序は例示的なものであり、幾つかの実施形態では、ステップ４０１〜４０６が異なる順序で行われることも、幾つかのステップが同時に行われることもあり得る。図４に示すように、フィルタ・ドライバ３００は、ファイル・システム１２８の層とブロック層１３０との間に配されることができる。
【００３６】
ステップ４０１は、ファイル・システム１２８がバッファまたはキャッシュ（例えば、ファイル・システムｉノード（インデックス・ノード）キャッシュ２２９Ａまたはバッファ・キャッシュ２２９Ｂ）からＩ／Ｏリクエストを発行するステップを含む。ステップ４０１は、更に、内部ヒント・エンジン（例えば、２６０）を含むフィルタ・ドライバ３００が、ファイル・システムから発行されたＩ／Ｏリクエストを傍受するステップを含む。
【００３７】
ステップ４０２において、Ｉ／Ｏリクエストは、ブロック単位でｉノード（インデックス・ノード）および／またはｖノード（仮想ファイル・システム（１以上）のインデックス・ノード）を参照するので、内部ヒント・エンジン（例えば、２６０）は、ｉノードおよび／またはｖノードのマッピングを行うことができる。このｉノードおよび／またはｖノードのマッピングは、特定のＩ／Ｏリクエストに関連する情報、またはファイル・システム１２８および／または仮想ファイル・システム（例えば、１２６）の重要な構造に関連する情報を提供する。更に、特定のＩ／Ｏリクエストに関連するｉノードおよび／またはｖノードは、少なくともＩ／Ｏリクエストが完了するまでは変わらないので、マッピングから得られる情報は、少なくともＩ／Ｏリクエストが完了するまでは正確性を維持する。
【００３８】
ステップ４０３において、フィルタ・ドライバ３００、またはフィルタ・ドライバの内部ヒント・エンジン（例えば、２６０）は、ファイル・システム１２８の層のｉノードおよび／またはｖノードの属性をルックアップするか、それにアクセスするか、またはそれをルックアップするリクエストを送信する。
【００３９】
ステップ４０４において、ファイル・システム層は、ファイル・システム１２８の層のｉノードおよび／またはｖノードの属性を送信して、フィルタ・ドライバ３００、またはフィルタ・ドライバ３００の内部ヒント・エンジン２６０に受信させる。ｉノード／ｖノードの幾つかの属性としては、ｉノード／ｖノード番号、ｉノード／ｖノード・フラグ、およびｉノード／ｖノード・タイプなどがある。
【００４０】
ステップ４０５において、内部ヒント・エンジン（例えば、２６０）は、例えばスーパー・ブロックなどのようなブロックの様々なフラグ、メタｉノード（メタインデックス・ノード）、およびメタｖノード（メタ仮想インデックス・ノード）を分析することにより、ヒント（例えば、ファイル・システム・ヒント）を生成する。メタｉノード／メタｖノードは、１つのファイル・システムがそのデータをより良く管理するために維持する内部ｉノード／ｖノードである。例えば、内部ヒント・エンジン（例えば、２６０）は、特定のブロックがスーパー・ブロックであるか否かを、その特定のブロックのフラグまたはブロック番号に基づいて検査および／または判別する。更に、例えば、内部ヒント・エンジン（例えば、２６０）は、特定のブロックがメタｉノードであるかメタｖノードであるかを、その特定のブロックのフラグに基づいて検査および／または判別する。次に、内部ヒント・エンジン（例えば、２６０）は、ｉノードおよび／またはｖノードの属性を分析した後に、ヒントを構築または生成する。
【００４１】
ステップ４０６において、フィルタ・ドライバ、またはフィルタ・ドライバの内部ヒント・エンジン、またはフィルタ・ドライバの通信コンポーネントは、生成したヒントを、ストレージ・システム・ドライバ（例えば、１４２）、またはストレージ・コントローラ（例えば、１５２）、またはストレージ・システム（例えば、１５０）へ、ＳＣＳＩ層（例えば、１４０）を介して送るまたは渡す。
【００４２】
更に図４を参照する。フィルタ・ドライバ３００、またはフィルタ・ドライバ３００のヒント・エンジン２６０は、ハッシュ・テーブル４１０を含む。フィルタ・ドライバ３００、またはフィルタ・ドライバ３００またはヒント・エンジン２６０は、ＬＢＡ（論理ブロック・アドレス）に対して、生成されたヒント（例えば、ファイル・システム・ヒント）を記憶するようにハッシュ・テーブル４１０を維持する。生成されたヒントは、生成されたときにハッシュ・テーブル４１０に記憶される。ハッシュ・テーブル４１０のエントリは、内部ヒント・エンジンが、ハッシュ・テーブル内の既存のエントリと関連する更なるヒントを生成したときに、または更なる情報を得たときに、更新される。
【００４３】
ファイル・システムのメタデータの幾つかのヒントは、スーパー・ブロックおよびメタファイルと関連する情報を含む。
【００４４】
スーパー・ブロックは、典型的には、一貫性を維持するために頻繁にフラッシュ（flushed）される。従って、スーパー・ブロックと関連するファイル・システム・メタデータ・ヒントは、非常に重要（ホット）であると見なされる。スーパー・ブロックは、典型的には、殆どのファイル・システムにわたって明確なものである。典型的に、スーパー・ブロックは、そのブロック番号から検出することができる。
【００４５】
メタファイルに関しては、全てまたは殆どのメタファイルが、特定のファイル・システムに対してのリザーブ（予約）されたｉノード番号を有するか、またはそれと関連付けされている。メタファイルは、典型的には大きくないが、大きいファイル・システムでは大きくなり得る。ファイル・システムが大きいメタファイルを含む状況では、フィルタ・ドライバまたはヒント・エンジンは、特定のメタファイル、例えば、ｉノード・マップ・メタファイルやブロック・マップ・メタファイルと関連するヒントのみを生成することを選択する場合もある。メタファイルと関連するファイル・システム・メタデータ・ヒントは、例えば、ｉノード・マップ・メタファイルやブロック・マップ・メタファイルを含む。メタファイル（例えば、ｉノード・マップ・メタファイルやブロック・マップ・メタファイル）と関連するファイル・システム・メタデータ・ヒントは、非常に重要であると見なされる。
【００４６】
ファイル・システムのＩ／Ｏと関連する幾つかのヒントは、置換書込み（replacement write）、リカバリ書込み、ブロック事前割り振り（pre-allocation）、および読出し（read）と関連する情報を含む。
【００４７】
置換書込みＩ／Ｏリクエストは、ストレージに対してのファイル・システム全体にわたる(file-system-wide)データ・フラッシュ中に、またはリソースを解放するためにデータが書き込まれるという可能性を示す書込強化（write hardening）中に、発生し得る。従って、ファイル・システムＩ／Ｏ関連のヒントはホットであるとみなされる。なぜなら、Ｉ／Ｏ（例えば、書込み）リクエストは、迅速に完了されるべきだからである。ブロック層へ渡されるフラグは、置換書込みを示す。
【００４８】
リカバリ書込みＩ／Ｏリクエストは、典型的には、クラッシュが発生する前にデータの持続性を保証するためにユーザによりトリガされるが、クラッシュした場合には、ヒントは供給されない。
【００４９】
アプリケーションは、後の使用のためにブロックを事前割り振りする。ブロック事前割り振りリクエストはコールドである（あまり重要ではない）と見なされる。なぜなら、事前割り振りリクエストは、追加モード（append mode）で出されるものであり、通常は、大量のブロックの割り振りが行われるからである。
【００５０】
読出しＩ／Ｏリクエストに関しては、典型的に、各ファイル・システムが、特定の最新状況（recency）ベースのアルゴリズムに従うバッファ・キャッシュを有するので、ヒントは、読出しＩ／Ｏリクエストに関連するデータには直ちにアクセスされないことを示す情報を含む。従って、読出しＩ／Ｏリクエストはコールドであると見なされる。
【００５１】
図５は、Ｉ／Ｏリクエストおよびアプリケーション・ヒントに関するフロー図を示し、このフロー図で示す処理は、ステップ５０１〜５０６で示すステップの幾つか又は全てを含む。図５に示すように、フィルタ・ドライバ（例えば、３００）は、カーネル空間１２０のファイル・システム１２８の層とブロック層１３０との間に配置される。フィルタ・ドライバは、外部ヒント・エンジン（例えば、５６０や２６０）を含むか、または内包するか、または外部ヒント・エンジンと関連付けられる。ユーザ空間１１０のデータベース／ユーザ・アプリケーション層（例えば、１１２）は、１以上のデータベース（例えば、５１４）、１以上のアプリケーション（例えば、５１６）、および１以上のＡＰＩ（アプリケーション・プログラミング・インターフェース）ライブラリ（例えば、５１２）を含む。
【００５２】
ステップ５０１は、アプリケーションまたはデータベースがＩ／Ｏリクエストを送信するためにＡＰＩライブラリ５１２を用いる（例えば、アクセスしたり、インターフェースしたりする）ことを含む。更には、幾つかのデータベースは、ブロック構造の既存の知識を用いて構成され、そのブロック構造の既存の知識を持つデータベースが、ブロック層（例えば、１３０）とダイレクトＩ／Ｏを実行するように構成されるようにする。他のデータベースは、ブロック構造の既存の知識を有さない。他方、アプリケーションは、典型的には、ブロック構造の既存の知識を有さない。
【００５３】
ステップ５０２において、１以上のＩ／Ｏコントロール（ioctl）コールが、ドライバ（例えば、フィルタ・ドライバ（例えば、３００）やストレージ・システム・ドライバ（例えば、１４２））へ送られる。Ｉ／Ｏコントロール・コールは、デバイス固有Ｉ／Ｏ処理のためのシステム・コールであり得る。例えば、Ｉ／ＯコントロールまたはＩ／Ｏコントロール・インターフェースは、ユーザ空間（例えば、１１０）がデバイス・ドライバ（例えば、ストレージ・システム・ドライバ１４２やフィルタ・ドライバ３００）と通信するために用いられる１つのシステム・コールを含む。更に、Ｉ／Ｏコントロールを介してデバイス・ドライバへ送られたリクエストは、Ｉ／Ｏコントロール・システム・コールに対して向けられたものであり、Ｉ／Ｏコントロール・システム・コールは、デバイスに対するハンドルとリクエスト番号とを含む。
【００５４】
ステップ５０３において、フィルタ・ドライバ（例えば、３００）またはフィルタ・ドライバの外部ヒント・エンジン（例えば、５６０や２６０）は、Ｉ／Ｏコントロールを処理する。また、外部ヒント・エンジン（例えば、５６０や２６０）は、Ｉ／Ｏコントロール自体を記憶するか、またはＩ／Ｏコントロールの処理から得た情報を記憶する。Ｉ／Ｏコントロールと関連する情報は、後の使用のために記憶される。例えば、Ｉ／Ｏコントロールと関連する情報は、後の使用のためにハッシュ・テーブル（例えば、５１０や４１０）に記憶される。
【００５５】
ステップ５０４において、フィルタ・ドライバ（例えば、３００）またはフィルタ・ドライバ（例えば、３００）の外部ヒント・エンジン（例えば、５６０や２６０）は、Ｉ／Ｏリクエストを受信する。Ｉ／Ｏリクエストの受信に応じて、またはＩ／Ｏリクエストを受信したときに、外部ヒント・エンジン（例えば、５６０や２６０）は、ユーザにより提供された情報をルックアップするか又はその情報にアクセスする。次に、外部ヒント・エンジン（例えば、５６０や２６０）は、そのユーザ提供情報を分析して、１以上のヒント（例えば、アプリケーション駆動ヒント）を生成する。外部ヒント・エンジン（例えば、５６０や２６０）は、生成された１以上のヒントをハッシュ・テーブル（例えば、５１０や４１０）に記憶する。
【００５６】
ステップ５０５において、外部ヒント・エンジン（例えば、５６０や２６０）は、ファイル・システムのヒント機構に対しフォールバック処理（fallback）を行うか否かを決定する。外部ヒント・エンジン（例えば、５６０や２６０）が、受信したユーザ提供情報が不十分（例えば、ユーザにより提供された情報が無い場合や、提供された情報が非常に少ない場合など）なのでヒントを生成することができないと判断した場合、外部ヒント・エンジン（例えば、５６０や２６０）は、ヒント・エンジンに、特定のＩ／Ｏリクエスト（ｉｏｃｔｌ）と関連するファイル・システム・ヒント機構（例えば、ファイル・システム・ヒントを生成するように構成されたフィルタ・ドライバの内部ヒント・エンジン）に対しフォールバック処理を行うことを決定する。同様に、外部ヒント・エンジン（例えば、５６０や２６０）は、ユーザ提供情報からヒントを生成できる場合や、適切なまたは関連するファイル・システム・ヒント機構が無い場合、ファイル・システム・ヒント機構にフォールバック処理を行わないことを決定する。更に、外部ヒント・エンジンは、ユーザ提供情報から生成されたヒントの有用性が比較的低いと決定または判定することができ、その場合、ユーザ提供情報から生成されたヒントを、ファイル・システム・ヒント機構により生成されたファイル・システム・ヒントを用いて補足または増強することを決定することができる。幾つかの実施形態では、可能であれば（例えば、ファイル・システム・ヒントと、関連するアプリケーション駆動ヒントとが存在する場合）、外部ヒント・エンジンは、常にまたはほぼ常に、ユーザ提供情報から生成されたヒントを、ファイル・システム・ヒント機構により生成されたファイル・システム・ヒントを用いて補足または増強することを選択する。他の実施形態では、外部ヒント・エンジンは、特定のファイル・システム・ヒントが特定のアプリケーション駆動ヒントの価値や有用性に寄与する場合又は特定のアプリケーション駆動ヒントに価値や有用性を付加する場合のみ、補足または増強することを選択する。
【００５７】
ステップ５０６において、ヒントを、ストレージ・システム・ドライバへ送る又は渡す。フィルタ・ドライバ、またはフィルタ・ドライバの外部ヒント・エンジン、またはフィルタ・ドライバの通信コンポーネントは、生成されたヒントを、ストレージ・システム・ドライバ（例えば、１４２）、またはストレージ・コントローラ（例えば、１５２）、またはストレージ・システム（例えば、１５０）へ、ＳＣＳＩ層を通じて送るまたは渡す。
【００５８】
更に図５を参照する。フィルタ・ドライバ（例えば、３００）、またはフィルタ・ドライバ（例えば、３００）の外部ヒント・エンジン（例えば、５６０や２６０）は、ハッシュ・テーブル（例えば、５１０や４１０）を含む。フィルタ・ドライバ（例えば、３００）、またはフィルタ・ドライバ（例えば、３００）の外部ヒント・エンジン（例えば、５６０や２６０）は、ＬＢＡ（論理ブロック・アドレス）に対して、生成されたヒント（例えば、ファイル・システム・ヒント）を記憶するようにハッシュ・テーブル（例えば、５１０や４１０）を維持する。生成されたヒントは、生成されたときにハッシュ・テーブル（例えば、５１０や４１０）に記憶される。ハッシュ・テーブル（例えば、５１０や４１０）のエントリは、外部ヒント・エンジンが、ハッシュ・テーブル内の既存のエントリと関連する更なるヒントを生成したときに、または更なる情報を得たときに、更新される。
【００５９】
幾つかの特定アプリケーション・ヒント（アプリケーションに特定のヒント）は、特定のファイルをホットまたはコールドと定めることや、ブロックを通じてアプリケーションのホットなデータを定めることや、実際のＩ／Ｏの前にコンテキストを設定または設定解除することに関連する情報を含む。
【００６０】
特定のファイルをホットまたはコールドと定めることに関して、ＡＰＩは、含まれるデータがホットまたはコールドであるファイル名または特定の拡張部（エクステンション）を持つファイル名を取得する。特定アプリケーション・メタデータ（アプリケーションに特定のメタデータ）を定義することは非常に有用である。パス名は、ヒンティングのためにｉノード番号へと変換できる。
【００６１】
ブロックを通じてのアプリケーションのホットなデータを定めることに関して、ＡＰＩは、ホットまたはコールドのデータとして記述することができる１つの範囲のブロックを取得する。ブロックを通じてアプリケーションのホットなデータを定めることは、アプリケーションがブロックの知識を有することが重要な場合において有用である。ヒンティングは、一組のブロック番号を含むことができる。
【００６２】
実際のＩ／Ｏの前にコンテキストを設定または設定解除することに関して、コンテキストを設定／設定解除することは、後に来るＩ／Ｏがホットまたはコールドであることを言及し得る。これは、データを記憶する際に、スタンドアローン・アプリケーションからなるアプリケーションに関して有用であり、また、Ｉ／Ｏの前にユーザがそのデータの重要度を定義するときに有用である。ヒンティングは、少なくとも１つのプロセス識別番号を含むことができる。
【００６３】
更に、ファイル・システム・ヒント（例えば、上記のファイル・システム・ヒント）は、アプリケーション駆動のヒンティングと関連して使用でき、また、アプリケーション駆動のヒンティングの有効性を向上させるために使用できる。アプリケーション駆動のヒンティングは、アプリケーションに急造されるヒンティングを含む。このアプリケーション急造ヒンティング(application improvised hinting)は、１以上のＡＰＩを露出させること、およびファイル・システム・ヒントから導出された情報を組み込むためにデフォルトのヒンティング機構をオーバーライドすることを含む。アプリケーション急造ヒンティングは、ファイル・システム・ヒントの受信や、ファイル・システム・ヒントへのアクセスや、ファイル・システム・ヒントを含むハッシュ・テーブルへのアクセスを通じて、実施できる。アプリケーション急造ヒンティングは、ファイル・システム・ヒントを含むハッシュ・テーブルへのアクセス、およびファイル・システム・ヒントに基づく１以上のアプリケーション駆動ヒントの生成を含む。
【００６４】
図６および図７は、ヒントをヒンティング・フィルタ・ドライバ６１０からストレージ・システム１５０へ通信するための幾つかの方法を示すフロー図を示す。図６および図７は、ヒンティング・フィルタ・ドライバ６１０、ブロック層１３０、およびブロック層１３０からＳＣＳＩ層１４０へのリクエスト１３２（複数のＬＢＡを含む）を示す。ヒンティング・フィルタ・ドライバ６１０は、前述のフィルタ・ドライバ（例えば、３００）の機能またはフィルタ・ドライバ自体を含む。ヒンティング・フィルタ・ドライバ６１０は、ブロック層１３０の上に存在することができる。ヒンティング・フィルタ・ドライバは、内部ヒント・エンジンや外部ヒント・エンジン（例えば、５６０や２６０）などのような１以上のヒント・エンジンの機能を含むか、ヒント・エンジンを内包するか、ヒント・エンジンにより構成されるか、またはヒント・エンジンと関連する。
【００６５】
図６および図７において、ヒンティング・フィルタ・ドライバ６１０は、内部入力や外部入力からヒントを生成するときに用いられる情報を受信する。例えば、内部入力は、ファイル・システムから受信したＩ／Ｏリクエストを含み、内部入力は、内部ヒント・エンジンを用いてのファイル・システム・ヒントの生成において使用される。また、例えば、外部入力は、ユーザ空間のデータベースまたはアプリケーションから受信したＩ／Ｏコントロール（ｉｏｃｔｌ）を含み、外部入力は、外部ヒント・エンジンを用いてのアプリケーション駆動ヒントの生成において使用される。
【００６６】
図６は、ヒントをヒンティング・フィルタ・ドライバ６１０からストレージ・システム１５０へ通信する第１手法を示す。第１手法では、ヒンティング・フィルタ・ドライバ６１０は、１以上のヒントを、１以上のブロックの１以上の存在する不使用のフィールドへ添付し、次に、ヒントおよびブロックを共にしてＩ／Ｏリクエスト（例えば、書込みリクエスト）の一部とし、ストレージ・システム・ドライバ１４２や、ストレージ・コントローラ１５２や、ストレージ・システム１５０へ、ＳＣＳＩ層１４０を介して通信する。例えば、ファイル・システム・ヒントは、ストレージ・システム・ドライバへ送られるブロックの不使用フィールドに添付されることにより、ヒンティング・フィルタ・ドライバ６１０からストレージ・システム・ドライバ（例えば、１４２）へ渡される。次に、ストレージ・システム・ドライバは、Ｉ／Ｏリクエストの一部としてブロックの不使用フィールドに添付されたヒントを受信する。次に、ストレージ・システム・ドライバ１４２は、ヒントをＩ／Ｏフレームのフィールドに添付し、ヒントの添付されたＩ／Ｏフレームをストレージ・コントローラ１５２やストレージ・システム１５０へ渡す。本発明の幾つかの実施形態では、ストレージ・システム・ドライバ１４２は、メッセージ・パッシング・テクノロジ（ＭＰＴ、message passing technology）を用いて通信するように構成されたストレージ・ドライバを含む。第１手法の利点は、ヒントがデータと共にあることである。
【００６７】
ヒンティング・フィルタ・ドライバから特定のヒントを通信することを実施するにあたり、幾つかの実施形態は、第１手法を変更したものや、第１手法をハイブリッド化したものや、第１手法の代替的なものを含む。例えば、特定のヒントの通信のための幾つかの実施形態は、ヒントを関連させるべきリクエストのブロックが、不使用フィールドを有さない場合や、適切なサイズの不使用フィールドを有さない場合には、ヒントを、後のリクエストにおけるブロックの不使用フィールドへ添付することを含む。Ｉ／Ｏリクエストが、不使用フィールドを有さない場合や、適切なサイズ（容量）の不使用フィールドを有さない場合、ヒントは、ストレージ・レベルへ、後のリクエストを用いて渡されるか、または後続のＩ／Ｏリクエストの不使用フィールドを用いて渡される。ヒントが後続のメッセージとして渡されるとき、またはヒントが後続のＩ／Ｏリクエストの不使用フィールド内に配されるとき、ヒントが関連するオフセット・インジケータを含むか、またはヒントにオフセット・インジケータが付随する。オフセット・インジケータは、ヒントの関連する読出しＩ／Ｏリクエストと、ヒントの関連する実際の読出しＩ／Ｏリクエストからヒントをオフセットさせた（ずらせた）時間量またはＩ／Ｏリクエスト数とのうちの少なくとも１つを示す。次に、ストレージ・システムまたはストレージ・コントローラは、Ｉ／Ｏリクエストおよび関連するヒント（１以上）またはヒントの一部を受信したときに、後続の分離されていたヒントを、組立、結合、または関連させて適切なＩ／Ｏリクエストの形にする。
【００６８】
図７は、ヒントをヒンティング・フィルタ・ドライバ６１０からストレージ・システム１５０へ通信する第２手法を示す。第２手法では、ヒンティング・フィルタ・ドライバは、Ｉ／Ｏリクエストとヒントとを分離してストレージ・システム・ドライバ１４２やストレージ・コントローラ１５２やストレージ・システム１５０へ送信する。幾つかの実施形態では、ヒンティング・フィルタ・ドライバは、Ｉ／Ｏリクエストをストレージ・レベルへ送信し、次に、ヒンティング・フィルタ・ドライバは、Ｉ／Ｏリクエストと関連するヒントに関してのストレージ・レベルからのリクエストを受信するのを待ち、次に、ヒンティング・フィルタ・ドライバは、ストレージ・レベルからヒント・リクエストを受信すると、ヒントをストレージ・レベルへ送信する。即ち、ヒンティング・フィルタ・ドライバ６１０は、ストレージ・システム・ドライバ１４２やストレージ・コントローラ１５２やストレージ・システム１５０から要求された場合に、ヒントを、ストレージ・システム・ドライバ１４２やストレージ・コントローラ１５２やストレージ・システム１５０へ、ＳＣＳＩ層１４０を介して送信する。従って、ストレージ・システム・ドライバ１４２は、Ｉ／Ｏリクエストを受信するように構成され、また、ヒンティング・フィルタ・ドライバ６１０へヒントを要求するためのコールを送信するように構成される。ヒントおよび関連するＩ／Ｏリクエストを受信すると、ストレージ・システム・ドライバ１４２は、ヒントをＩ／Ｏフレームのフィールドに添付し、ヒントの添付されたＩ／Ｏフレームをストレージ・コントローラ１５２やストレージ・システム１５０へ渡す。幾つかの実施形態では、ストレージ・システム・ドライバ１４２は、ＭＰＴの１つのバージョンのものを用いて通信するように構成されたストレージ・ドライバを含む。第２手法は、不使用または余分なフィールドを有するＩ／Ｏリクエストのブロックに依存する必要がない。
【００６９】
図８は、ヒント処理と関連するフローチャートを示す。ヒント処理は、ストレージ・レベルで、ハードウェアやファームウェアやソフトウェアにより行われるものであり、ヒント処理用のコンポーネントやモジュール、例えば、ストレージ・システム・ドライバ１４２やストレージ・コントローラ１５２やストレージ・システム１５０などにより行われる。好適な実施形態では、ヒント処理は、ストレージ・コントローラ１５２のファームウェアにより行われる。ヒント処理においてヒントを受信すると、ヒント処理用コンポーネントは、ヒントを処理するために方法８００を行う。方法８００は、ステップ８１０、８２０、８３０、８３１、８４０、８４１、８５０、８５１、および８６０の幾つかまたは全てを含むように構成できる。
【００７０】
ステップ８１０は、ヒント処理用のコンポーネントまたはモジュールが、ヒントを処理すべきか無視すべきかについての検査および／または判定を行うことを含む。ヒント処理用のコンポーネントまたはモジュールが、ヒントを無視せずに処理すべきであると判断した場合、処理はステップ８２０へ進む。ヒント処理用のコンポーネントまたはモジュールが、ヒントを無視すべきであると判断した場合、処理はステップ８６０へ進み、通常のＩ／Ｏリクエスト・ストレージ・アルゴリズムを行う。
【００７１】
ステップ８２０は、特定のヒントの重要性または「ホット度合い」を判定するために、そのヒントを見るまたは分析することを含み、ヒント処理用のコンポーネントまたはモジュールは、ステップ８３０、８３１、８４０、８４１、８５０、および８５１の少なくとも１つを通じて、または図８に示していない重要性または「ホット度合い」の更なる判定手法を通じて、特定のヒントに対するヒート・マップ・インデックス値を設定することができる。
【００７２】
ステップ８３０において、ヒント処理用のコンポーネントまたはモジュールが、特定のヒントが非常に重要であると判定した場合、即ち、「非常にホット」であると判定した場合、ステップ８３１において、ヒント処理用のコンポーネントまたはモジュールは、特定のヒート・インデックス値を非常に大きい数に設定し、その特定のヒントと関連する１以上のブロックを配置し、その特定のヒントと関連する１以上のブロックを結び付ける（pin）。
【００７３】
ステップ８４０において、ヒント処理用のコンポーネントまたはモジュールが、特定のヒントが重要である、即ち、「ホット」であると判定した場合、ステップ８４１において、ヒント処理用のコンポーネントまたはモジュールは、特定のヒート・インデックス値を程々に大きい数に設定し、その特定のヒントと関連する１以上のブロックを固定する。
【００７４】
ステップ８５０において、ヒント処理用のコンポーネントまたはモジュールが、特定のヒントがあまり重要ではないと判定した場合、即ち、「コールド」であると判定した場合、ステップ８５１において、ヒント処理用のコンポーネントまたはモジュールは、特定のヒート・インデックス値を非常に小さい数に設定し、その特定のヒントと関連する１以上のブロックを、速度の低いストレージ位置（低速のストレージ・デバイス）に配置する。
【００７５】
ステップ８３０、８３１、８４０、８４１、８５０、および８５１は例示であり、特定のヒート・インデックス値は、任意の範囲の整数または非整数の値に設定することができる。
【００７６】
ステップ８３０、８３１、８４０、８４１、８５０、および８５１の少なくとも１つを完了した後、処理はステップ８６０へ進み、通常のＩ／Ｏリクエスト・ストレージ・アルゴリズムを行う。
【００７７】
図９は、ヒントの生成および通信に関連する実施形態の方法９００を示す。実施形態である方法９００は、フィルタ・ドライバや、計算デバイス（例えば、フィルタ・ドライバのプロセッサ）で実行されるソフトウェアやファームウェアや、ヒント・エンジンや、他の計算デバイスや、他のコンピュータ・コンポーネントにより、または他のソフトウェアやファームウェアやミドルウェアにより、行われることを意図されたものである。方法９００は、ステップ９１０、９２０、９３０、９４０、９５０、９６０、および９７０の幾つかまたは全てを含むことができ、また、発明の詳細な説明の中で説明したステップを更に含むこともできるが、それに関してはこの段落で明示しない。更に、方法９００のステップは、同時にまたは非シーケンシャルな順に行うこともできる。方法９００はステップ９１０を含み、ステップ９１０は、ファイル・システム層からＩ／Ｏリクエストを受信することを含む。方法９００はステップ９２０を含み、ステップ９２０は、ファイル・システム・コンテキスト情報に関してＩ／Ｏリクエストを検査することを含む。ファイル・システム・コンテキスト情報に関してＩ／Ｏリクエストを検査することは、ファイル・システム・コンテキスト情報に関して、Ｉ／Ｏリクエストの少なくとも１つのブロックのフラグ、状態（例えば、ｉノードの状態（ステート））、およびフィールド（ｉノードのフィールド）のうちの少なくとも１つを検査することを含む。方法９００はステップ９３０を含み、ステップ９３０は、ファイル・システム・コンテキスト情報の属性を判定するためにファイル・システム層へアクセスすることを含む。方法９００はステップ９４０を含み、ステップ９４０は、ファイル・システム層からファイル・システム・コンテキスト情報の属性を受信することを含む。方法９００はステップ９５０を含み、ステップ９５０は、ファイル・システム・コンテキスト情報の属性を分析することを含む。方法９００はステップ９６０を含み、ステップ９６０は、ファイル・システム・コンテキスト情報の属性の分析に基づいて少なくとも１つのヒントを生成することを含む。少なくとも１つのヒントは、Ｉ／Ｏリクエストのデータが相対的に高速の記録媒体に記憶されるべきかまたは相対的に低速の記録媒体に記憶されるべきかを決定するための、Ｉ／Ｏリクエストのデータの相対的な重要度を示す。方法９００はステップ９７０を含み、ステップ９７０は、少なくとも１つのヒントを低位レベルのストレージ・タイヤへ送信することを含む。また、方法は、アプリケーションから渡されるデータの重み付けを提供する機構を使用することを含む。
【００７８】
本発明および本発明による利点は上記の説明が理解できる。更には、本発明の精神および範囲から外れることなく、また、本発明の本質的な利点を犠牲にすることなく、本発明のコンポーネントの形態、構成、および配置における様々な変更が可能であることは明らかである。上記の説明における形態は、本発明の例示的な実施形態であり、特許請求の範囲に記載した発明は、様々な変更がなされた形態のものも含まれることを意図している。
【図１】
0005710673.tif 000002
【図２】
0005710673.tif 000003
【図３】
0005710673.tif 000004
【図４】
0005710673.tif 000005
【図５】
0005710673.tif 000006
【図６】
0005710673.tif 000007
【図７】
0005710673.tif 000008
【図８】
0005710673.tif 000009
【図９】
0005710673.tif 000010