JP2007287147A - 高速ファイル属性検索 - Google Patents

Abstract

【課題】 大型データ記憶装置に合わせて良好にスケールするファイル検索技法が必要である。
【解決手段】 データ記憶装置のファイルシステムイメージの生成またはアクセスの過程を含む、特定属性基準によりファイル検索を実行する方法を提供する。このとき、ファイルシステムイメージの実質的にシーケンシャルなスキャンを実行することができる。スキャンに基づき、特定属性基準を有するファイルシステムイメージ上のｉノードのリスト（特定属性ｉノードマップと呼ばれる）を構築することができる。このシーケンシャルスキャンは、ｉノードの読取りに掛かる総時間を劇的に削減する。このとき、リスト中のｉノードにマッチする（ファイルツリー中の）ｉノードを見つけるために、データ記憶装置のファイルツリーをウォークすることができる。このようにして、マッチするｉノードに対応するファイルのリストをすぐに簡単に作成することができる。
【選択図】 図４

Description

本発明は、データ記憶装置における特定の属性基準セットにマッチするファイルの検索に関する。属性基準の例としては、ファイル更新日時、サイズ、所有権、パーミッション（許可属性）を挙げることができる。

大型データ記憶装置中のファイルへのアクセスに、多大な時間を要することがあり得る。例えば、最も一般的な磁気ディスクドライブを含むデータ記憶装置を考えてみよう。このディスクドライブには、回転磁気プラッタが組み込まれかつプラッタ表面に物理的に接することなく読み書きヘッドが装着された構造を含めることができる。それゆえ、２つの待ち時間（レイテンシ）、即ち、プラッタを正しい位置へスピンさせる第１の待ち時間及びヘッドの位置を変える（かつ異なるトラックへ移動させる）第２の待ち時間は、このディスクドライブの読取りと関係がある。

このため、ある特定のファイルに関連する読取時間は、ディスクドライブ上の最終読取ファイルの位置に左右される。つまり、２つのファイルがディスクドライブ上に近接して位置していれば、第２のファイルの読取時間は比較的短い。これに対して、２つのファイルがディスクドライブ上に遠く離れて位置していれば、第２のファイルの読取時間は比較的長い。

典型的なディスクドライブにおいては、最初にファイルがネーミング階層における自身の場所に基づいて作成される。しかし、ファイルが更新または削除されると、ファイルの順序は、ディスクドライブ上の利用可能な空間にますます左右される。さらに、ラージファイルは、異なる位置に格納される複数のファイルに分割される必要があることがある。

データ記憶装置は、各ファイルへの書込み及び読出しを容易にするように全てのファイルへの参照を格納しなければならない。これらの参照には、識別ノード（ｉノード）と呼ばれるメタデータ構造が含まれる。とりわけ、各ファイルは、対応付けられたｉノードを有する。

図１は、簡略化されたｉノード１００を示す。ｉノード１００は、そのｉノード番号１０１を識別し、かつメタデータ１０２及びディスクアドレス１０３を含む。メタデータ１０２は、複数のファイル属性、例えば、最終更新日時、ファイルサイズ、所有権、パーミッションなどを含むことができる。ディスクアドレス１０３は、ディスクドライブ１０５におけるデータブロックの物理的な位置を識別する。このデータブロックには、ｉノード１００に対応するファイルが含まれる。この例では、ディスクアドレス１０３は、データブロック１０４を識別する。

論理的には、これらのｉノードが作成された後、そのようなｉノードへの参照も生成されなければならない。従来のデータ記憶装置は、ユーザディレクトリを用いてファイル名をｉノード番号にマップする。図２は、複数のファイルレコード２０２〜２０４を含む簡略化されたユーザディレクトリ２０１を示す。ディレクトリは、自身が包含するレコードのリストを格納するために図１に描かれたのと同じ構造を用いる特殊な型のファイルであることに留意されたい。模範的なファイルレコード２０２には、ファイル名２０５及びｉノード番号２０６が含まれる。ある１つのｉノード番号は、１つのｉノードのみを参照することに留意されたい。

各ファイルは、ただ１つのｉノード番号（及び、上に述べたようにただ１つのｉノード）しか有しないが、ある１つのファイルが複数の名前を有することはあり得る。例えば、Ｅメールのためのデータ記憶装置であって、各受信Ｅメールが、受信者に関連付けられたファイルを作成するものを考えてみよう。このデータ記憶装置において、ある１通のＥメールが複数のユーザ、例えばボブとスーザンに送信されるとすれば、そのＥメールは、ボブに対しては「1.」と名付けられ、それによって、これが所定時間内におけるボブ宛ての１番目のＥメールであることを示することがある。その一方、この同じＥメールは、スーザンに対して「6.」とラベルを付けられ、それによって、これが同一所定時間内におけるスーザン宛ての６番目のＥメールであることを示すことがある。しかし、ボブ及びスーザンの両者に送信されたＥメールは同じなので、ただ１つのｉノード番号（及び、上に述べたように１つのｉノード）だけしかデータ記憶装置に保存される必要がない。

従来のデータ記憶装置は、「ファイルツリー」を用いてユーザディレクトリを編成する。図３は、ファイルツリー３００（データ記憶産業においてはネーミング階層とも呼ばれる）を示す。ファイルツリー３００の第１のレベル、即ちレベル３０１には、ハイレベルディレクトリ（即ち「/」）が含まれる。レベル３０１は、ツリー階層において「ルート」とも呼ばれる。ＵＮＩＸ（登録商標）ファイルシステムの典型的な実施形態において、このハイレベルディレクトリは、ｉノード番号「２」を有する（即ち、「０」及び「１」は用いられない）。

ファイルツリー３００の第２のレベル、即ちレベル３０２には、ユーザディレクトリが含まれる。この場合は、ボブのディレクトリ（即ち「A」）、スーザンのディレクトリ（即ち「B」）、パットのディレクトリ（即ち「C」）の３つのユーザディレクトリが示されている。各ユーザディレクトリは、そのユーザディレクトリが作成されたときに生成されたｉノード番号も有することに留意されたい。それゆえ、ユーザディレクトリ「A」はｉノード番号「２０」を有することがあろうが、ユーザディレクトリ「B」はｉノード番号「１２０」を有することがあろう。レベル３０２の各ユーザディレクトリは、ネーミング階層において「ブランチ」と呼ばれる。

ファイルツリー３００の第３のレベル、即ちレベル３０３には、ユーザディレクトリ内のファイルが含まれる。この実施形態において、ユーザディレクトリAにはファイル名a.、b.、c.が含まれ、ユーザディレクトリBにはファイル名1.、2.、3.、4.、5.、6.が含まれ、ユーザディレクトリCにはファイル名a.及びb.が含まれる。ファイル及びユーザディレクトリの名前は、任意のサポートされている文字セットを用いてユーザまたはアプリケーションによって指定されることがあることに留意されたい。いずれにせよ、命名規則は各ユーザディレクトリと矛盾しない。上述のように、異なる名前（例えば、ボブには/A/a.、スーザンには/B/6.）を有するファイルが、同じｉノード番号を有することがある。ファイルツリー３００において用いられているファイル名は、（ユーザ割り当ての名前ではなく）システムが作り出す名前を用いるＥメール記憶装置において典型的なものである。レベル３０３の各ファイルは、ツリー階層において「リーフ」と呼ばれる。

ファイルツリー３００は典型に過ぎないことに留意されたい。データ記憶装置におけるファイルツリー３００の実際の形式は、典型的な場合では図２に示されているものに従うことになろう。例えば、ルートレベルでのディレクトリは、レコードとして示されているユーザディレクトリによっても同様に示されることができる。上に述べたように、ファイルツリー３００の各レコードは（即ちレベル３０１、３０２、３０３で）、ｉノード番号を含むことにもなろう。しかし、そのようなｉノード番号は、簡単のために図３には示されていない。

データ記憶装置における１つの典型的なアクセスは、所定の時刻／日付以後作成された全てのファイルを調べることを要求することである。Ｅメール記憶装置の中で、そのような要求は、昨日以後来た全てのＥメールに対するものであるかもしれない。ＵＮＩＸ（登録商標）ファイルシステムにおいては、「探索」ユーティリティツールがこの要求をインプリメントすることができる。

従来のインプリメンテーションにおいては、検索は、レベル３０１で始まり、その後レベル３０２での各ブランチからレベル３０３でのリーフへと下方にウォークする。具体的には、ハイレベルディレクトリ及びユーザレベルディレクトリにおけるレコードの順序に基づいてスキャンを実行することができる。例えば、ハイレベルディレクトリにおけるレコードの順序が「A」、「B」、「C」であると仮定すると、先ず「A」及びその構成要素ファイル（例えば「a.」、「b.」、「c.」）の各々がスキャンされることになり、２番目に「B」及びその構成要素ファイル（例えば「1.」、「2.」、「3.」、「4.」、「5.」、「6.」）の各々がスキャンされることになり、３番目に「C」及びその構成要素ファイル（例えば「a.」及び「b.」）がスキャンされることになるであろう。上記のスキャニング（走査）には、各エントリのｉノードを見て更新日時（メタデータとしてｉノードに格納されている）が昨日の日付より大きいかどうかを判定する過程が含まれる。

システムのサイズ及びｉノードの場所は共に、ｉノードのアクセスタイムに悪影響を及ぼすことがあり得る。具体的には、多くのデータ記憶装置はますます大量のデータを格納するようになっている。例えば、典型的なＥメール記憶装置は、１億個のｉノード及びそれ以上の数の名前さえも含むこともある。

あいにく、この巨大なファイルツリーをウォークし、ファイルツリーにおける各エントリに対する適切な属性をフェッチし、その後、その属性を特定基準と比較する従来の技法は、ディスクドライブ上でのｉノードの本質的にランダムなアクセスをもたらす。ｉノードは一般的にはディスクドライブ中至る所にチャンクで分散される（例えば、典型的な編成は６４ＭＢのチャンクに８，０００個のｉノードを有することができよう）ことに留意されたい。このように、大型データ記憶装置におけるファイルツリーのウォークは、非スケーラブルなインプリメンテーションである。例えば、上述したＥメール記憶装置は、単純な更新日時要求を実行するのに何時間も走行しかねない。

それゆえ、大型データ記憶装置に合わせて適切にスケールするファイル検索技法が必要である。

データ記憶装置において特定属性基準によりファイル検索を実行する方法について述べる。この方法は、データ記憶装置のファイルシステムイメージを生成することができる。このファイルシステムイメージは、本質的に、特定の時点でのデータ記憶装置のスナップショットである。この時点で、ファイルシステムイメージにおけるｉノードの実質的にシーケンシャルなスキャンを実行することができる。

スキャンに基づき、特定属性基準を有するファイルシステムイメージ上のｉノードのリストを構築することができる。このリストの１つの編成（本明細書中では特定属性ｉノードマップとも呼ばれる）は、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表されるようなビットマップを有することである。特定属性基準は、少なくとも１つのメタデータ属性、例えば、更新日時、所有権、ファイルサイズ、パーミッション、及びこれらのメタデータ属性の組合せを含むことができる。このとき、リスト中のｉノードにマッチする（ファイルツリー中の）ｉノードを見つけるために、データ記憶装置のファイルツリーをウォークすることができる。次に、マッチするｉノードに対応するファイルのリストを生成することができる。

従って、要約すれば、特定属性基準にマッチするｉノードは、有利には、ファイルシステムイメージ（または、他の実施形態において、実際のデータ記憶装置）のシーケンシャルスキャンによって識別されることができる。このシーケンシャルスキャンは、ファイルシステムイメージのランダムスキャンを排除し、それによってｉノードの読取りに掛かる総時間を劇的に削減する。ひとたび特定属性ｉノードマップが生成されると、後に続くファイルツリーのウォークは、特定属性ｉノードマップ上のｉノードとファイルツリーのｉノードのマッチを簡単に判定している。

図４は、大型データ記憶装置を用いてであっても検索要求を実行するのに必要な時間を著しく減らすことができる検索技法４００を示す。ステップ４０１は、ファイルシステムイメージを生成するかまたはファイルシステムイメージにアクセスする。稼働中のディスクドライブは一般的にはファイルの流動状態にあり、ｉノードは絶えず変更されていることに留意されたい。ファイルシステムイメージは、効率的にはディスクドライブの適時のスナップショットであり、ディスクドライブに格納されている情報を全て示す。このファイルシステムイメージは、別々の論理ボリュームとして維持されることができる。

一実施形態において、ディスクドライブ自体を（ファイルシステムイメージに代えて）用いることができる。（即ち、ステップ４０１は任意選択である。）それゆえ、ファイルシステムイメージに適用される検索技法４００の残りのステップ（即ち、ステップ４０２、４０３、４０４、４０６）は、ディスクドライブにも同様に適用されることができる。簡単のために、検索技法４００のそのようなステップにおけるファイルシステムイメージについてのみ言及する。

ステップ４０２は、解析されるべき別のｉノードがファイルシステムイメージにあるかどうかを判定することができる。もしあれば、ステップ４０３は次のｉノードをスキャンする（即ち読み取る）ことができる。ステップ４０４は、そのｉノードのメタデータの属性が所望の属性（例えば、更新日時、所有権など）にマッチするかどうかを判定することができる。もしマッチすれば、ステップ４０５はそのｉノードを特定の属性のための（attribute specific）ｉノードマップに追加することができる。この時点で、検索技法４００は、ステップ４０２に戻って、解析する別のｉノードがファイルシステムイメージにあるかどうかを判定することができる。ステップ４０２において判定されるように、全てのｉノードの解析が完了した後、ステップ４０６は、特定の属性のためのｉノードマップにおいてｉノードを見つけるために、ファイルツリーをウォークすることができる。ファイルツリー中のマッチするｉノードは、有利には、当該ｉノードに対応するファイルを識別することになる。この情報を用いて、ステップ４０７は、マッチするｉノードに対応するファイルのリストを作成することができる。

ｉノードがチャンクに編成されるのであれば、ステップ４０２は、別のｉノードチャンクが解析されることになる（即ち、１回の要求でｉノードチャンク全体を読み取ることができる）か判定することができることに留意されたい。その後、ステップ４０３は、次のｉノードチャンクをスキャンすることができる。ステップ４０４が、そのｉノードチャンクにおける任意のｉノードのメタデータにおける属性が所望の属性にマッチするかを判定するならば、ステップ４０５は、そのようなｉノードを特定の属性のためのｉノードマップに追加することができる。

上述のｉノードチャンクは、使用を予測して形成されることができることにさらに留意されたい。従って、ｉノードチャンクは、どのｉノードが実際に使用されているかを示すビットマップを有することができる。ステップ４０３においてこのビットマップを用いることによって、不使用ｉノード（またはチャンク全体さえも）の読取りを回避することができる。

一実施形態において、特定の属性のためのｉノードマップはビットマップを用いて実現されることができるが、このビットマップでは、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表される。検索には任意の属性セットを含めることができることに留意されたい。それゆえ、特定の属性のためのｉノードマップを作成するために、例えば、先週以後更新されたファイル、スーザンが所有するファイル、ボブ及びスーザンの両者を含むパーミッションを有するファイルを含む属性を用いることができることもある。特定の属性のためのｉノードマップにおけるｉノード番号をその後さらにソートまたはハッシュして、すでに高速であるアクセスを増加させることができることに留意されたい。

特定の属性のためのｉノードマップを使用すると、データ記憶装置の検索時間を劇的に削減することができる。例えば、図５は、複数のｉノード５０１〜５０６を格納する簡略化されたディスクドライブ５００を示す。（図５はディスクドライブのファイルシステムイメージも表すこともあることに留意されたい。）検索パターン５１０は、従来の技法を用いたディスクドライブ５００の模範的な読取り操作を表す。図３に関連して前述したように、読取パターン５１０は、ディスクドライブ５００上のｉノードの位置ではなく、ファイルツリーにおいて解析されている次のｉノードに基づく。この場合、読取パターン５１０は、ｉノードを５０１、５０６、５０２、５０５、５０４の順で解析する。

対照的に、読取パターン５１１は、図４に関連して話題にしたように、特定の属性のためのｉノードマップを生成するための模範的な読取りを表す。読取パターン５１１は、ディスクドライブ５００上のｉノードの位置に基づく。この場合、読取り操作は、ｉノードを５０１、５０２、５０３、５０４、５０５、５０６の順で解析することができる。ｉノード５０１〜５０６に対応付けられたｉノード番号は連続的でないことがあるが、それはこの例にとって重要でないことに留意されたい。具体的には、読取パターン５１１は、ディスクドライブ５００に沿って順次（シーケンシャル）に（物理的に、必ずしも数値的にである必要はない）実行される。

とりわけ、読取パターン５１０は、（ｉノードチャンクは図４に関連して述べたように読み取られないと仮定すれば）同数の読取りを有するが、ディスクドライブ５００に沿ってランダムに実行される。読取パターン５１１は、ルートレベル及びブランチレベルでの種々のディレクトリの読取りの結果、限られた数のランダム読出しを有することもあり得ることに留意されたい。しかし、大型データ記憶装置を用いて特定の属性のためのｉノードマップを作成すると、有利には、読取りの９０％がシーケンシャルであり、読取りの１０％だけがランダムであることになり得る。

従って、読取パターン５１１は、待ち時間が従来の読取パターン５１０よりかなり短いので、ｉノードの総読取時間を劇的に削減する。ディスクドライブ５００（またはそれに対応するファイルシステムイメージ）は、上述の読取パターンを説明するものであって、実際のディスクドライブ（またはファイルシステムイメージ）の模範となるものではないことに留意されたい。具体的には、典型的なファイルシステムには、ユーザ数より遥かに多くのファイル（例えばＥメール）が含まれる。従って、ファイルに比べればディレクトリは一般的にごく少数である。つまり、ディスクドライブ５００（またはそれに対応するファイルシステムイメージ）は、ｉノード（またはｉノードチャンク）を分割している非常に大きなデータブロックを有することができよう。結果として、ｉノードを読み出すのに従来のパターン５１０を用いるか新たなパターン５１１を用いるかの差が、さらによく理解されることができる。例えば、従来のファイルツリーウォークを用いて４５分掛かる属性検索を、特定の属性のためのｉノードマップ技法を用いて１分に短縮することができる。

本発明を説明する実施形態について添付の図面を参照しながら本明細書において詳細に述べてきたが、本発明はこれらそっくりそのままな実施形態に限定されるものではないことを理解されたい。好適実施形態は、網羅的なものでもなければ、開示されたものと寸分違わない形に本発明を限定するものでもない。よって、多くの変更及び改変をなし得ることは明白であろう。従って、本発明の範囲は、特許請求の範囲及びそれと等価なものによって画定されると解釈されたい。

そのｉノード番号を識別しかつメタデータ及びディスクアドレスを含む簡略化されたｉノード。 複数のファイルレコードを含む簡略化されたユーザディレクトリ。 単純なファイルツリー。 大型データ記憶装置を用いてでも検索要求を実行するのに必要な時間を著しく減らすことができる検索技法。 ２つの検索パターンを用いて読み取られる簡略化されたディスクドライブ（またはファイルシステムイメージ）。第１のパターンはｉノードのランダムアクセスに基づくが、第２のパターンはｉノードのシーケンシャルアクセスに基づく。

符号の説明

１００、５０１〜５０６ ｉノード
１０５、５００ ディスクドライブ
５１０ 従来の読取パターン
５１１ 新たな読取パターン

Claims (14)

1. データ記憶装置においてｉノードの属性検索を実行する方法であって、
   前記データ記憶装置のファイルシステムイメージにおけるｉノードの実質的にシーケンシャルなスキャンを実行する過程と、
   特定属性基準にマッチする前記ファイルシステムイメージ中のｉノードのリストを構築する過程とを含むことを特徴とする方法。
2. 前記特定属性基準が、ｉノードに格納された少なくとも１つのメタデータ属性を含むことを特徴とする請求項１に記載の方法。
3. 前記リストが、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表されるようなビットマップを含むことを特徴とする請求項１に記載の方法。
4. データ記憶装置においてｉノードの属性検索を実行する方法であって、
   前記データ記憶装置におけるｉノードの実質的にシーケンシャルなスキャンを実行する過程と、
   特定属性基準にマッチする前記データ記憶装置上のｉノードのリストを構築する過程とを含むことを特徴とする方法。
5. 前記特定属性基準が、ｉノードに格納された少なくとも１つのメタデータ属性を含むことを特徴とする請求項４に記載の方法。
6. 前記リストが、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表されるようなビットマップを含むことを特徴とする請求項４に記載の方法。
7. データ記憶装置において特定属性基準によりファイル検索を実行する方法であって、
   前記データ記憶装置のファイルシステムイメージを生成する過程と、
   前記ファイルシステムイメージにおけるｉノードの実質的にシーケンシャルなスキャンを実行する過程と、
   特定属性基準を有する前記ファイルシステムイメージ上のｉノードのリストを構築する過程と、
   前記リスト中の前記ｉノードにマッチする前記ファイルツリー中のｉノードを見つけるために、前記データ記憶装置のファイルツリーをウォークする過程と、
   マッチするｉノードに対応するファイルのリストを生成する過程とを含むことを特徴とする方法。
8. 前記特定属性基準が、ｉノードに格納された少なくとも１つのメタデータ属性を含むことを特徴とする請求項７に記載の方法。
9. 前記リストが、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表されるようなビットマップを含むことを特徴とする請求項７に記載の方法。
10. データ記憶装置において特定属性基準によりファイル検索を実行する方法であって、
    前記データ記憶装置におけるｉノードの実質的にシーケンシャルなスキャンを実行する過程と、
    特定属性基準を有する前記データ記憶装置上のｉノードのリストを構築する過程と、
    前記リスト中の前記ｉノードにマッチする前記ファイルツリー中のｉノードを見つけるために、前記データ記憶装置のファイルツリーをウォークする過程と、
    マッチするｉノードに対応するファイルのリストを生成する過程とを含むことを特徴とする方法。
11. 前記特定属性基準が、ｉノードに格納された少なくとも１つのメタデータ属性を含むことを特徴とする請求項１０に記載の方法。
12. 前記リストが、各ｉノードがそのｉノード番号によってインデックス付けされるビットによって表されるようなビットマップを含むことを特徴とする請求項１０に記載の方法。
13. 特定の属性のためのｉノードマップであって、
    ファイルシステムイメージ上の実質的にシーケンシャルなｉノードに対応しかつ特定属性基準にマッチする複数のｉノード番号を含むことを特徴とする特定の属性のためのｉノードマップ。
14. 各ｉノードが、そのｉノード番号によってインデックス付けされるビットによって表されることを特徴とする請求項１３に記載の特定の属性のためのｉノードマップ。

Images