(57)【要約】【課題】  クライアントにおいてファイル作成処理に費やされる時間を短縮することが可能となる。【解決手段】  複数のファイルサーバが、メタデータとしてのｉノード番号を分散管理するファイルシステムであって、複数のファイルサーバのうちの所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、複数のファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他のファイルサーバに貸し出し、クライアントからファイル作成処理の要求を受けた所定のファイルサーバは、貸し出されたｉノード番号を用いてｉノード情報を作成し、作成されたｉノード情報を前記クライアントへ送信する。【選択図】  図１２
2020101919.tif 000002
【特許請求の範囲】
【請求項１】
複数のファイルサーバが、メタデータとしてのｉノード番号を分散管理するファイルシステムであって、
複数の前記ファイルサーバのうちの所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、複数の前記ファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他の前記ファイルサーバに貸し出し、
クライアントから前記ファイル作成処理の要求を受けた所定の前記ファイルサーバは、貸し出された前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信する
ことを特徴とするファイルシステム。
【請求項２】
所定の前記ファイルサーバは、前記ｉノード情報の前記クライアントへの送信と並行して、所定の前記ファイルサーバに前記ｉノード番号の一部を貸し出した他の前記ファイルサーバに対して、前記ｉノード情報を保存する要求を送信することを特徴とする請求項１記載のファイルシステム。
【請求項３】
複数の前記ファイルサーバは、他の前記ファイルサーバに対して貸し出している前記ｉノード番号の数が一定数を下回った場合に、他の前記ファイルサーバに対して前記ｉノード番号を追加で貸し出すことを特徴とする請求項２に記載のファイルシステム。
【請求項４】
所定の前記ファイルサーバに対して前記ｉノード番号の一部を貸し出した他の前記ファイルサーバは、前記クライアントから前記ｉノード情報の参照または更新を要求された場合、前記ｉノード情報が存在するか否かの判定、および前記ｉノード番号が貸出中であるか否かの判定を行い、前記各判定に応じた応答を前記クライアントに送信する
ことを特徴とする請求項１乃至３のいずれか１項に記載のファイルシステム。
【請求項５】
複数の前記ファイルサーバのそれぞれは、
借用ｉノード番号テーブルを用いて、他の前記ファイルサーバから貸し出された前記ｉノード番号を管理し、
貸出ｉノード番号テーブルを用いて、他の前記ファイルサーバへ貸し出した前記ｉノード番号を管理する
ことを特徴とする請求項１乃至４のいずれか１項に記載のファイルシステム。
【請求項６】
前記借用ｉノード番号テーブルは、開始ｉノード番号と、終了ｉノード番号と、借用元ファイルサーバと、未返却の前記ｉノード番号の数を示す未返却数と、借用した前記ｉノード番号の返却／未返却の状況を示す未返却ビットマップとを含む
ことを特徴とする請求項５に記載のファイルシステム。
【請求項７】
前記貸出ｉノード番号テーブルは、開始ｉノード番号と、終了ｉノード番号と、貸出先ファイルサーバと、未返却の前記ｉノード番号の数を示す未返却数と、借用した前記ｉノード番号の返却／未返却の状況を示す未返却ビットマップとを含む
ことを特徴とする請求項５または６に記載のファイルシステム。
【請求項８】
メタデータとしてのｉノード番号を分散管理するファイルシステムを構成するファイルサーバであって、
前記ファイルサーバにおいてファイル作成処理が実行されるのに先だって、他のファイルサーバから、前記他のファイルサーバが管理するｉノード番号の一部を借り受け、クライアントから前記ファイル作成処理の要求を受けた場合、借り受けた一部の前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信する制御手段
を備えることを特徴とするファイルサーバ。
【請求項９】
複数のファイルサーバが、メタデータとしてのｉノード番号を分散管理するファイルシステムにおけるメタデータ管理方法であって、
複数の前記ファイルサーバのうちの所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、複数の前記ファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他の前記ファイルサーバに貸し出し、
クライアントから前記ファイル作成処理の要求を受けた場合、所定の前記ファイルサーバは、貸し出された前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信する
ことを特徴とするメタデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステム、ファイルサーバ、およびメタデータ管理方法に関する。
【背景技術】
【０００２】
主にＨＰＣ（High Performance Computing）で使用されるファイルシステムであり、複数のファイルサーバで構成される分散並列ファイルシステムが知られている。分散並列ファイルシステムにおいて、ファイルデータやメタデータは、複数のファイルサーバで分散管理される。よって、分散並列ファイルシステムは、これまでのＮＦＳ（Network File System）のように１台のファイルサーバのみでファイルシステムを構成する場合と比較して、特定のファイルサーバへの負荷集中を抑制する効果を発揮する。
【０００３】
ところで、ファイル作成処理において、親ディレクトリのディレクトリエントリ情報と新規ファイルのｉノード情報の両方を更新する必要がある。メタデータを複数のファイルサーバで分散管理する分散並列ファイルシステムでは、これらを管理するファイルサーバが別々となる場合がある。この場合、ファイルサーバ間で通信を行い、その結果を待ち合わせる必要がある。
【０００４】
メタデータには、各ファイルのサイズ・更新日時・アクセス権・ｉノード番号などを示すｉノード情報と、各ディレクトリに存在するファイルのファイル名とそのｉノード番号を示すディレクトリエントリ情報と、が含まれる。ｉノード番号とは、ファイルシステム内でファイルを識別するための一意な番号である。
【０００５】
図１６は、一般的な分散並列ファイルシステム１の構成を示すブロック図である。図１６では、３台のファイルサーバ１０、２０、３０にて分散並列ファイルシステムが構成されている。分散並列ファイルシステム１において、ｉノード番号は、当該番号に対応するファイルを管理するファイルサーバによって管理されている。たとえば、図１６のファイルサーバ１０はｉノード番号0x00000000〜0x00ffffffを管理し、ファイルサーバ２０はｉノード番号0x01000000〜0x01ffffffを管理し、ファイルサーバ３０はｉノード番号0x02000000〜0x02ffffffを管理している。
【０００６】
上記管理により、クライアント（図１６において不図示）は、ｉノード番号の情報のみでどのファイルサーバにアクセスすれば良いかを決定することができる。従って、各ファイルサーバは、他のファイルサーバとの通信を行うことなく新規ファイルのｉノード番号を決定することが可能である。
【０００７】
分散並列ファイルシステム１では、あるディレクトリを管理するファイルサーバと、その直下のファイルを管理するファイルサーバとが異なる場合がある。
【０００８】
ここで、ファイルシステムのディレクトリｄｉｒ１のメタデータがファイルサーバ１０で管理されており、この直下に新たなファイルｆｉｌｅ１を作成し、ファイルｆｉｌｅ１のメタデータがファイルサーバ２０で管理される場合を考える。
【０００９】
図１７は、図１６に示される一般的な分散並列ファイルシステム１の動作を説明するためのフローチャートである。
【００１０】
クライアントは、ファイルサーバ１０に対して、ディレクトリｄｉｒ１のｉノード番号と、新たに作成するファイル名ｆｉｌｅ１と、ファイルｆｉｌｅ１のｉノード番号以外のｉノード情報を引数として、ファイル作成要求を送信する。
【００１１】
ファイルサーバ１０は、ディレクトリｄｉｒ１のディレクトリエントリ情報内にｆｉｌｅ１のエントリを仮作成する（ステップＳ１）。ファイルサーバ１０は、ファイルｆｉｌｅ１を管理するファイルサーバを決定する（ステップＳ２）。ディレクトリｄｉｒ１の直下について各ファイルサーバが管理するファイル数が均等になることが求められるため、ファイルサーバは、たとえば、ラウンドロビン方式により決定される。つまり、ファイルサーバ１０が管理するディレクトリ直下に最初に作成されるファイルはファイルサーバ２０が管理し、２番目に作成されるファイルはファイルサーバ３０が管理し、３番目に作成されるファイルはファイルサーバ１０が管理する、というルールが採用される。このルールに基づくと、１番目に作成されるファイルｆｉｌｅ１を管理するファイルサーバとしては、ファイルサーバ２０が選択される。
【００１２】
ファイルサーバ１０は、ファイルｆｉｌｅ１を管理するファイルサーバ２０に対して、新たに作成するファイルの名前ｆｉｌｅ１と、ｉノード番号以外のｉノード情報の一部とを引数として、「ｉノード情報作成要求」を送信する（ステップＳ３）。
【００１３】
ファイルサーバ２０は、自身が管理するｉノード番号0x01000000〜0x01ffffffのうち、未使用のものをファイルｆｉｌｅ１に割り当てる（ステップＳ４）。ファイルサーバ２０は、ファイルｆｉｌｅ１のｉノード情報を、ファイルサーバ２０のメタデータ保存ストレージ（図１６において不図示）に保存する（ステップＳ５）。ファイルサーバ２０は、ファイルサーバ１０に対して、ファイルｆｉｌｅ１のｉノード番号を含む「ｉノード情報」を、「ｉノード情報作成要求」の応答として送信する（ステップＳ６）。
【００１４】
ファイルサーバ１０は、「ｉノード情報」に含まれるｉノード番号を使用して、ディレクトリｄｉｒ１のディレクトリエントリ情報を更新する（ステップＳ７）。さらに、ファイルサーバ１０は、ファイルサーバ１０のメタデータ保存ストレージ（図１６において不図示）に保存する。
【００１５】
そして、ファイルサーバ１０は、クライアントに対して、ファイルｆｉｌｅ１の「ｉノード情報」を「ファイル作成要求」の応答として送信する（ステップＳ８）。
【００１６】
特許文献１には、マスターネームノードでファイルが作成された場合に、マスターネームノードとスレーブネームノードとの間で、ファイル及びメタ情報の同期を行う分散ファイルシステムについての記載がある。
【００１７】
特許文献２には、ｉノードファイルおよびデータファイルのそれぞれは、同じストレージサーバー装置に記憶されても、異なるストレージサーバー装置に記憶されてもよいことが記載されている。また、引用文献２には、ストレージサーバー装置の選択には、ラウンドロビン方式、容量選択方式、あるいはネットワーク的に近くのストレージサーバー装置を選択する方式があることが記載されている。
【先行技術文献】
【特許文献】
【００１８】
【特許文献１】特開２０１５−０３５０２０号公報
【特許文献２】特開２０１０−２８７０３６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１９】
上述したように、一般的な分散並列ファイルシステムの場合、クライアントから「ファイル作成要求」を受けてから「ｉノード情報」を送信するまでの間にファイルサーバ間において通信が行われ、その通信の終了を待たなければならない。従って、クライアントにおいてファイル処理に費やされる時間が増大する虞がある。また、特許文献１や特許文献２の技術では上記課題を解決することは困難である。
【００２０】
本発明は、上記課題を解決するためになされたものであり、クライアントにおいてファイル作成処理に費やされる時間を短縮することが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明のファイルシステムは、複数のファイルサーバが、メタデータとしてのｉノード番号を分散管理するファイルシステムであって、複数の前記ファイルサーバのうちの所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、複数の前記ファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他の前記ファイルサーバに貸し出し、クライアントから前記ファイル作成処理の要求を受けた所定の前記ファイルサーバは、貸し出された前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信する。
【００２２】
本発明のファイルサーバは、メタデータとしてのｉノード番号を分散管理するファイルシステムを構成するファイルサーバであって、前記ファイルサーバにおいてファイル作成処理が実行されるのに先だって、他のファイルサーバから、前記他のファイルサーバが管理するｉノード番号の一部を借り受け、クライアントから前記ファイル作成処理の要求を受けた場合、借り受けた一部の前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信する制御部を備える。
【００２３】
本発明のメタデータ管理方法は、複数のファイルサーバが、メタデータとしてのｉノード番号を分散管理するファイルシステムにおけるメタデータ管理方法であって、複数の前記ファイルサーバのうちの所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、複数の前記ファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他の前記ファイルサーバに貸し出し、クライアントから前記ファイル作成処理の要求を受けた場合、所定の前記ファイルサーバは、貸し出された前記ｉノード番号を用いてｉノード情報を作成し、作成された前記ｉノード情報を前記クライアントへ送信することを特徴とする。
【発明の効果】
【００２４】
本発明によれば、クライアントにおいてファイル作成処理に費やされる時間を短縮することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】本発明の第１の実施形態に係るファイルシステムの構成例を説明するためのブロック図である。
【図２】図１に示される借用ｉノード番号テーブルのデータ構成例（たとえば、更新前のデータ構成例）を示す図である。
【図３】図１に示される貸出ｉノード番号テーブルのデータ構成例（たとえば、更新前のデータ構成例）を示す図である。
【図４】第１の実施形態に係るファイルシステムの動作例（メタデータ管理方法の一環であって、詳細には「ファイル作成」の処理手順例）を説明するためのフローチャートである。
【図５】第１の実施形態に係るファイルシステムの動作例（メタデータ管理方法の一環であって、詳細には「ｉノード情報保存要求」の処理手順例）を説明するためのフローチャートである。
【図６】図１に示される借用ｉノード番号テーブルのデータ構成例（たとえば、更新後のデータ構成例）を示す図である。
【図７】図１に示される貸出ｉノード番号テーブルのデータ構成例（たとえば、更新後のデータ構成例）を示す図である。
【図８】図１に示される借用ｉノード番号テーブルのデータ構成例（たとえば、更新後のデータ構成例）を示す図である。
【図９】図１に示される貸出ｉノード番号テーブルのデータ構成例（たとえば、更新後のデータ構成例）を示す図である。
【図１０】第１の実施形態に係るファイルシステムの動作例（メタデータ管理方法の一環であって、詳細には「ｉノード情報取得」の処理手順例）を説明するためのフローチャートである。
【図１１】第１の実施形態に係るファイルシステムの動作例（メタデータ管理方法の一環であって、詳細には「貸出中ｉノード問い合わせ」の処理手順例）を説明するためのフローチャートである。
【図１２】本発明の第２の実施形態のファイルシステムの構成例を説明するブロック図である。
【図１３】図１２に示すファイルシステムの動作（メタデータ管理方法）を説明するためのフローチャートである。
【図１４】本発明の第３の実施形態のファイルサーバの構成例を説明するブロック図である。
【図１５】図１４に示すファイルサーバの動作例を説明するためのフローチャートである。
【図１６】一般的な分散並列ファイルシステムの構成を示すブロック図である。
【図１７】図１６に示される分散並列ファイルシステムの動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００２６】
［第１の実施形態］
（構成の説明）
図１は、本発明の第１の実施形態に係るファイルシステム５０の構成例を説明するためのブロック図である。ファイルシステム５０は、メタデータを分散管理するファイルシステム、たとえば、分散並列ファイルシステムである。ファイルシステム５０は、複数のファイルサーバ１００、１０１、１０２と、クライアント１０４と、ファイルサーバ１００、１０１、１０２と、を含む。上記構成要素同士は、ネットワーク１０６を介して接続される。なお、図１では、ファイルサーバが３つの場合が例示されているがこれに限定されることはなく、ファイルサーバの数は、２であってもよく、あるいは、４以上であってもよい。
【００２７】
ファイルサーバ１００、１０１、１０２のそれぞれは、借用ｉノード番号テーブル２００と、貸出ｉノード番号テーブル２０２と、メタデータ保存ストレージ２０４と、を備える。
【００２８】
ファイルサーバ１００、１０１、１０２は、たとえば、ネットワーク上で情報（データやサービス等）を提供しているハードウェアが搭載された機器のことである。ここで、ハードウェアとは、たとえば、ＩＣやＦＰＧＡ等の電子回路、コンピュータ（たとえば、ＣＰＵがメモリに記憶されたプログラムを実行することにより機能を実現する装置）、あるいは電子回路とコンピュータが組み合わせされた装置のことを指す。上記において、ＩＣはIntegrated Circuitの略であり、ＦＰＧＡはField Programmable Gate Arrayの略であり、ＣＰＵはCentral Processing Unitの略である。
【００２９】
ファイルサーバ１００、１０１、１０２は、借用ｉノード番号テーブル２００を用いて、他のファイルサーバから貸し出されたｉノード番号を管理し、貸出ｉノード番号テーブル２０３を用いて、他のファイルサーバへ貸し出したｉノード番号を管理する。
【００３０】
なお、図１では、説明をより明りょうなものとするために、ファイルサーバ１００の構成のみが記載されているが、ファイルサーバ１０１、１０２もファイルサーバ１００と同一構成である。
【００３１】
図２は、借用ｉノード番号テーブル２００のデータ構成例を示す図である。借用ｉノード番号テーブル２００は、項目として、たとえば、開始ｉノード番号と、終了ｉノード番号と、借用元ファイルサーバと、未返却のｉノード番号の数を示す未返却数と、借用したｉノード番号の返却／未返却の状況を示す未返却ビットマップと、を含む。
【００３２】
未返却ビットマップは、（終了ｉノード番号−開始ｉノード番号＋１）ビットを持つビットマップであり、未返却であればビットには“１”、返却済みであればビットには“０”が設定される。例として、図２の１行目について、未返却ビットマップの先頭ビットが１であるため、ｉノード番号0x01ff0000は未返却であることを示す。また、仮に２番目のビットが０であれば、ｉノード番号0x01ff0001が返却済みであることを示す。
【００３３】
図３は、貸出ｉノード番号テーブル２０２のデータ構成例を示す図である。貸出ｉノード番号テーブル２０２は、項目として、たとえば、開始ｉノード番号と、終了ｉノード番号と、貸出先ファイルサーバと、未返却数と、未返却ビットマップと、を含む。未返却ビットマップの内容は借用ｉノード番号テーブル２００と同様である。
【００３４】
メタデータ保存ストレージ２０４は、メタデータを保存するための磁気ディスク装置などの補助記憶装置である。ｉノード番号をキーとして、そのｉノード情報またはディレクトリエントリ情報の読み書きを行うことが可能である。
（動作の説明）
図４は、ファイルシステム５０の動作例、詳細には「ファイル作成」の処理手順例を説明するためのフローチャートである。
【００３５】
なお、図４の処理で説明する処理が実行される前に、具体的には、ファイルシステム５０においてファイル作成処理が実行されるのに先だって、各ファイルサーバは他のファイルサーバのそれぞれに対して、１０２４個ずつｉノード番号を貸し出しているものとする。ここで、図２はファイルサーバ１００の借用ｉノード番号テーブル２００の一例を示し、図３はファイルサーバ１０１の貸出ｉノード番号テーブル２０２の一例を示している。
【００３６】
以下では、クライアント１０４が、ディレクトリｄｉｒ１の直下にファイルｆｉｌｅ１を作成する場合の動作について説明する。ディレクトリｄｉｒ１のメタデータは、ファイルサーバ１００で管理されているものとする。
【００３７】
ファイルサーバ１００は、ネットワーク１０６を介してクライアント１０４からファイル作成要求を受け取ると、ディレクトリｄｉｒ１のディレクトリエントリ情報について、ファイルｆｉｌｅ１のエントリを仮作成する（ステップＳ１０）。
【００３８】
ファイルサーバ１００は、ファイルｆｉｌｅ１のメタデータを管理するファイルサーバを決定する（ステップＳ１１）。本動作説明では、ファイルｆｉｌｅ１のメタデータを管理するファイルサーバとして、ファイルサーバ１０１が選択されたものとする。
【００３９】
ファイルサーバ１００は、図２の借用ｉノード番号テーブル２００から、借用元ファイルサーバが１０１である行（“エントリ”とも呼ばれる）を検索する（ステップＳ１２）。この結果、図２の１行目が選択される。
【００４０】
ファイルサーバ１００は、選択された行の未返却ビットマップを参照し、ビットが１になっているもの（すなわち、未返却のもの）を１つ選択し、これに対応するｉノード番号を新規ファイルのｉノード番号として割り当てる（ステップＳ１３）。
【００４１】
さらに、ファイルサーバ１００は、未返却数を１減算するとともに、選択されたビットを０に変更する。最終的に未返却数が０になった場合、ファイルサーバ１００は、その行を借用ｉノード番号テーブル２００から削除する。たとえば、図２において、未返却ビットマップの先頭ビットが１であるため、これに対応するｉノード番号0x01ff0000が新規ファイルのｉノード番号として割り当てられる。その後、借用ｉノード番号テーブル２００は、図６のように更新される。
【００４２】
ファイルサーバ１００は、採用されたｉノード番号を使用してディレクトリｄｉｒ１のディレクトリエントリ情報を更新し（ステップＳ１４）、「ファイル作成要求」の応答としてのｉノード情報をクライアント１０４へ送信する（ステップＳ１５）。
【００４３】
ファイルサーバ１００は、ステップＳ１４およびステップＳ１５の各処理と並行して、ファイルサーバ１０１に対して、ｉノード情報保存要求を送信する（ステップＳ２０）。ｉノード情報保存要求は、ファイルサーバ１００にｉノード番号の一部を貸し出したファイルサーバ１０１に対してｉノード情報を保存させる要求である。
【００４４】
図５は、ファイルシステム５０の動作例、詳細には、図４に示されるｉノード情報保存要求（ステップＳ２０）の詳細な処理手順例を説明するフローチャートである。
【００４５】
ファイルサーバ１００は、ファイルサーバ１０１に対してファイルｆｉｌｅ１のｉノード情報を送信する（ステップＳ２１）。
【００４６】
ファイルサーバ１０１は、ファイルｆｉｌｅ１のｉノード情報を、自身のメタデータ保存ストレージ２０４に保存する（ステップＳ３０）。
【００４７】
ファイルサーバ１０１は、自身の貸出ｉノード番号テーブル２０２を参照して、貸出先ファイルサーバが１００であり、かつ送信されたｉノード番号が含まれる行を選択する。この結果、図３の１行目が選択される。次に、ファイルサーバ１０１は、貸出ｉノード番号テーブル２０２を更新する（ステップＳ３１）。具体的には、ファイルサーバ１０１は、貸出ｉノード番号テーブル２０２（図３参照）の１行目において、未返却数を１減算し、送信されたｉノード番号に対応する未返却ビットマップのビットを０に変更する。この結果、未返却数が０になった場合、ファイルサーバ１０１は、その行を貸出ｉノード番号テーブル２０２から削除する。図３において、ファイルｆｉｌｅ１のｉノード番号は0x01ff0000であるため、これに対応する先頭ビットが０に変更される。その後、貸出ｉノード番号テーブル２０２は、図７のように更新される。
【００４８】
次に、ファイルサーバ１０１は、ファイルサーバ１００に対して、処理の完了を応答するとともに、ファイルサーバ１００に対して貸し出しているｉノード番号の数が一定数を下回った場合にはｉノード番号を追加で貸し出す（ステップＳ３２）。たとえば、図７の状態から、ファイルサーバ１００の未返却数が１２８以下になった状態を考える。この場合、ファイルサーバ１０１は、新たにｉノード番号0x01ff0800〜0x01ff0bffの１０２４個をファイルサーバ１００に貸し出す。ファイルサーバ１０１の貸出ｉノード番号テーブル２０２は、図９のように更新される。この場合、ファイルサーバ１００の借用ｉノード番号テーブル２００は、図８のように更新される（つまり、図８において、３行目が追加される）。
（効果の説明）
以上説明した第１の実施形態では、各ファイルサーバは、管理しているｉノード番号の一部を他のファイルサーバに貸し出している。しかもそれらの貸出は、ファイルシステム５０においてファイル作成処理が実行されるのに先だって行われる。よって、いずれかのファイルサーバにおいてファイル作成処理が実行される場合、そのいずれかのファイルサーバは、貸し出されたｉノード番号を用いてｉノード情報を作成し、ファイルサーバ間の通信を行うことなく、作成されたｉノード情報をクライアント１０４へ送信する。従って、本実施形態によれば、クライアント１０４においてファイル作成処理に費やされる時間を短縮することが可能となる。
（変形例１）
上記処理において、ファイルｆｉｌｅ１のｉノード情報がクライアント１０４に返却された後、ファイルサーバ１０１に対する「ｉノード情報保存要求」に関する処理がまだ完了していない場合が想定される。この状態で、クライアント１０４からファイルサーバ１０１に対してファイルｆｉｌｅ１のｉノード情報の参照または更新が必要な処理が要求された場合、ファイルサーバ１０１にはまだファイルｆｉｌｅ１のｉノード情報が存在しないため、ファイルサーバ１００の処理を待ち合わせる必要がある。フローチャート図１０、図１１を使用し、ｉノード情報取得時の動作について説明する。
【００４９】
図１０は、ファイルシステム５０の動作例、詳細には、「ｉノード情報取得」の処理手順例を説明するためのフローチャートである。
【００５０】
図１０に示すように、クライアント１０４から、ファイルｆｉｌｅ１のｉノード番号0x01ff0000を引数とした「ｉノード情報取得要求」を受信すると、ファイルサーバ１０１は、メタデータ保存ストレージ２０４を読み込み、ｉノード番号0x01ff0000のｉノード情報の取得を試みる（ステップＳ４０）。
【００５１】
ファイルサーバ１０１は、ｉノード番号0x01ff0000のｉノード情報がメタデータ保存ストレージ２０４に存在するかどうかを判定する（ステップＳ４１）。ｉノード情報が存在する場合（ステップＳ４１においてＹｅｓ）、ファイルサーバ１０１は、そのｉノード情報をクライアント１０４に返却し（ステップＳ４２）、本フローチャートの処理を終了する。
【００５２】
一方、ｉノード番号0x01ff0000のｉノード情報がメタデータ保存ストレージ２０４に存在しない場合（ステップＳ４１にてＮｏ）、ファイルサーバ１０１は、貸出ｉノード番号テーブル２０２を検索し、ｉノード番号0x01ff0000を含む行を選択する（ステップＳ４３）。
【００５３】
ファイルサーバ１０１は、ｉノード番号が貸し出し中か否かを判定する（ステップＳ４４）。たとえば、該当する行が存在し、かつ該当する行のｉノード番号0x01ff0000に対応する未返却ビットマップのビットが１の場合、ファイルサーバ１０１は、ｉノード番号が貸し出し中と判断する（ステップＳ４４）。
【００５４】
ｉノード番号が貸し出し中でない場合（ステップＳ４４にてＮｏ）、ファイルサーバ１０１は、メタデータ保存ストレージ２０４を、再度読み込む（ステップＳ４５）。この処理を実行する理由は、図１０におけるステップＳ４０、Ｓ４１、Ｓ４３の処理の間に、図５のステップＳ２１、Ｓ３０、Ｓ３１が実行される可能性があるためである。次に、ファイルサーバ１０１は、メタデータ保存ストレージ２０４にｉノード番号0x01ff0000のｉノード情報が存在する場合にはそのｉノード情報をクライアント１０４に返却し、一方、存在しない場合には「ファイルが存在しない」ことを示すエラーを、クライアント１０４に返却し（ステップＳ４２）、本フローチャートの処理を終了する。
【００５５】
一方、ｉノード番号が貸し出し中と判断された場合（ステップＳ４４にてＹｅｓ）、ファイルサーバ１０１は、「貸出中ｉノード問い合わせ」を実行する（ステップＳ５０）。
【００５６】
図１１は、ファイルシステム５０の動作例、詳細には、図１０に示される貸出中ｉノード問い合わせ（ステップＳ５０）の詳細な処理手順例を説明するフローチャートである。
【００５７】
ファイルサーバ１０１は、貸出ｉノード番号テーブル２０２の該当した行の貸出先ファイルサーバの情報を参照する。ファイルサーバ１０１は、参照した結果として、たとえば、ファイルサーバ１００を得る。次に、ファイルサーバ１０１は、ファイルサーバ１００に対して、ｉノード番号0x01ff0000を返却済みかどうかの問い合わせ要求を送信する（ステップＳ５１）。
【００５８】
ファイルサーバ１００は、借用ｉノード番号テーブル２００を検索し、ｉノード番号0x01ff0000が含まれる行を選択する。該当する行が存在し、かつ未返却ビットマップのｉノード番号0x01ff0000に対応するビットが１の場合、ファイルサーバ１００は、ｉノード番号は「未返却」であり、ビットが０の場合、ｉノード番号は「返却済み」と判断する（ステップＳ５２）。
【００５９】
ファイルサーバ１００は、ファイルサーバ１０１に対して、ｉノード番号0x01ff0000の返却状態を応答する（ステップＳ５３）。たとえば、ファイルサーバ１００の借用ｉノード番号テーブル２００が図６の状態において、ｉノード番号0x01ff0000が返却済みかどうかの問い合わせを受けた場合、ｉノード番号0x01ff0000は１行目に含まれていることから、ファイルサーバ１００は、１行目を選択する。また、ｉノード番号0x01ff0000に対応するのは未返却ビットマップの先頭ビットであり、その値が０になっているため、ファイルサーバ１００は、ｉノード番号は「返却済み」と判断する。
【００６０】
ファイルサーバ１０１は、ファイルサーバ１００から受信したｉノード番号0x01ff0000の返却状態を判定する（ステップＳ５４）。返却状態が「未返却」の場合（ステップＳ５４にてＹｅｓ）、ファイルサーバ１０１は、ｉノード番号0x01ff0000に対応するファイルは存在しないと判断する（ステップＳ５５）。その後、ファイルサーバ１０１は、本フローチャートを終了させ、図１０のフローチャートに処理を戻し、判断結果（ｉノード情報＝存在しない）をクライアント１０４に応答する（図１０のステップＳ４２）。
【００６１】
一方、使用状態が「返却済み」の場合（ステップＳ５４にてＮｏ）、ファイルサーバ１０１は、ファイルサーバ１００がｉノード情報保存要求（図４のステップＳ２０）を送信し、さらに、図５のステップＳ３０の処理（ｉノード情報の保存）が完了するのを待ち合わせる（ステップＳ５６）。
【００６２】
そして、ファイルサーバ１０１は、メタデータ保存ストレージ２０４を読み込み（ステップＳ５７）、ｉノード番号0x01ff0000に対応するｉノード情報を取得し、本フローチャートの処理を終了させ、図１０のフローチャートに処理を戻す。そして、ファイルサーバ１０１は、取得したｉノード情報をクライアント１０４に応答する（図１０のステップＳ４２）。
【００６３】
以上説明した変形例１によれば、クライアント１０４からファイルサーバ１０１に対してファイルｆｉｌｅ１のｉノード情報の参照または更新が必要な処理が要求された場合、クライアント１０４に対してより迅速に応答することが可能となる。その理由は、ファイルサーバ１０１が、ｉノード情報が存在するか否かの判定、およびｉノード番号が貸出中であるか否かの判定を行い、クライアント１０４に対して、それらの判定に応じた応答を行うからである。
（変形例２）
以上説明した第１の実施形態では、メタデータ保存ストレージ２０４をファイルサーバごとに持たせていたが、ＳＡＮ（Storage Area Network）を使用することにより、複数のファイルサーバから１つのメタデータ保存ストレージにアクセスできるように構成することが可能である。
【００６４】
また、１台のファイルサーバが障害で使用できなくなった場合には、障害となったファイルサーバが使用していたメタデータ保存ストレージ２０４を、他のファイルサーバに引き継ぐような構成とすることも可能である。このような構成により、ファイルシステム５０を継続的に使用することができるようになる。
［第２の実施形態］
図１２は、本発明の第２の実施形態のファイルシステム３００の構成例を説明するブロック図である。
【００６５】
ファイルシステム３００は、複数のファイルサーバ３１０、３２０、３３０が、メタデータとしてのｉノード番号を分散管理するファイルシステムである。なお、図１２では、ファイルサーバが３つの場合が例示されているがこれに限定されることはなく、ファイルサーバの数は、２であってもよく、あるいは、４以上であってもよい。
【００６６】
図１３は、図１２に示すファイルシステムの動作（メタデータ管理方法）を説明するためのフローチャートである。
【００６７】
所定のファイルサーバにおいてファイル作成処理が実行されるのに先だって、ファイルサーバのそれぞれは、自身が管理するｉノード番号の一部を、他のファイルサーバに貸し出す（ステップＳ３００）
クライアントからファイル作成処理の要求を受けた所定のファイルサーバは、貸し出されたｉノード番号を用いてｉノード情報を作成し、作成されたｉノード情報をクライアントへと送信する（ステップＳ３０１）。
【００６８】
以上説明した第２の実施形態のファイルシステム３００によれば、ファイル作成要求を受けた場合、クライアントに応答を返却するまでの間にファイルサーバ間通信は実施されない。従って、クライアントにおいてファイル作成処理に費やされる時間を短縮することが可能となる。
［第３の実施形態］
図１４は、本発明の第３の実施形態のファイルサーバ４００の構成例を説明するブロック図である。
【００６９】
ファイルサーバ４００は、メタデータとしてのｉノード番号を分散管理するファイルシステムを構成するファイルサーバである。
【００７０】
ファイルサーバ４００は、制御部４０２（制御手段の一例）を備える。制御部４０２は、ファイルサーバ４００においてファイル作成処理が実行されるのに先だって、他のファイルサーバから、この他のファイルサーバが管理するｉノード番号の一部を借り受ける。そして、クライアントからファイル作成処理の要求を受けた場合、制御部４０２は、借り受けた一部のｉノード番号を用いてｉノード情報を作成し、作成したｉノード情報をクライアントへ送信する。
【００７１】
図１５は、図１４に示すファイルサーバ４００の動作例を説明するためのフローチャートである。
【００７２】
制御部４０２は、ファイルサーバ４００においてファイル作成処理が実行されるのに先だって、他のファイルサーバから、この他のファイルサーバが管理するｉノード番号の一部を借り受ける（ステップＳ４００）。
【００７３】
そして、クライアントからファイル作成処理の要求を受けた場合、制御部４０２は、借り受けた一部のｉノード番号を用いてｉノード情報を作成し、作成したｉノード情報をクライアントへ送信する（ステップＳ４０１）。
【００７４】
以上説明した第３の実施形態のファイルサーバ４００によれば、ファイル作成要求を受けた場合、クライアントに応答を返却するまでの間にファイルサーバ間通信は実施されない。従って、クライアントにおいてファイル作成処理に費やされる時間を短縮することが可能となる。
【００７５】
以上、各実施形態を用いて本発明を説明したが、本発明の技術的範囲は、上記各実施形態の記載に限定されない。上記各実施形態に多様な変更又は改良を加えることが可能であることは当業者にとって自明である。従って、そのような変更又は改良を加えた形態もまた本発明の技術的範囲に含まれることは説明するまでもない。また、以上説明した各実施形態において使用される、数値や各構成の名称等は例示的なものであり適宜変更可能である。
【符号の説明】
【００７６】
５０    ファイルシステム
１００、１０１、１０２    ファイルサーバ
１０４    クライアント
１０６    ネットワーク
２００    借用ｉノード番号テーブル
２０３    貸出ｉノード番号テーブル
２０４    メタデータ保存ストレージ
３００    ファイルシステム
３１０、３２０、３３０    ファイルサーバ
４００    ファイルサーバ
４０２    制御部
【図１】
2020101919.tif 000003
【図２】
2020101919.tif 000004
【図３】
2020101919.tif 000005
【図４】
2020101919.tif 000006
【図５】
2020101919.tif 000007
【図６】
2020101919.tif 000008
【図７】
2020101919.tif 000009
【図８】
2020101919.tif 000010
【図９】
2020101919.tif 000011
【図１０】
2020101919.tif 000012
【図１１】
2020101919.tif 000013
【図１２】
2020101919.tif 000014
【図１３】
2020101919.tif 000015
【図１４】
2020101919.tif 000016
【図１５】
2020101919.tif 000017
【図１６】
2020101919.tif 000018
【図１７】
2020101919.tif 000019