JP2009015849A - スケーラブル・ファイル・システムの回復のためのリソース管理 - Google Patents

Abstract

【課題】データを保存するためのシステム及び方法を提供すること。
【解決手段】一実施形態では、ファイル・システムが、関連するメタデータを含むデータを保存する。ファイル・システム・エラーが起こったことを検出したことに応答して、このファイル・システムは、エラーが起こったデータを含むコンテナを識別し、そのコンテナ内に含まれるデータの一貫性チェックを実行する。そのコンテナと他のコンテナとの間に双方向リンクが存在し、かつその双方向リンク内でエラーが見つかった場合に、ファイル・システムは、他方のコンテナ内に含まれるデータの一貫性チェックを実行し、この他方のコンテナと第３のコンテナとの間に別の双方向リンクが存在するかどうか判定する。この他方のコンテナと第３のコンテナとの間に別の双方向リンクが存在し、かつその別の双方向リンク内でエラーが見つかった場合に、ファイル・システムは、第３のコンテナ内に含まれるデータの一貫性チェックを実行する。
【選択図】図３ａ

Description

本発明は、コンピュータ・システムに関し、さらに詳細にはコンピュータ・システムの中のファイル・システムのリソース管理に関する。

コンピュータ・ファイル記憶システムは、次第に大きくなり、多数のリソースを消費し、多様なファイル・システム・オペレーションに関してスケーラビリティの問題が存在するようになっている。特に、従来のファイル・システムでは、損傷を受けたファイル・システムを修復するために必要な時間の量は、よくても、ファイル・システムのメタデータのサイズに比例して増大する。修復が行われている間、ファイル・システムは通常オフラインになっており、その結果、許容できないほどの長時間にわたって、保存されたファイルがアクセス不可能になる。

損傷を受けたファイル・システムを修復するのに多大な時間がかかる１つの理由は、リソースが全体的にかつ無制限に割り当てられていることである。したがって、１つのエラーがファイル・システムのいずれの部分にも影響を及ぼす可能性があり、徹底的な一貫性チェックが必要となる。言い換えると、故障領域はファイル・システム全体であることもあり得る。よく知られているＦｉｌｅ Ｓｙｓｔｅｍ Ｃｏｎｓｉｓｔｅｎｃｙ Ｃｈｅｃｋｅｒ（ＦＳＣＫ）などのユーティリティをサポートするためには、全体的メタデータ追跡表を保持しなければならない。ＦＳＣＫのオペレーションの間、これらの追跡表はアクセス可能でなければならない。その結果、仮想メモリ・サブシステムにストレスがかかり、一貫性チェック・オペレーションを平行して行うことが困難になることもある。大きいファイル・システムが多数の小さいファイル・システムへと分割されれば、小さいシステムのうちの１つの修復はより速くなるであろう。しかしながら、許容できない管理オーバヘッドが存在することもあり、単一のファイル・システムの意味が失われる可能性もある。ＦＳＣＫに類似したユーティリティを実行するのに必要とされる時間を削減するために様々な技法を採用することができる。しかしながら、それでもなおソフトウェアのバグ又は外部の媒体によって引き起こされるようないくつかのタイプのエラーによって、多大な時間を要する一貫性チェックが必要となる。上記の観点から、これらの課題の主因となるファイル・システムのリソースを動的に管理するためのさらに有効なシステムと方法が望まれる。

コンピュータ・システム及び方法の様々な実施態様が開示される。一実施態様では、コンピュータ・システムは、保存データとそれに付随する保存メタデータとを含むファイル・システムを含む。ファイル・システム・エラーが起こったことを検出したことに応答して、ファイル・システムは、エラーが発生したファイル・データとそれに付随するメタデータとを含む第１のコンテナを識別し、第１のコンテナに含まれるファイル・データとそれに付随するメタデータの一貫性チェックを実行するように構成される。一実施態様では、コンテナは、いくつかのデータ記憶の割り当て単位と、付随するメタデータ記憶の単位とを含むファイル・システムの動的に作成された可変サイズ部分である。さらなる実施態様では、データをブロックの中に保存し、付随するメタデータをｉノードの中に保存することである。コンテナはｉノードとブロックの所有権を分離するために使用される。例えば、あるコンテナ内のｉノードはその同じコンテナ内のブロックを参照するだけである。第１のコンテナと第２のコンテナとの間に双方向のリンクが存在し、かつその双方向リンク内でエラーが見つかった場合に、ファイル・システムは、第２のコンテナ内に含まれるファイル・データとそれに付随するメタデータの一貫性チェックを実行し、かつ第２のコンテナと第３のコンテナとの間に第２の双方向リンクが存在するかどうか判定するようにさらに構成される。第２のコンテナと第３のコンテナとの間に双方向のリンクが存在し、かつその第２の双方向リンク内でエラーが見つかった場合に、ファイル・システムは、第３のコンテナ内に含まれるファイル・データとこれに付随するメタデータの一貫性チェックを実行するようにさらに構成される。

新たなファイル・データを保存したいという要求を受信したことに応答して、ファイル・システムは、前に保存されて論理ネームスペース内で新たなファイル・データにリンクされるデータを含むターゲット・コンテナを識別するようにさらに構成される。新たなファイル・データが新たなディレクトリを含まない場合に、又は新たなファイル・データが新たなディレクトリを含み、かつターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有する場合に、ファイル・システムは、新たなファイル・データをターゲット・コンテナ内に保存するようにさらに構成される。ターゲット・コンテナが新たなディレクトリのための十分なリソースを有さない場合に、ファイル・システムは、リンクされたコンテナを作成し、ファイル・データをリンクされたコンテナ内に保存し、かつターゲット・コンテナとリンクされたコンテナとの間の双方向リンクを保存するようにさらに構成される。論理ネームスペース内でファイルを移動させることや、ファイルの名前を変えることなどのファイル・システムのオペレーションに応答して、ファイル・システムは、第３のコンテナに保存されたデータと第４のコンテナに保存されたデータとの間の、論理ネームスペース内の接続を作成するオペレーションを検出したことに応答して、第３のコンテナと第４のコンテナとの間の双方向リンクを保存するようにさらに構成することができる。

ファイル・システムは、コンテナ間の双方向リンクの表を保持するようにさらに構成される。この双方向リンクの表は少なくとも一対の項目を含み、各々の項目がソース・コンテナ、ソースｉノード、宛先ｉノードを識別する。所定の項目のソースｉノードは、その所定の項目のソース・コンテナ内に保存されたファイル・データに付随するメタデータを保存するために使用される。所定の対のうちの第１の項目の宛先ｉノードは、その所定の対のうちの第２の項目のソースｉノードと同じである。

これら及び他の実施態様は以下の記述及び添付の図面を考慮すると明らかになるであろう。

本発明は様々な変更及び代替の形態の余地があるが、実例として特定の実施形態が図中に示されて本願明細書に詳しく述べられる。しかしながら、図面類とこれらに対する詳しい記述が開示される特定の形態に本発明を限定するように意図されておらず、逆に本発明が添付の特許請求項によって規定される本発明の趣旨と範囲内に入るすべての変更形態、同等形態、及び代替形態を網羅することは理解されるはずである。

図１はコンピュータ・システムの一実施形態１００を例示している。図示されるように、システム１００は物理ファイル・システム１２０と論理ネームスペース１３０を含む。物理ファイル・システム１２０は論理ネームスペース１３０に連結された大域リソース管理部１１０を含む。代替の実施形態では、大域リソース管理部１１０は独立型の構成要素である。物理ファイル・システム１２０はハードディスク又はＣＤ−ＲＯＭなどの１つ又は複数のデータ記憶デバイスに連結されることもある。通例では、物理ファイル・システム１２０は１つ又は複数の処理用素子（図示せず）又は他の標準的なコンピュータ・システム構成要素にさらに連結されることもある。

大域リソース管理部１１０は、ｉノード、ブロック、又は他のメタデータやデータ記憶の物理ユニットなどの物理ファイル・システム１２０のリソースを割り当てることに関与する。また、大域リソース管理部１１０はリソース割り当てを追跡するデータ構造を保持することもある。付け加えると、大域リソース管理部１１０は、物理ファイル・システム１２０の状態を追跡し、途中停止したオペレーション、ソフトウェアのバグ、突然の停電その他に起因して生じるエラーを検出して修正することが可能である。大域リソース管理部１１０はハードウェア、ソフトウェア、又はこれらの組み合わせにおいて実装することができる。

図２は論理ネームスペースの一実施形態１３０を例示している。例示された実施形態では、ネームスペース１３０はルートノード２１０で始まり、ノード２２０、２２５、２３１〜２３５、２４１、２４２を含む。ノード２２０、２２５はルートノード２１０にリンクされてもよく、ノード２３１、２３２はノード２２０にリンクされてもよく、ノード２３３〜２３５はノード２２５にリンクされてもよく、ノード２４１、２４２はノード２３２にリンクされてもよい。ノードはレベルの階層でリンクされる。例えば、ノード２２０と２２５が階層の第２のレベル、ノード２３１〜２３５が第３のレベル、等々を形成してもよい。代替の実施形態では、ネームスペース１３０はルートノードにリンクされた２つのノードよりも少ない、又は多いノードも含めて図２に示されたものよりもさらに多くのノードとさらに多くのレベルを含むこともある。

オペレーションの間、ファイルがシステム１００に保存されるときにユーザは論理ネームスペース１３０の中でターゲットの場所を選択する。論理ネームスペース１３０の中のターゲットの場所はファイル・システム１２０内の物理的場所にマップされている。大域リソース管理部１１０はファイル・システムの中のリソースの割り当てを管理し、かつファイル・システム１２０内のメタデータのエラーや他の不一致を下記でさらに述べる処理に従って検出し、修正するなどといった保守管理オペレーションを遂行することもある。

ここで図３ａ、３ｂを参照すると、大域リソース管理部１１０によって実行される一般化された処理が示されている。特に、図３ａはファイル・システムの中にデータを保存するために使用される処理の一実施形態３０２を例示しており、図３ｂはファイル・システム上で一貫性チェックを実行するために使用される処理の一実施形態３０４を例示している。代替の実施形態において、処理３０２、３０４に例示された個々のブロックが異なる順序で実行され、及び／又はいくつかのブロックが他と並列で実行されることもあることに留意するべきである。本願明細書で使用されるとき、一貫性チェックはエラーを検出し及び／又は修正するように構成された１つ又は複数の処理を含むことがある。

処理３０２はファイル・システム内にデータを保存したいという要求の受信（ブロック３１０）で始まる。この要求が新たな最上位レベルのディレクトリの作成を要求していれば（判定ブロック３２０）、新たなコンテナが作成され（ブロック３３０）、データは付随するメタデータと共に新たなコンテナ内に保存され（ブロック３３５）、処理は完了する。本願明細書で使用され、下記でさらに詳しく述べられるコンテナは、ファイル・システムの、動的に作成された可変サイズの部分であり、これはいくつかのデータ記憶の割り当て単位とこれに付随するメタデータ記憶の単位を含む。一実施形態では、データはブロック内に保存され、付随するメタデータはｉノード内に保存される。コンテナはｉノードとブロックの所有権を分離するために使用される。例えば、コンテナ内のｉノードは同じコンテナ内のブロックを参照するのみである。

ターゲットの場所が新たな最上位レベルのディレクトリでなければ（判定ブロック３２０）、保存されるべきデータの親ファイルを含むコンテナが識別される（ブロック３４０）。要求が、最上位レベルのディレクトリよりも下の新たなディレクトリが作成されることを求めていなければ（判定ブロック３４２）、データは付随するメタデータと共に識別済みのコンテナ内に保存されて（ブロック３４４）、処理は完了する。言い換えると、既にあるディレクトリ内に保存されるべき新たなファイル・データは常に親ディレクトリと同じコンテナ内に保存される。要求が、最上位レベルのディレクトリよりも下の新たなディレクトリが作成されることを求めており、かつスペースが新たなディレクトリに関して予期されるデータを保持するのに十分であると判定されれば（判定ブロック３５０）、データは付随するメタデータと共に識別済みのコンテナ内に保存されて（ブロック３４４）、処理は完了する。そうでない場合、新たなリンクされたコンテナが作成される（ブロック３５２）。次いで、データは付随するメタデータと共にリンクされたコンテナ内に保存される（ブロック３５４）。付け加えると、処理を完了するために双方向のリンクが識別済みのコンテナとリンクされたコンテナとの間に作成される（ブロック３５６）。

処理３０４はエラーに関してファイル・システムをチェックしたいという要求の受信（ブロック３６０）で始まる。整合しないメタデータと未了のトランザクションとを記録する状態追跡表内でエラーが追跡される。いったん要求が受信されると、エラーを特定するために、ファイル・システムのコンテナの各々に割り当てらたリソースの範囲がチェックされる（ブロック３６２）。次いで、第１のコンテナに対応する状態記録が選択される（ブロック３６４）。選択された状態記録の中でエラーが検出されれば（判定ブロック３７０）、対応するコンテナ内に保存されたファイルの各々に関してメタデータがチェックされ、いずれのエラーも修正される（ブロック３８０）。付け加えると、対応するコンテナと他のコンテナとの間のあらゆるリンクがチェックされる（ブロック３８５）。双方向リンクの一方又は両方の側が有効でなければ（判定ブロック３９０）、リンクが修復され、このリンクが接続するコンテナが選択される（ブロック３９５）。新たに選択されたコンテナとそのリンクは、双方向リンクのエラーが検出されなくなるまでブロック３８０、３８５、３９０、３９５の反復実行を介して同様の方式でチェックされる。残りのリンク・エラーが無くなると（判定ブロック３９０）、又は選択された状態記録内でコンテナ・エラーが検出されなかった場合（判定ブロック３７０）でかつ最後の状態記録がチェックされていない場合（判定ブロック３７４）、次の状態記録が選択されて（ブロック３７２）エラー検出が繰り返されてもよい（ブロック３７０）。いったん最後の状態記録がチェックされると（判定ブロック３７４）、処理は完了する。

図４は物理ファイル・システムの一実施形態１２０の一般化されたブロック図である。例示された実施形態では、物理ファイル・システム１２０はコンテナ４１０、４２０、４３０、４４０、４５０などといった１つ又は複数のコンテナを含む。各々のコンテナは記憶スペースとこれに付随するメタデータを含む。例えば、コンテナ４１０は数多くのデータ・ファイルを保存するためのスペースを含むこともある記憶部４１４を含む。コンテナ４１０は記憶部４１４内に保存されるファイルに付随するメタデータを含むメタデータ部４１２も含む。同様に、コンテナ４２０は記憶部４２４とメタデータ部４２２を含み、コンテナ４３０は記憶部４３４とメタデータ部４３２を含み、コンテナ４４０は記憶部４４４とメタデータ部４４２を含み、コンテナ４５０は記憶部４５４とメタデータ部４５２を含む。５つのコンテナのみが示されているが、物理ファイル・システム１２０内に含まれるコンテナはより多くても、少なくてもよい。各々のコンテナは双方向リンクを通じて１つ又は複数の他のコンテナにリンクされ、これはコンテナ相互参照として知られている。

例えば、例示された実施形態では、コンテナ４１０と４２０はリンク４６１と４６２を介して接続され、コンテナ４１０と４３０はリンク４６３と４６４を介して接続され、コンテナ４４０と４５０はリンク４６５、４６６、４６７、４６８を介して接続される。第１のコンテナが追加の保存データに関して十分なリソースを有さないなどといった特定の状況が検出されれば、１つのコンテナから第２のコンテナにリンクが確立されることもある。そのような状況はオーバーフローと称され、第２のコンテナはリンクされたコンテナと称される。例えば一実施形態では、第１のコンテナにさらに多くの記憶部を追加することによって、所定の最大数よりも多くの記憶ユニット、オブジェクト、ファイルなどを管理するために、リンクされたコンテナが必要となる場合には、そのリンクされたコンテナが追加されることもある。様々な実施形態において、リソースが十分であるかどうかを決める判定基準は記憶リソースの利用可能性に代わって、又はこれに加えていずれの望ましい判定基準を含んでもよく、方針によって、動的にユーザ入力によって、又はいずれかの他の望ましい手段によって決定されてもよい。

物理ファイル・システム１２０の一実施形態では、記憶部とメタデータ部は従来のブロックとｉノードで構成される。さらに詳細には、記憶素子４１４、４２４、４３４などの各々がブロックのセットの１つ又は複数の割り当てで構成されてもよく、メタデータ素子４１２、４２２、４３２などの各々が該当するｉノードのセットで構成されてもよい。ブロックとｉノードのセットは下記でさらに述べられるであろう処理を介してコンテナに割り当てられてもよい。大域リソース管理部１１０はコンテナへのブロックとｉノードのマップ、及びコンテナ間のリンクの追跡の記録を様々なデータ構造を使用して保持している。図５、６、７、及びそれらに付随する記述はそのようなデータ構造の一実施形態の詳細を提供し、メタデータの単位はｉノードであり、データ記憶の単位はブロックである。代替の実施形態では、ブロックとｉノードの代わりに様々な記憶割り当て単位及びメタデータ単位のうちのいずれが使用されてもよい。

図５はコンテナとこれらに付随するｉノードを管理するために使用される表のセットの一実施形態を例示している。図５はコンテナの状態表５１０、ｉノードのセットの所有権表５２０、ｉノードのセットの集計表５３０を含む。表５１０はファイル・システム内に作成された各コンテナに関する項目を含んでいる。項目は、例示された実施形態で示すように、コンテナＩＤ５１２で区別される。したがって、５つの項目がコンテナＩＤ Ｃ１、Ｃ２、Ｃ３、Ｃ４、Ｃ５で区別されて示されている。ファイル・システムにコンテナが追加されるたびに項目が表に追加される。各々の項目は状態ビット５１４、５１６をも含む。状態ビット５１４、５１６は対応するコンテナに付随した考え得るエラー状態を記録する。

例えば一実施形態では、状態ビット５１４は、対応するコンテナ内に保存されるか又は保存されるであろうデータを含む未了のトランザクションが存在することを示している。状態ビット５１６は、一致しないメタデータ参照が存在することを示してもよい。未了のトランザクションは必ずしもエラーではないが、ファイル・システムが静穏であると予期される時間に未了のトランザクションの状態ビットが設定されればエラーが想定される。一致しないメタデータ参照もやはりファイル・システム内のエラーを示すと想定される。そのような状況は、トランザクション中に予期しない停電が起こるとき、ハードウェアの故障の後に常に、又はソフトウェアのエラーが理由で生じる。システムが再起動すると、たとえトランザクションがもはや保留ではないとしても、そのトランザクションが完了されなかったことを示す未了トランザクション・ビットが設定される。状態ビットによって追跡されることが可能な他のエラー状況は当業者に明らかであろう。

表５２０は、ファイル・システム内に割り当てられたｉノードの各々のセットに関する項目を含んでいる。項目は、例示された実施形態に示されるように、ｉノード・セットＩＤ５２４で区別される。１１の項目がｉノード・セットＩＤ ＩＳ１〜ＩＳ１１で区別されて示されている。ファイル・システムにｉノード・セットが割り当てられるたびに項目が表に追加される。各々の項目は、コンテナにｉノード・セットが割り当てられたことを示すコンテナＩＤ５２２をも含む。

表５３０は各コンテナのｉノード利用を集計するデータを含む。一実施形態では、表５３０は項目５３１〜５３８などを含む。各々の項目はｉノード・セットＩＤ５４１、割り当てられたｉノード総数５４２、空いているｉノードの総数５４３、ディレクトリのｉノード総数５４４を含んでいる。ｉノードが割り当てられるたびに、例えばファイル・システムにファイル又はディレクトリが追加されるとき、常に項目が表の中で更新される。ｉノード・セットＩＤ５４１は、ｉノード・セットを識別し、かつ表５２０の中のｉノード・セットＩＤ５２４の値と一致する値を保持している。表５３０はｉノードＩＤ５４１でインデックスを付けられる。割り当てられたｉノード総数５４２はセットの中で割り当てられるｉノードの数を追跡する。空いているｉノードの総数５４３は、セットの中で割り当てるのに利用可能なｉノードの数を追跡する。ディレクトリのｉノード総数５４４はファイルではなくディレクトリに付随するｉノードの数を追跡する。

図６はコンテナとこれらに付随するブロックを管理するために使用される表のセットの一実施形態を例示している。図６はブロック・セット所有権表６２０とブロック・セット集計表６３０を含む。表６２０はファイル・システム内に割り当てられたブロックの各々のセットに関する項目を含んでいる。項目は例示された実施形態に示されるように、ブロック・セットＩＤ６２４で区別される。したがって、１１の項目がブロック・セットＩＤ Ｓ１〜Ｓ１１で区別されて示されている。コンテナにブロック・セットが割り当てられるたびに項目が表に追加される。各々の項目は、コンテナにブロック・セットが割り当てられたことを示すコンテナＩＤ６２２を含むこともある。表６３０は項目６３１〜６３８などを含んでいる。各々の項目はブロック・セットＩＤ６４１、コンテナＩＤ６４２、ブロック・セット集計６４３を含んでいる。ブロック・セットＩＤ６４１は、ブロック・セットを識別し、かつ表６２０の中のブロック・セットＩＤ６２４の値と一致する値を保持している。コンテナ・セットＩＤ６４２は、ブロックが割り当てられるコンテナを識別し、かつ表６２０の中のコンテナＩＤ６２２の値と一致する値を保持している。ブロック・セット集計６４３はブロック・セットＩＤ６４１に付随するブロックの利用を記述するデータを含んでいる。ブロックが使用されるたびに、例えばファイル・システムにファイル・データが追加されるときに常に、項目が表６３０内で更新される。

図７はコンテナとこれらに付随するリンクを管理するために使用されるコンテナ・リンケージ表の一実施形態７１０、７５０を例示している。各々のコンテナは独自のコンテナ・リンケージ表に関連している。表７１０は項目７１１〜７１８などを含み、かつ第１のコンテナに付随している。同様に、表７５０は項目７５１〜７５８などを含み、かつ第２のコンテナに付随している。各々の項目はタイプ領域と２つの追加領域を含んでいる。例えば、項目７１１はタイプ７２２、内部ｉノードＩＤ７２３、外部ｉノードＩＤ７２４を含んでいる。タイプ７２２は内部ｉノード７２３が別のコンテナ内のｉノードを参照することを示す外部の値を有して外部ｉノードＩＤ７２４によって識別される。ファイル・システム内にエラー又はメタデータの不一致が無ければ、対応する第２の項目が、表７５０などの他のコンテナ・リンケージ表に存在する。それは、このケースでは一致項目７５８である。項目７５８はタイプ７８２を含み、これは内部ｉノード７８３が別のコンテナ内のｉノードを参照することを示す外部の値を持ち、外部ｉノードＩＤ７８４によって識別される。このケースでは、内部ｉノードＩＤ７８３は項目７１１の外部ｉノードＩＤ７２４と同じ値を有し、外部ｉノードＩＤ７８４は項目７１１の内部ｉノードＩＤ７２３と同じ値を有する。同様に、タイプ７４２、内部ｉノードＩＤ７４３、内部ファイルＩＤ７４４を含む項目７１４が図示されている。タイプ７２２は内部ｉノード７４３が同じコンテナの中のファイルを参照することを示す内部の値を持ち、内部ファイルＩＤ７４４によって識別される。双方向の対を形成する項目７１１、７５８とは異なり、項目７１４は他のコンテナ・リンケージ表内に一致項目を有さない。それよりもむしろ、項目７１４は同じコンテナ内のファイルとディレクトリ間の余剰のハード・リンクを示す。すべてのファイルがディレクトリへの少なくとも１つのリンクを有してもよいが、他のディレクトリへの付加的なリンクを有してもよい。各々の付加的リンクは表７１０内の項目７１４などの項目を介して追跡される。修復オペレーション中に、ファイル・システムのメタデータの適切な状態を判定するために大域リソース管理部が項目の一致する対の中にある冗長性を利用する。

図８はファイル・システムの中にデータを保存するために使用されることが可能な処理の一実施形態８００を例示している。処理８００は新たなデータの記憶要求の受信（ブロック８１０）で始まる。記憶要求によってターゲットにされるコンテナが最初に決定される（ブロック８２０）。次いで、要求からのデータを保持するためにｉノードと十分な数のブロックが利用可能であれば（判定ブロック８３０）、コンテナ状態表内のターゲット・コンテナの未了トランザクション状態ビットが設定される（ブロック８６０）。ｉノードの利用可能性を判定するために、ｉノード・セット所有権表とｉノード・セット集計表が閲覧される。ブロックの利用可能性を判定するために、ブロック・セット所有権表とブロック・セット集計表が閲覧される。利用可能なｉノードが識別され（ブロック８６２）、利用可能なブロックが識別され（ブロック８６４）、ブロックがｉノードに関連付けられる（ブロック８７０）。いったんｉノードとブロックが関連付けられ、使用されるように指定されると、ｉノード・セット集計表とブロック・セット集計表の両方の中の対応する項目が更新されてこれらが使用中であることを示す（ブロック８７５）。次いで、データが指定のブロックの中に保存される（ブロック８８０）。データが保存された後、コンテナ状態表内のターゲット・コンテナの未了トランザクション状態ビットが消去されて処理を完了する（ブロック８８５）。

判定ブロック８３０に戻って、要求からのデータを保持するためのｉノードと十分な数のブロックがターゲット・コンテナ内で利用可能でなければ、新たなデータ要求のタイプが判定される。この要求が、ターゲット・コンテナが供給できるよりも多くのスペースを必要とする新たな最上位レベルのディレクトリ又は新たなディレクトリを追加することでない場合（判定ブロック８４０）、コンテナ状態表内のターゲット・コンテナの未了トランザクション状態ビットが設定される（ブロック８５０）。ｉノードのセットが獲得されてターゲット・コンテナに割り当てられる（ブロック８５２）。新たなｉノードがターゲット・コンテナに割り当てられて使用中であることを示すために、ｉノード・セット所有権表とｉノード・セット集計表内の新たな項目が作成される（ブロック８５４）。ブロックのセットが獲得されてターゲット・コンテナに割り当てられる（ブロック８５６）。新たなブロックがターゲット・コンテナに割り当てられて使用中であることを示すためにブロック・セット所有権表とブロック・セット集計表内の新たな項目が作成される（ブロック８５８）。１つ又は複数の新たなブロックが新たなｉノードと関連付けられ（ブロック８７０）、残りの処理ブロック８７５、８８０、８８５が実行されて前に述べられたように処理を完了する。

判定ブロック８４０に戻って、この要求が、ターゲット・コンテナが供給できるよりも多くのスペースを必要とする新たな最上位レベルのディレクトリ又は新たなディレクトリを追加することである場合、新たなリンクされたコンテナがターゲット・コンテナにリンクしたファイル・システムに追加される（ブロック８４２）。次いで新たなコンテナ項目がコンテナ状態表内に作成されてもよく、新たな項目の未了トランザクション状態ビットが設定される（ブロック８４４）。次いで処理８００はブロック８５２から完了へと続く。代替の実施形態において、処理８００に例示された個々のブロックが異なる順序で実行されてもよいこと、及び／又はいくつかのブロックが他と平行して実行されてもよいことに留意するべきである。

図９はコンテナの境界を横切るファイル・システムのオペレーションを追跡するために使用される処理の一実施形態９００を例示している。処理９００は２つのコンテナ間の相互参照を作成するネームスペースの中でファイルの名前を変えること、ファイルを移動させること、ファイルをコピーすることなどの要求の受信（ブロック９１０）で始まる。ソース・コンテナが識別され（ブロック９２０）、宛先コンテナが識別される（ブロック９３０）。例えば、第１のコンテナ（ソース）にマップされるネームスペース内の１つのノードから第２のコンテナ（宛先）にマップされるネームスペース内の別のノードにファイルが移動させられ、又はコピーされる。あるいは、コンテナ間にコンテナ相互参照を作成することによって、１つのコンテナ内に保存されるファイルを別のコンテナに関連するディレクトリに移す工程が実施されてもよい。いったんソース・コンテナと宛先のコンテナが識別されると、コンテナ状態表内のソース・コンテナと宛先コンテナの未了トランザクション状態ビットが設定される（ブロック９４０）。次いで、オペレーションがコピー・オペレーションであれば、ｉノードが宛先コンテナ内で識別されるか又は獲得され（ブロック９６０）、ファイル・データを保持するために十分な数のブロックが宛先コンテナ内で識別されるか又は獲得される（ブロック９６２）。ｉノードの利用可能性を判定するために、ｉノード・セット所有権表とｉノード・セット集計表が閲覧される。ブロックの利用可能性を判定するために、ブロック・セット所有権表とブロック・セット集計表が閲覧される。ブロックがｉノードと関連付けられる（ブロック９６４）。

いったんｉノードとブロックが関連付けられて使用されるように指定されると、ｉノード・セット集計表、ｉノード・セット所有権表、ブロック・セット所有権表、ブロック・セット集計表内の対応する項目が更新されてこれらが使用中であることを示す（ブロック９６６）。次いで、指定されたブロック内にデータが保存される（ブロック９６８）。データが保存された後、コンテナ状態表内のターゲット・コンテナの未了トランザクション状態ビットが消去されて（ブロック９７０）、処理を完了する。

オペレーションがコピー・オペレーションでない場合、例えば移動又は再命名オペレーションである場合、項目の双方向対がコンテナ・リンケージ表内に作成される（ブロック９８２）。次いでコンテナ状態表内のターゲット・コンテナの未了トランザクション状態ビットが消去され（ブロック９８４）、処理を完了する。代替の実施形態において、処理９００に例示された個々のブロックが異なる順序で実行されてもよいこと、及び／又はいくつかのブロックが他と平行して実行されてもよいことに留意するべきである。

図１０はエラーに関してファイル・システムを走査するために使用される処理の一実施形態１０００を例示している。処理１０００は、システムが再起動されるときに常に生じる、又はユーザ若しくはアプリケーションその他からの命令に応答した、選択されたコンテナに対応するコンテナ状態表内の第１の項目の状態ビットの走査（ブロック１０１０）で始まる。走査が起こるとき、ファイル・システムは静止状態に置かれていることが想定されている。したがって、設定されるいずれの未了トランザクション状態ビットもファイル・システムのエラーであると解釈される。選択されたコンテナ項目に関して状態ビットが設定されておらず（判定ブロック１０２０）、かつコンテナ状態表内のすべての項目が走査された場合（判定ブロック１０３０）、処理１０００は完了する（ブロック１０５０）。状態ビットが設定されれば（判定ブロック１０２０）、対応するファイル・システムの部分がチェックされてエラーが修正される。

エラー修正処理はよく知られているＦＳＣＫオペレーションで使用されるものと同様の処理を使用してもよいが、しかしファイル・システムの部分のみがチェックされる。したがって、この処理は「部分的ＦＳＣＫ」と称することができる。さらに詳細には、一実施形態では選択されたコンテナに対応するｉノード・セット所有権表とブロック・セット所有権表内の項目をチェックすることで、確認されるべきｉノードとブロックの範囲を判定する（ブロック１０６０）。さらにｉノードとブロックの所有権を有効にするために、対応するｉノード・セット集計表内の項目とブロック・セット集計表内の項目がメモリ内に読み取られる。ｉノード及びブロックの所有権の不一致が解決される。ｉノード・セット集計表とブロック・セット集計表内の項目も、処理１０００において後に変更を受ける。例えば主要ファイル・システムの破損が起こった場合のケースのように、見つけ出されるエラーの数がいくつかの所定の閾値を超える場合（判定ブロック１０７０）、全ファイル・システムのチェックが実行され（ブロック１０９０）、処理は完了する（ブロック１０５０）。

少数のコンテナのみがエラーを含むことが見出されれば（判定ブロック１０７０）、ｉノード対ブロックの参照が確認され、見つけ出されるすべてのエラーが修復される（ブロック１０７２）。各々のコンテナは独立して調べられる。さらに詳細には、ｉノードが、所有されていないブロック・セットからブロックを参照する場合、このブロック・セットは、選択されたコンテナに追加され、所有権の付与はロックによって保護される。このブロック・セットが別のコンテナによって所有される場合、この不一致については、後でその別のコンテナがチェックされて確認された後に解消するために指摘される。

次に、ｉノードの階層が確認されてエラーが修復される（ブロック１０７４）。さらに詳細には、この確認は適切な親子関係に関してすべてのディレクトリのブロックとディレクトリの項目をチェックする工程を含んでいる。付け加えると、コンテナ・リンケージ表がチェックされる。このチェックは選択されたコンテナの中のファイルへのすべてのハード・リンクを確認する工程や、見出されるすべてのエラーを修復する工程（ブロック１０７６）を含んでいる。また、選択されたコンテナのコンテナ・リンケージ表内の項目であって他のコンテナを参照する項目が確認される（ブロック１０７８）。選択されたコンテナのコンテナ・リンケージ表内の項目が外部のコンテナ内のｉノードを参照する場合、外部のコンテナのコンテナ・リンケージ表内の対応する項目も存在するはずである。そうでない場合、エラーが存在し、外部のコンテナが確認されなければならない。項目又は一致する双方向項目が無いことはコンテナ間のエラーが存在しないことを示す。一致しない項目は様々な方策又はアルゴリズムのうちの１つによって解決される（ブロック１０８０）。例えば、選択されたコンテナに対応するコンテナ・リンケージ表内の項目の値が間違っており、対応する反対方向の項目と一致するように訂正されることが想定されてもよい。場合によっては、又は加えて、間違ったディレクトリ項目や、現在のコンテナとの未結合リンクが取り除かれる。孤立ｉノードは遺失物取扱ディレクトリにリンクされる。

いったん項目が修復されると、選択されたコンテナに対応するコンテナ状態表内の状態ビット・エラーが消去される（ブロック１０８５）。コンテナ状態表内のすべての項目が走査されていた場合（判定ブロック１０３０）、処理１０００は完了する（ブロック１０５０）。コンテナ状態表内のすべての項目が走査されていなかった場合（判定ブロック１０３０）、次のコンテナ項目を走査する工程（ブロック１０４０）と状態ビットをチェックする工程（判定ブロック１０２０）などに進むことによって処理１０００がコンテナ状態表内の各々の項目について繰り返される。代替の実施形態において、処理１０００に例示された個々のブロックが異なる順序で実行されてもよいこと、及び／又はいくつかのブロックが他と平行して実行されてもよいことに留意すべきである。

上述の実施形態がソフトウェアを含むこともさらに留意するべきである。そのような実施形態では、本方法及び／又はメカニズムを実施するプログラム命令がコンピュータで読み取り可能な媒体に搬送又は保存される。プログラム命令を保存するように構成される多数のタイプの媒体が入手可能であり、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、フラッシュメモリ、プログラム可能なＲＯＭ（ＰＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、様々な他の形態の揮発性又は不揮発性の記憶装置をも含む。

上記の実施形態は相当に詳しく述べられてきたが、いったん上記の開示が十分に理解されると数多くの変形形態及び改造形態が当業者に明らかになるであろう。添付の特許請求項はすべてのそのような変形形態及び改造形態を包含するように解釈されることが意図される。

コンピュータ・システムの一実施形態を例示する図である。 論理ネームスペースの一実施形態を例示する図である。 ファイル・システムの中にデータを保存するために使用されることが可能な処理の一実施形態を例示する図である。 ファイル・システム上で一貫性チェックを実行するために使用されることが可能な処理の一実施形態を例示する図である。 物理ファイル・システムの一実施形態の一般化されたブロック図である。 コンテナとこれらに関連するｉノードを管理するために使用されることが可能な表のセットの一実施形態を例示する図である。 コンテナとこれらに関連するブロックを管理するために使用されることが可能な表のセットの一実施形態を例示する図である。 コンテナとこれらに関連するリンクを管理するために使用されることが可能なコンテナ・リンケージ表の一実施形態を例示する図である。 ファイル・システムの中にデータを保存するために使用されることが可能な処理の一実施形態を例示する図である。 コンテナの境界を横切るファイル・システムのオペレーションを追跡するために使用されることが可能な処理の一実施形態を例示する図である。 エラーに関してファイル・システムを走査するために使用されることが可能な処理の一実施形態を例示する図である。

符号の説明

１００ コンピュータ・システム
１１０ 大域リソース管理部
１２０ 物理ファイル・システム
１３０ 論理ネームスペース
２１０ ルートノード
２２０〜２４２ ノード
３０２、３０４、８００、９００、１０００ 処理
４１０、４２０、４３０、４４０、４５０ コンテナ
４１２、４２２、４３２、４４２、４５２ メタデータ部
４１４、４２４、４３４、４４４、４５４ 記憶部
４６１、４６２、４６３、４６５、４６６、４６７、４６８ リンク
５１０ コンテナ状態表
５１２、５２２、６２２、６４２ コンテナＩＤ
５１４、５１６ 状態ビット
５２０、５４１ ｉノード・セット所有権表
５２４ ｉノード・セットＩＤ
５３０ ｉノード・セット集計表
５３１〜５３８、６３１〜６３８、７１１〜７１８、７５１〜７５８ 項目
５４２ 割り当てられたｉノード総数
５４３ 空いているｉノードの総数
５４４ ディレクトリのｉノード総数
６２０ ブロック・セット所有権表
６３０ ブロック・セット集計表
６４１ ブロック・セットＩＤ
６４３ ブロック・セット集計
７１０、７５０ コンテナ・リンケージ表
７２２、７４２、７８２ タイプ
７２３、７４３、７８３ 内部ｉノードＩＤ
７２４、７８４ 外部ｉノードＩＤ
７４４ 内部ファイルＩＤ

Claims (20)

1. 保存データ及び保存メタデータを含むファイル・システムと、
   前記ファイル・システムに連結された処理用素子とを含むコンピュータ・システムであって、
   ファイル・システム・エラーが起こったことを検出したことに応答して前記処理用素子が、
   前記検出エラーに該当する前記ファイル・システムの第１のコンテナを識別し、
   前記第１のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行し、
   前記ファイル・システムの前記第１のコンテナと第２のコンテナとの間に第１の双方向リンクが存在するかどうか判定し、
   前記第１の双方向リンク内のエラーを検出したことに応答して前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行するように構成されるコンピュータ・システム。
2. 前記第１の双方向リンク内でエラーが見つかった場合に、前記処理用素子が、
   前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行し、
   前記第２のコンテナと第３のコンテナとの間に第２の双方向リンクが存在するかどうか判定し、
   前記第２の双方向リンク内のエラーを検出したことに応答して前記第３のコンテナ内に含まれるファイル・データとそれに関連するメタデータの一貫性チェックを実行するようにさらに構成される、請求項１に記載のシステム。
3. 前記第１と第２のコンテナの各々が、データ記憶の割り当て単位と、関連するメタデータ記憶の単位とを含む前記ファイル・システムの動的に作成された可変サイズの部分を含み、所定のコンテナ内のメタデータが前記所定のコンテナ内のデータを排他的に参照する、請求項１に記載のシステム。
4. 新たなファイル・データを保存したいという要求を受信したことに応答して、前記処理用素子が、
   論理ネームスペース内で前記新たなファイル・データにリンクされるデータを含む前記ファイル・システムのターゲット・コンテナを識別し、
   前記新たなファイル・データが新たなディレクトリを含まない場合に、又は前記新たなファイル・データが新たなディレクトリを含み、かつ前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有する場合に、前記新たなファイル・データを前記ターゲット・コンテナ内に保存し、
   前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有さない場合に、
   リンクされたコンテナを作成し、
   前記ファイル・データを前記リンクされたコンテナ内に保存し、
   前記ターゲット・コンテナと前記リンクされたコンテナとの間の双方向リンクを保存するようにさらに構成される、請求項３に記載のシステム。
5. 前記処理用素子が、前記ファイル・システムの第３のコンテナと前記ファイル・システムの第４のコンテナとの間の双方向リンクを、前記第３のコンテナに保存されたファイル・データと前記第４のコンテナに保存されたファイル・データとの間の論理ネームスペース内の接続を作成するファイル・システムのオペレーションに応答して保存するようにさらに構成される、請求項４に記載のシステム。
6. 前記処理用素子が、複数のコンテナの間の双方向リンクの表を保持するようにさらに構成される、請求項１に記載のシステム。
7. 前記表が少なくとも一対の項目を含み、各々の項目がソース・コンテナ、ソースｉノード、宛先ｉノードを識別し、
   所定の項目のソースｉノードが前記所定の項目のソース・コンテナに該当し、
   項目の所定の対に関して、第１の項目の宛先ｉノードが第２の項目のソースｉノードと同じである、請求項６に記載のシステム。
8. ファイル・システム・エラーが起こったことを検出するステップと、
   前記検出エラーに該当する第１のコンテナを識別するステップと、
   前記第１のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行するステップと、
   前記第１のコンテナと第２のコンテナとの間に第１の双方向リンクが存在するかどうか判定するステップと、
   前記第１の双方向リンク内のエラーを検出したことに応答して前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行するステップとを含む方法。
9. 前記第１の双方向リンク内でエラーが見つかった場合に、
   前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行するステップと、
   前記第２のコンテナと第３のコンテナとの間に第２の双方向リンクが存在するかどうか判定するステップと、
   前記第２の双方向リンク内のエラーを検出したことに応答して前記第３のコンテナ内に含まれるファイル・データとそれに関連するメタデータの一貫性チェックを実行するステップとをさらに含む、請求項８に記載の方法。
10. 前記第１と第２のコンテナの各々が、データ記憶の割り当て単位と、関連するメタデータ記憶の単位とを含む前記ファイル・システムの動的に作成された可変サイズの部分を含み、所定のコンテナ内のメタデータが前記所定のコンテナ内のデータを排他的に参照する、請求項８に記載の方法。
11. 新たなファイル・データを前記ファイル・システム内に保存したいという要求を受信したことに応答して、
    論理ネームスペース内で前記新たなファイル・データにリンクされるデータを含むターゲット・コンテナを識別するステップと、
    前記新たなファイル・データが新たなディレクトリを含まない場合に、又は前記新たなファイル・データが新たなディレクトリを含み、かつ前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有する場合に、前記新たなファイル・データを前記ターゲット・コンテナ内に保存するステップと、
    前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有さない場合に
    リンクされたコンテナを作成するステップと、
    前記ファイル・データを前記リンクされたコンテナ内に保存するステップと、
    前記ターゲット・コンテナと前記リンクされたコンテナとの間の双方向リンクを保存するステップとをさらに含む、請求項１０に記載の方法。
12. 第３のコンテナと第４のコンテナとの間の双方向リンクを、前記第３のコンテナに保存されたファイル・データと前記第４のコンテナに保存されたファイル・データとの間の論理ネームスペース内の接続を作成するファイル・システムのオペレーションに応答して保存するステップをさらに含む、請求項１１に記載の方法。
13. 複数のコンテナの間の双方向リンクの表を保持するステップをさらに含む、請求項９に記載の方法。
14. 前記表が少なくとも一対の項目を含み、各々の項目がソース・コンテナ、ソースｉノード、及び宛先ｉノードを識別し、
    所定の項目のソースｉノードが前記所定の項目のソース・コンテナに該当し、
    項目の所定の対に関して、第１の項目の宛先ｉノードが第２の項目のソースｉノードと同じである、請求項１３に記載の方法。
15. プロセッサによって、
    ファイル・システム・エラーが起こったことを検出すること、
    前記検出エラーに該当する第１のコンテナを識別すること、
    前記第１のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行すること、
    前記第１のコンテナと第２のコンテナとの間に第１の双方向リンクが存在するかどうか判定すること、
    前記第１の双方向リンク内のエラーを検出したことに応答して前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行すること
    を実行可能なコンピュータ命令を保存するコンピュータで読み取り可能な記憶媒体。
16. 前記第１の双方向リンク内でエラーが見つかった場合に、前記命令が、
    前記第２のコンテナ内に含まれるファイル・データとメタデータの一貫性チェックを実行すること、
    前記第２のコンテナと第３のコンテナとの間に第２の双方向リンクが存在するかどうか判定すること、
    前記第２の双方向リンク内のエラーを検出したことに応答して前記第３のコンテナ内に含まれるファイル・データとそれに関連するメタデータの一貫性チェックを実行することをさらに実行可能である、請求項１５に記載のコンピュータで読み取り可能な記憶媒体。
17. 前記第１と第２のコンテナの各々が、データ記憶の割り当て単位と、関連するメタデータ記憶の単位とを含む前記ファイル・システムの動的に作成された可変サイズの部分を含み、所定のコンテナ内のメタデータが前記所定のコンテナ内のデータを排他的に参照する、請求項１５に記載のコンピュータで読み取り可能な記憶媒体。
18. 新たなファイル・データを前記ファイル・システム内に保存したいという要求を受信したことに応答して、前記命令が、
    論理ネームスペース内で前記新たなファイル・データにリンクされるデータを含むターゲット・コンテナを識別すること、
    前記新たなファイル・データが新たなディレクトリを含まない場合に、又は前記新たなファイル・データが新たなディレクトリを含み、かつ前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有する場合に、前記新たなファイル・データを前記ターゲット・コンテナ内に保存すること、
    前記ターゲット・コンテナが、新たなディレクトリを収容するための十分なリソースを有さない場合に、リンクされたコンテナを作成し、前記ファイル・データを前記リンクされたコンテナ内に保存し、かつ前記ターゲット・コンテナと前記リンクされたコンテナとの間の双方向リンクを保存することをさらに実行可能である、請求項１７に記載のコンピュータで読み取り可能な記憶媒体。
19. 前記命令が、第３のコンテナと第４のコンテナとの間の双方向リンクを、前記第３のコンテナに保存されたファイル・データと前記第４のコンテナに保存されたファイル・データとの間の論理ネームスペース内の接続を作成するファイル・システムのオペレーションに応答して保存することをさらに実行可能である、請求項１８に記載のコンピュータで読み取り可能な記憶媒体。
20. 前記命令が、複数のコンテナの間の双方向リンクの表を保持するためにさらに実行可能であり、
    前記表が少なくとも一対の項目を含み、各々の項目がソース・コンテナ、ソースｉノード、及び宛先ｉノードを識別し、
    所定の項目のソースｉノードが前記所定の項目のソース・コンテナに該当し、
    項目の所定の対に関して、第１の項目の宛先ｉノードが第２の項目のソースｉノードと同じである、請求項１５に記載のコンピュータで読み取り可能な記憶媒体。

Images