JPWO2004055675A1 - ファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステム - Google Patents
ファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステム Download PDFInfo
- Publication number
- JPWO2004055675A1 JPWO2004055675A1 JP2004560587A JP2004560587A JPWO2004055675A1 JP WO2004055675 A1 JPWO2004055675 A1 JP WO2004055675A1 JP 2004560587 A JP2004560587 A JP 2004560587A JP 2004560587 A JP2004560587 A JP 2004560587A JP WO2004055675 A1 JPWO2004055675 A1 JP WO2004055675A1
- Authority
- JP
- Japan
- Prior art keywords
- file
- management
- partition
- sharing
- shared
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理装置であって、全てのファイルサーバに共用され、ファイルおよびディレクトリのメタデータを複数の区画に分割して記憶し、各区画を管理するファイルサーバが定められたメタディスクと、ファイル生成要求を受け付けて生成したファイルが管理分担の対象であることを示す区画番号を含むｉｎｏｄｅをメタディスクに書き込むファイル操作部と、メタディスクに記憶されたｉｎｏｄｅ中の区画番号を用いてファイル操作要求を処理するファイルサーバを決定する要求受付部とを備える。
Description
この発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムならびにファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理装置、ファイル管理プログラムおよびファイル管理方法に関し、特に、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるファイルシステム、ファイル管理装置、ファイル管理プログラムおよびファイル管理方法に関するものである。
近年、複数のファイルサーバが同一のファイルを共用することを可能とするクラスタファイルシステムにおいて、メタデータの管理を複数のファイルサーバに分散する技術が開発されている。ここで、メタデータとは、ファイルおよびディレクトリの名前やファイルデータのディスク上での格納位置などファイル管理のために使用するデータである。このメタデータを特定のファイルサーバだけが管理すると、そのファイルサーバだけに負荷が集中し、システム全体の性能低下を招く。そこで、このメタデータの管理を複数のファイルサーバに分散することによって、クラスタファイルシステムのスケーラビリティの向上が図られている。
たとえば、Ｆｒａｎｋ Ｓｃｈｍｕｃｋ，Ｒｏｇｅｒ Ｈａｓｋｉｎ，″ＧＰＦＳ：Ａ Ｓｈａｒｅｄ−Ｄｉｓｋ Ｆｉｌｅ Ｓｙｓｔｅｍ ｆｏｒ Ｌａｒｇｅ Ｃｏｍｐｕｔｉｎｇ Ｃｌｕｓｔｅｒｓ，″Ｐｒｏｃ．ｏｆ ｔｈｅ ＦＡＳＴ ２００２ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｌｅ ａｎｄ Ｓｔｏｒａｇｅ Ｔｅｃｈｎｏｌｏｇｉｅｓ，ＵＳＥＮＩＸ Ａｓｓｏｃｉａｔｉｏｎ，Ｊａｎｕａｒｙ，２００２．には、ファイルサーバ毎に存在すると想定できるファイルアクセスのローカリティに着目し、ファイル単位にメタデータを管理するファイルサーバ（メタデータサーバ）を動的に変更する方式が開示されている。この方式は、ファイルアクセスが要求されたファイルサーバをそのファイルのメタデータサーバとするもので、ファイルサーバ毎にアクセスするファイルのローカリティが存在する場合に、一つのファイルサーバで処理を完結させ、余分なファイルサーバ間通信を発生させない有効な方式であるといえる。
しかし、この方式では、メタデータサーバのありかが事前に予測不可能なため、どの程度ファイルサーバ間通信が発生することになるかの予測が困難であり、特に属性つきディレクトリ読み出し操作などのファイル操作では、メタデータアクセスのために膨大なファイルサーバ間通信が発生する可能性があるという欠陥がある。またメタデータサーバ決定のため複雑なプロトコルを必要とするという欠陥も存在する。
このようなメタデータサーバを動的に変更する方式の欠陥を解消する方式として、静的にメタデータサーバを決定する方式が考えられる。たとえば、クラスタファイルシステムの名前空間を複数の区画に分割し、各区画の管理をメタデータサーバに分担させ、各メタデータサーバに、分担する区画に属するファイルのメタデータを管理させる方式が考えられる。しかし、単に各区画にその区画を管理するメタデータサーバを静的に割り付けるだけでは、特定の区画のメタデータが増加した場合に、その区画を管理するメタデータサーバの負荷が増大してしまう。
そこで、メタデーダサーバが管理する区画を動的に分割したり、各メタデータサーバが管理する区画を変更したりすることが必要となるが、区画を管理するメタデータサーバが変更になると、メタデータサーバ間のメタデータの移動が必要であり、オーバヘッドが大きくなるという問題がある。また、ファイルシステム内部でファイルを識別するための情報としてメタデータの位置情報を利用している場合には、区画の変更に伴ってメタデータが他のメタデータサーバに移動すると、ファイルの内部識別情報が変わってしまうという問題がある。
従って、この発明は、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるファイルシステム、ファイル管理装置、ファイル管理プログラムおよびファイル管理方法を提供することを目的としている。
たとえば、Ｆｒａｎｋ Ｓｃｈｍｕｃｋ，Ｒｏｇｅｒ Ｈａｓｋｉｎ，″ＧＰＦＳ：Ａ Ｓｈａｒｅｄ−Ｄｉｓｋ Ｆｉｌｅ Ｓｙｓｔｅｍ ｆｏｒ Ｌａｒｇｅ Ｃｏｍｐｕｔｉｎｇ Ｃｌｕｓｔｅｒｓ，″Ｐｒｏｃ．ｏｆ ｔｈｅ ＦＡＳＴ ２００２ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｌｅ ａｎｄ Ｓｔｏｒａｇｅ Ｔｅｃｈｎｏｌｏｇｉｅｓ，ＵＳＥＮＩＸ Ａｓｓｏｃｉａｔｉｏｎ，Ｊａｎｕａｒｙ，２００２．には、ファイルサーバ毎に存在すると想定できるファイルアクセスのローカリティに着目し、ファイル単位にメタデータを管理するファイルサーバ（メタデータサーバ）を動的に変更する方式が開示されている。この方式は、ファイルアクセスが要求されたファイルサーバをそのファイルのメタデータサーバとするもので、ファイルサーバ毎にアクセスするファイルのローカリティが存在する場合に、一つのファイルサーバで処理を完結させ、余分なファイルサーバ間通信を発生させない有効な方式であるといえる。
しかし、この方式では、メタデータサーバのありかが事前に予測不可能なため、どの程度ファイルサーバ間通信が発生することになるかの予測が困難であり、特に属性つきディレクトリ読み出し操作などのファイル操作では、メタデータアクセスのために膨大なファイルサーバ間通信が発生する可能性があるという欠陥がある。またメタデータサーバ決定のため複雑なプロトコルを必要とするという欠陥も存在する。
このようなメタデータサーバを動的に変更する方式の欠陥を解消する方式として、静的にメタデータサーバを決定する方式が考えられる。たとえば、クラスタファイルシステムの名前空間を複数の区画に分割し、各区画の管理をメタデータサーバに分担させ、各メタデータサーバに、分担する区画に属するファイルのメタデータを管理させる方式が考えられる。しかし、単に各区画にその区画を管理するメタデータサーバを静的に割り付けるだけでは、特定の区画のメタデータが増加した場合に、その区画を管理するメタデータサーバの負荷が増大してしまう。
そこで、メタデーダサーバが管理する区画を動的に分割したり、各メタデータサーバが管理する区画を変更したりすることが必要となるが、区画を管理するメタデータサーバが変更になると、メタデータサーバ間のメタデータの移動が必要であり、オーバヘッドが大きくなるという問題がある。また、ファイルシステム内部でファイルを識別するための情報としてメタデータの位置情報を利用している場合には、区画の変更に伴ってメタデータが他のメタデータサーバに移動すると、ファイルの内部識別情報が変わってしまうという問題がある。
従って、この発明は、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるファイルシステム、ファイル管理装置、ファイル管理プログラムおよびファイル管理方法を提供することを目的としている。
上述した課題を解決し、目的を達成するため、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理装置であって、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込む分担ファイル処理手段と、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理手段により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定手段と、を備えたことを特徴とする。
この発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理プログラムであって、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理手順と、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理手順により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定手順と、をファイルサーバで実行することを特徴とする。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理方法であって、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理工程と、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理工程により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定工程と、を含んだことを特徴とする。
かかる発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムであって、前記複数のファイルサーバで共用され、前記ファイルのメタ情報を記憶するメタデータ記憶装置を備え、前記複数のファイルサーバのそれぞれは、前記ファイルに対する操作要求を受け付け、該受け付けた操作要求を処理するファイルサーバの決定を前記メタデータ記憶装置に記憶されたメタ情報に基づいておこなうことを特徴とする。
この発明によれば、複数のファイルサーバで共用され、ファイルのメタ情報を記憶するメタデータ記憶装置を備え、複数のファイルサーバのそれぞれは、ファイルに対する操作要求を受け付け、受け付けた操作要求を処理するファイルサーバの決定をメタデータ記憶装置に記憶されたメタ情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
この発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理プログラムであって、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理手順と、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理手順により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定手順と、をファイルサーバで実行することを特徴とする。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理方法であって、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理工程と、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理工程により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定工程と、を含んだことを特徴とする。
かかる発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
また、本発明は、複数のファイルサーバが同じファイルを共用することができるファイルシステムであって、前記複数のファイルサーバで共用され、前記ファイルのメタ情報を記憶するメタデータ記憶装置を備え、前記複数のファイルサーバのそれぞれは、前記ファイルに対する操作要求を受け付け、該受け付けた操作要求を処理するファイルサーバの決定を前記メタデータ記憶装置に記憶されたメタ情報に基づいておこなうことを特徴とする。
この発明によれば、複数のファイルサーバで共用され、ファイルのメタ情報を記憶するメタデータ記憶装置を備え、複数のファイルサーバのそれぞれは、ファイルに対する操作要求を受け付け、受け付けた操作要求を処理するファイルサーバの決定をメタデータ記憶装置に記憶されたメタ情報に基づいておこなうこととしたので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができる。
第１図は、本実施の形態に係るクラスタファイルシステムによるメタデータ管理の概念を説明するための説明図であり、第２図は、本実施の形態に係るクラスタファイルシステムのシステム構成を示す機能ブロック図であり、第３図は、ファイルハンドルのデータ構造の一例を示す図であり、第４図は、区画分割によるメタデータ管理を説明するための説明であり、第５図は、担当表の一例を示す図であり、第６図は、第２図に示した要求受付部の処理手順を示すフローチャートであり、第７図は、第２図に示したファイル操作部の処理手順を示すフローチャートであり、第８図は、第２図に示したｉｎｏｄｅ割当部の処理手順を示すフローチャートであり、第９図は、第２図に示したｉｎｏｄｅ開放部の処理手順を示すフローチャートであり、第１０図は、第２図に示した区画分割部の処理手順を示すフローチャートであり、第１１図は、第１０図に示した再帰的区画分割処理の処理手順を示すフローチャートである。
以下、添付図面を参照して、この発明に係るファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステムの好適な実施の形態を詳細に説明する。
まず、本実施の形態に係るクラスタファイルシステムによるメタデータ管理の概念について説明する。第１図は、本実施の形態に係るクラスタファイルシステムによるメタデータ管理の概念を説明するための説明図である。同図（ａ）は、従来のメタデータ管理を示し、同図（ｂ）は、本実施の形態に係るメタデータ管理を示している。なお、ここでは説明の便宜上、３台のファイルサーバのみを示したが、ファイルサーバの台数は任意の数とすることができる。
同図（ａ）に示すように、従来のメタデータ管理では、各ファイルサーバが管理を分担するファイルおよびディレクトリのメタデータを独自に管理していた。このため、メタデータの管理分担を変更する場合には、メタデータを他のファイルサーバに移動するオーバヘッドが発生していた。また、一つのディレクトリに属する複数のファイルに関する情報が様々なファイルサーバに分散しているため、多くのファイルを有するディレクトリのファイル属性表示などの場合、多くのファイルサーバ間で膨大なメタデータの転送が必要であった。
一方、本実施の形態に係るメタデータ管理では、全てのファイルサーバがアクセスできる共用ディスクを用いて、各ファイルサーバがメタデータを分担して管理する。したがって、メタデータの管理分担を変更する場合にも、メタデータを変更元のメタデータサーバから変更先のメタデータサーバに移動する必要はなく、メタデータ中の管理分担を示す情報を書き換えるだけで済み、オーバヘッドを少なくすることができる。
ただし、メタデータに対して複数のファイルサーバが矛盾した更新をおこなうことを防ぐために、メタデータを複数の区画に分割し、各区画を管理するファイルサーバを定め、各区画を管理するファイルサーバだけがその区画に属するファイルおよびディレクトリについてのメタデータを更新することができることとする。たとえば、区画番号が０のメタデータはファイルサーバＡのみが更新可能であり、区画番号が１のメタデータはファイルサーバＢのみが更新可能であり、区画番号が１０のメタデータはファイルサーバＣのみが更新可能である。
また、本実施の形態に係るメタデータ管理では、同じディレクトリに属するファイルおよびディレクトリのメタデータは、まとめて同一の区画に作成する。したがって、あるディレクトリに属する全てのファイルの属性表示など多くのメタデータを必要とするファイル操作の場合にも、ファイルのメタデータがまとまって１台のファイルサーバに存在するため、データの一括転送が可能であり、他のファイルサーバからメテデータを収集するオーバヘッドを少なくすることができる。
このように、本実施の形態では、全てのファイルサーバがアクセスできる共用ディスクを用いてメタデータを管理することとしたので、メタデータの管理分担変更にともなうオーバヘッドを少なくすることができ、クラスタファイルシステムの処理能力をスケーラブルに拡張することができる。また、本実施の形態では、同じディレクトリに属するファイルおよびディレクトリのメタデータは、まとめて同一の区画に作成することとしたので、多くのメタデータを必要とするファイル操作の場合にも、ファイルサーバ間でのメタデータの転送を減らすことができ、安定した性能を保証しつつクラスタファイルシステムの処理能力をスケーラブルに拡張することができる。
次に、本実施の形態に係るクラスタファイルシステムのシステム構成について説明する。第２図は、本実施の形態に係るクラスタファイルシステム１００のシステム構成を示す機能ブロック図である。同図に示すように、このクラスタファイルシステム１００は、クライアント１０１〜１０Ｍと、ファイルサーバ３０１〜３０Ｎと、メタディスク４０と、データディスク５０とから構成される。また、クライアント１０１〜１０Ｍとファイルサーバ３０１〜３０Ｎはネットワーク２０を介して接続され、ファイルサーバ３０１〜３０Ｎはメタディスク４０およびデータディスク５０を共用している。
クライアント１０１〜１０Ｍは、ネットワーク２０を介してファイルサーバ３０１〜３０Ｎにファイル処理を依頼する装置である。これらのクライアント１０１〜１０Ｍは、ファイルサーバ３０１〜３０Ｎにファイル処理を依頼する場合に、処理の対象となるファイルまたはディレクトリを、ファイルハンドルを用いて指定する。ここで、ファイルハンドルとは、クラスタファイルシステム１００がディスクに格納されたファイルおよびディレクトリを特定するためのもので、クライアント１０１〜１０Ｍは、ＬＯＯＫＵＰなどのファイル検索要求の結果、このファイルハンドルをファイルサーバ３０１〜３０Ｎから受け取る。また、クライアント１０１〜１０Ｍは、常にこのファイルハンドルを用いてファイルサーバ３０１〜３０Ｎにファイル処理を依頼する。したがって、ファイルサーバ３０１〜３０Ｎは、同一のファイルおよびディレクトリに対しては常に同じファイルハンドルをクライアント１０１〜１０Ｍに応答する必要がある。
第３図は、ファイルハンドルのデータ構造の一例を示す図である。同図に示すように、ファイルハンドル３１０は、ｉｎｏｄｅ番号３１１と、生成時区画番号３１２から構成される。ここで、ｉｎｏｄｅ番号３１１は、ファイルまたはディレクトリについての情報を記憶したｉｎｏｄｅを特定するための番号であり、生成時区画番号３１２は、ファイルまたはディレクトリが生成された時に割り当てられたメタディスク４０の区画の番号である。これらのｉｎｏｄｅ番号および生成時区画番号３１２は、ファイルまたはディレクトリが削除されるまで変わることがなく、内部識別情報としてのファイルハンドル３１０を不変なものとしている。なお、メタディスク４０の区画の詳細については後述する。
また、第３図に示すように、ｉｎｏｄｅ３２０には、現区画番号３２１と、生成時区画番号３２２と、位置情報３２３と、属性３２４と、サイズ３２５が含まれ、このｉｎｏｄｅ３２０は、ファイル制御ブロックとして機能する。現区画番号３２１は、ファイルまたはディレクトリに現在割り当てられているメタディスク４０の区画の番号であり、生成時区画番号３２２は、ファイルまたはディレクトリが生成された時に割り当てられたメタディスク４０の区画の番号である。位置情報３２３は、ファイルまたはディレクトリのデータが格納されたデータディスク５０またはメタディスク４０の位置を示し、属性３２４は、ファイルまたはディレクトリのアクセス属性を示し、サイズ３２５はファイルまたはディレクトリの大きさを示している。
ここで、メタディスク４０の区画について説明する。このクラスタファイルシステム１００では、メタデータを記憶するメタディスク４０をファイルおよびディレクトリの名前に基づいて複数の区画に分割して管理しており、それぞれの区画を、ファイルサーバ３０１〜３０Ｎのいずれかのファイルサーバが管理する。第４図は、区画分割によるメタデータ管理を説明するための説明図である。同図は、ファイルおよびディレクトリの名前空間を１１個の区画に分割した例を示しており、ディレクトリＤは区画番号が０である区画に属し、ディレクトリＸは区画番号が１０である区画に属することを示している。ここで、ディレクトリＤに属するディレクトリＭおよびファイルｙ、ならびにディレクトリＭに属するファイルｗおよびｚは、親のディレクトリと同じ区画、すなわち区画番号が０である区画に属する。また、ディレクトリＸに属するディレクトリＭおよびファイルｘ、ならびにディレクトリＭに属するファイルｖおよびｗは、親のディレクトリと同じ区画、すなわち区画番号が１０である区画に属する。ただし、後述する区画分割によって区画が分割され、分割された区画に属するディレクトリ以下のファイルおよびディレクトリが別の区画に属するように変更された場合には、親のディレクトリと、子のファイルおよびディレクトリの区画番号が異なる場合も発生する。その場合でも、同一のディレクトリに属するファイルおよびディレクトリのメタデータが多くの区画にばらばらに分散されることはない。
第２図に示したファイルサーバ３０１〜３０Ｎは、クライアント１０１〜１０Ｍからの依頼を受けてクラスタファイルシステム１００のファイル処理をおこなう計算機であり、メタディスク４０に記憶されたメタデータを用いてファイルおよびディレクトリの管理をおこなう。
メタディスク４０は、クラスタファイルシステム１００のファイルおよびディレクトリを管理するためのデータであるメタデータを記憶した記憶装置であり、空きｉｎｏｄｅブロックマップ４１と、空きメタブロックマップ４２と、使用中メタブロック群４３と、使用中ｉｎｏｄｅブロック群４４と、未使用メタブロック群４５と、未使用ｉｎｏｄｅブロック群４６と、区画別リザーブマップ群４７とを有する。
空きｉｎｏｄｅブロックマップ４１は、ｉｎｏｄｅ３２０を記憶するｉｎｏｄｅブロックのうち使用されていないｉｎｏｄｅブロックを示す記憶部であり、空きメタブロックマップ４２は、メタデータを記憶するメタブロックのうち使用されていないメタブロックを示す記憶部である。
使用中メタブロック群４３は、メタデータを記憶するために使用されているメタブロックの集まりであり、使用中ｉｎｏｄｅブロック群４４は、ｉｎｏｄｅ３２０を記憶するために使用されているｉｎｏｄｅブロックの集まりである。また、未使用メタブロック群４５は、メタデータを記憶するメタブロックのうち使用されていないメタブロックの集まりであり、未使用ｉｎｏｄｅブロック群４６は、ｉｎｏｄｅ３２０を記憶するブロックのうち使用されていないｉｎｏｄｅブロックの集まりである。
区画別リザーブマップ群４７は、区画ごとに予約したｉｎｏｄｅブロックを示すリザーブｉｎｏｄｅブロックマップ４７ａと区画ごとに予約したメタブロックを示すリザーブメタブロックマップ４７ｂを有する区画別リザーブマップの集まりである。クラスタファイルシステム１００では、各区画はファイルサーバ３０１〜３０Ｎのうちのいずれかのファイルサーバによって管理されており、各ファイルサーバは、ｉｎｏｄｅブロックおよびメタブロックが必要になった場合に、各区画のリザーブｉｎｏｄｅブロックマップ４７ａおよびリザーブメタブロックマップ４７ｂを用いて新たなブロックを確保する。同様に、各ファイルサーバは、ｉｎｏｄｅブロックおよびメタブロックが不要になった場合に、各区画のリザーブｉｎｏｄｅブロックマップ４７ａおよびリザーブメタブロックマップ４７ｂを更新することによってブロックを開放する。
ただし、区画番号が０である区画は、空きｉｎｏｄｅブロックマップ４１および空きメタブロックマップ４２を用いて全体の空きｉｎｏｄｅブロックおよび空きメタブロックを管理するための区画であり、区画番号が０である区画については、区画別リザーブマップはない。また、区画番号が０以外の区画を管理するファイルサーバは、予約した空きｉｎｏｄｅブロックまたは空きメタブロックが所定の数以下になった場合に、区画番号が０である区画を管理するファイルサーバに対して、空きｉｎｏｄｅブロックおよび空きメタブロックの予約を要求する。同様に、区画番号が０以外の区画を管理するファイルサーバは、開放された空きｉｎｏｄｅブロックまたは空きメタブロックが所定の数以上になった場合に、区画番号が０である区画を管理するファイルサーバに対して、空きｉｎｏｄｅブロックおよび空きメタブロックを返却する。
データディスク５０は、クラスタファイルシステム１００のファイルに格納されるデータを記憶する記憶装置である。なお、このクラスタファイルシステム１００では、メタディスク４０とデータディスク５０を別のディスクとしているが、メタディスク４０とデータディスク５０を同一のディスクとすることもできる。また、それぞれのディスクを複数のディスクとすることもできる。
次に、ファイルサーバ３０１〜３０Ｎの構成について説明する。なお、これらのファイルサーバ３０１〜３０Ｎはいずれも同様の構成を有するので、ここではファイルサーバ３０１を例にとって説明する。
このファイルサーバ３０１は、アプリケーション３１とクラスタファイル管理部２００とを有する。アプリケーション３１は、ファイルサーバ３０１上で動作するプログラムであり、クラスタファイル管理部２００にファイル処理を依頼する。
クラスタファイル管理部２００は、クライアント１０１〜１０Ｍおよびアプリケーション３１からの依頼を受けてクラスタファイルシステム１００のファイル処理をおこなう処理部であり、記憶部２１０と制御部２２０とを有する。
記憶部２１０は、制御部２２０が使用するデータを記憶した記憶部であり、担当表２１１と、ｉｎｏｄｅキャッシュ２１２と、メタキャッシュ２１３とを有する。
担当表２１１は、ファイルサーバ名とファイルサーバが管理する区画の番号をファイルサーバごとに対応させて記憶した表である。第５図は、担当表２１１の一例を示す図である。同図は、ファイルサーバ名がファイルサーバＡであるファイルサーバは区画番号０の区画を管理し、ファイルサーバ名がファイルサーバＢであるファイルサーバは区画番号１および１０の区画を管理していることを示している。このように、一つのファイルサーバは、複数の区画を管理しており、また、後述する区画分割や担当区画変更によって、各ファイルサーバが管理する区画が変更される場合もある。
また、ｉｎｏｄｅキャッシュ２１２は、メタディスク４０に記憶されたｉｎｏｄｅ３２０を高速にアクセスするために利用される記憶部であり、メタキャッシュ２１３は、メタディスク４０に記憶されたメタデータを高速にアクセスするために利用される記憶部である。すなわち、メタディスク４０に記憶されたｉｎｏｄｅ３２０およびメタデータをアクセスする場合には、これらのキャッシュがまず検索され、キャッシュ上にｉｎｏｄｅ３２０およびメタデータ見つからない場合に、メタディスク４０がアクセスされる。また、これらｉｎｏｄｅキャッシュ２１２およびメタキャッシュ２１３上で更新されたデータは、ｉｎｏｄｅ３２０およびメタデータが属する区画を管理するファイルサーバによってのみメタディスク４０に反映される。
このように、ｉｎｏｄｅキャッシュ２１２およびメタキャッシュ２１３上で更新されたデータを、ｉｎｏｄｅ３２０およびメタデータが属する区画を管理するファイルサーバだけがメタディスク４０に反映することとしたので、複数のファイルサーバに記憶されるｉｎｏｄｅ３２０およびメタデータ間での整合性をとることができる。
制御部２２０は、クライアント１０１〜１０Ｍおよびアプリケーション３１からのファイル操作要求を受け付けて要求に対応する処理をおこなう処理部であり、要求受付部２２１と、ファイル操作部２２２と、ｉｎｏｄｅ割当部２２３と、ｉｎｏｄｅ開放部２２４と、区画分割部２２５と、担当区画変更部２２６とを有する。
要求受付部２２１は、クライアント１０１〜１０Ｍおよびアプリケーション３１からのファイル操作要求を受け付け、要求を処理するファイルサーバを決定する処理部である。すなわち、この要求受付部２２１は、ファイル操作要求とともにファイルハンドル３１０を受け取り、受け取ったファイルハンドル３１０中のｉｎｏｄｅ番号で特定されるｉｎｏｄｅ３２０をメタディスク４０から読み出し、ｉｎｏｄｅ３２０の有する現区画番号に基づいて要求を処理するファイルサーバを決定する。ただし、ファイルからのデータの読み出しとファイルへのデータの書き込みについては、ｉｎｏｄｅ３２０の有する区画を管理するファイルサーバからファイルの位置情報を取得して要求受付部２２１が処理をおこなう。
ファイル操作部２２２は、自ファイルサーバが管理する区画に属するファイルまたはディレクトリに対する操作要求を処理する処理部であり、ファイルからのデータの読み出しとファイルへのデータの書き込み以外の処理をおこなう。また、このファイル操作部２２２は、ファイルおよびディレクトリを生成する場合に、生成するファイルおよびディレクトリのメタ情報を格納するｉｎｏｄｅ３２０に親ディレクトリの現区画番号３２１を書き込む。このように、このファイル操作部２２２がｉｎｏｄｅ３２０に区画番号を書き込むことにより、生成したファイルおよびディレクトリを管理するサーバを指定することができる。
ｉｎｏｄｅ割当部２２３は、ファイルまたはディレクトリを生成する場合に必要なｉｎｏｄｅブロックを取得する処理部であり、区画番号が０である区画を管理するファイルサーバは、空きｉｎｏｄｅブロックマップ４１を用いて空きｉｎｏｄｅブロックを取得し、区画番号が０以外である区画を管理するファイルサーバは、リザーブｉｎｏｄｅブロックマップ４７ａを用いて空きｉｎｏｄｅブロックを取得する。
ｉｎｏｄｅ開放部２２４は、ファイルまたはディレクトリを削除する場合に不要となったｉｎｏｄｅブロックを開放する処理部であり、区画番号が０である区画を管理するファイルサーバは、空きｉｎｏｄｅブロックマップ４１を更新し、区画番号が０以外である区画を管理するファイルサーバは、リザーブｉｎｏｄｅブロックマップ４７ａを更新することによってｉｎｏｄｅブロックを開放する。
区画分割部２２５は、オペレータより区画分割の要求を受け、区画分割をおこなう処理部である。具体的には、オペレータから分割の基点となるディレクトリの名前と新区画番号を受け取り、再帰的処理によって、基点となるディレクトリ以下の全てのファイルおよびディレクトリの現区画番号３２１を更新する。この区画分割部２２５が、現区画番号３２１を更新することによって区画分割をおこなうこととしたので、効率良く区画の分割をおこなうことができる。
担当区画変更部２２６は、オペレータより担当区画変更要求を受け、担当区画の変更を動的におこなう処理部である。具体的には、担当表２１１を更新することによって、各ファイルサーバが担当する区画を動的に変更する。
次に、第２図に示した要求受付部２２１の処理手順について説明する。第６図は、第２図に示した要求受付部２２１の処理手順を示すフローチャートである。同図に示すように、この要求受付部２２１は、操作要求を受け付けたファイルまたはディレクトリに対するファイルハンドル３１０を受け取り、受け取ったファイルハンドル３１０のｉｎｏｄｅ番号を用いてｉｎｏｄｅキャッシュ２１２またはメタディスク４０からｉｎｏｄｅ３２０を読み込む（ステップＳ６０１）。
そして、ｉｎｏｄｅ３２０の現区画番号３２１および担当表２１１を用いてｉｎｏｄｅ３２０の現区画が自ファイルサーバの担当する区画であるか否かを調べ（ステップＳ６０２）、自ファイルサーバが担当する区画でない場合には、現区画番号３２１が設定済みであるか否かを調べる（ステップＳ６０３）。ここで、現区画番号３２１が設定済みであれば、他のファイルサーバが現区画を担当している場合であるので、受け取った操作要求がファイルの読み出しまたは書き込みであるか否かを調べ（ステップＳ６０４）、ファイルの読み出しまたは書き込みである場合には、現区画を担当するファイルサーバにファイルの格納位置を問い合わせる（ステップＳ６０５）。そして、問い合わせた位置に基づいてデータディスク５０をアクセスし（ステップＳ６０６）、結果を操作要求元に応答する（ステップＳ６０７）。
一方、受け取った操作要求がファイルの読み出しでも書き込みでもない場合には、現区画を担当するファイルサーバへ操作要求をルーティングする（ステップＳ６０８）。そして、ルーティング先のファイルサーバから操作結果を受信すると（ステップＳ６０９）、その結果を操作要求元に応答する（ステップＳ６０７）。
また、現区画番号３２１が設定済みでなければ、ファイルまたはディレクトリが作成されたことが自ファイルサーバのｉｎｏｄｅキャッシュ２１１に伝播されていない場合であるので、ファイルハンドル３１０の生成時区画番号３１２および担当表２１１を用いて生成時区画が担当区画であるか否かを調べ（ステップＳ６１０）、担当区画でない場合には、受け取った操作要求がファイルの読み出しまたは書き込みであるか否かを調べる（ステップＳ６１１）。そして、受け取った操作要求がファイルの読み出しでも書き込みでもない場合には、生成時区画を担当するファイルサーバへ操作要求をルーティングする（ステップＳ６１２）。そして、ルーティング先のファイルサーバから操作結果を受信すると（ステップＳ６０９）、その結果を操作要求元に応答する（ステップＳ６０７）。
一方、受け取った操作要求がファイルの読み出しまたは書き込みである場合には、生成時区画を担当するファイルサーバにファイルの格納位置を問い合わせ（ステップＳ６１３）、問い合わせた位置に基づいてデータディスク５０をアクセスし（ステップＳ６１４）、結果を操作要求元に応答する（ステップＳ６０７）。
また、ファイルハンドル３１０の生成時区画が担当区画でない場合には、エラー処理をおこない（ステップＳ６１５）、その結果を操作要求元に応答する（ステップＳ６０７）。
また、ｉｎｏｄｅ３２０の現区画が自ファイルサーバの担当する区画である場合には、自ファイルサーバで操作要求に対するファイル処理をおこない（ステップＳ６１６）、結果を操作要求元に応答する（ステップＳ６０７）。
このように、この要求受付部２２１は、操作要求とともに受け取ったファイルハンドル３１０および担当表２１１を用いて操作要求対象のファイルまたはディレクトリの属する区画番号を認識することができ、ファイル処理をおこなうファイルサーバを決定することができる。
次に、第２図に示したファイル操作部２２２の処理手順について説明する。なお、このファイル操作部２２２の処理は、第６図に示したファイル処理（ステップＳ６１６）の処理に対応する。また、このファイル操作部２２２は、自サーバからの処理要求に対する処理だけでなく、他のファイルサーバがルーティングした処理要求に対する処理もおこなう。第７図は、第２図に示したファイル操作部２２２の処理手順を示すフローチャートである。
同図に示すように、このファイル操作部２２２は、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理であるか否かを調べる（ステップＳ７０１）。そして、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理である場合には、ｉｎｏｄｅブロック割り当て処理によって空きｉｎｏｄｅブロックを取得し（ステップＳ７０２）、取得したｉｎｏｄｅ３２０の現区画番号３２１と生成時区画番号３２２としてファイルハンドル３１０で指定された親ディレクトリの区画番号を設定し（ステップＳ７０３）、生成したファイルまたはディレクトリを親ディレクトリに登録する（ステップＳ７０４）。このように、生成したファイルまたはディスレクトリは、親のディレクトリと同じ区画に分類される。
一方、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理でない場合には、受け取ったファイル操作要求がファイルまたはディレクトリの削除要求であるか否かを調べ（ステップＳ７０５）、ファイルまたはディレクトリの削除要求である場合には、ファイルハンドル３１０で指定された親のディレクトリ情報を読み込み（ステップＳ７０６）、削除要求のあったファイルまたはディレクトリを削除して親のディレクトリ情報を更新し（ステップＳ７０７）、削除したファイルまたはディレクトリに使用されていたｉｎｏｄｅ３２０に対してｉｎｏｄｅブロック無効化処理をおこなう（ステップＳ７０８）。
一方、受け取ったファイル操作要求がファイルまたはディレクトリの削除要求でない場合には、ファイルハンドル３１０で指定されたファイルまたはディレクトリについての情報を読み込んでファイル操作要求元へ送信する（ステップＳ７０９）。
そして、最後に、操作要求を受け付けたファイルサーバが自ファイルサーバであるか否かを調べ（ステップＳ７１０）、要求を受け付けたファイルサーバが自ファイルサーバでない場合には、要求元ファイルサーバに応答する（ステップＳ７１１）。
このように、このファイル操作部２２２が、生成したファイルまたはディレクトリのｉｎｏｄｅ中の現区画番号３２１に親ディレクトリの区画番号を書き込むことによって、生成したファイルまたはディレクトリに対する操作要求を処理するファイルサーバを指定することができる。
次に、第２図に示したｉｎｏｄｅ割当部２２３の処理手順について説明する。なお、このｉｎｏｄｅ割当部２２３の処理は、第７図に示したｉｎｏｄｅブロック割り当て処理（ステップＳ７０２）に対応する。第８図は、第２図に示したｉｎｏｄｅ割当部２２３の処理手順を示すフローチャートである。
同図に示すように、このｉｎｏｄｅ割当部２２３は、割り当てるｉｎｏｄｅブロックの区画番号が０であるか否かを調べる（ステップＳ８０１）。そして、区画番号が０である場合には、空きｉｎｏｄｅブロックマップ４１を用いて未使用ｉｎｏｄｅ番号を取得し（ステップＳ８０２）、ｉｎｏｄｅブロックを割り当て（ステップＳ８０３）、空きｉｎｏｄｅブロックマップ４１を更新する（ステップＳ８０４）。
一方、割り当てるｉｎｏｄｅブロックの区画番号が０でない場合には、区画番号に対応するリザーブｉｎｏｄｅブロックマップ４７ａを用いて空きｉｎｏｄｅ番号を取得し（ステップＳ８０５）、ｉｎｏｄｅブロックを割り当て（ステップＳ８０６）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ８０７）。そして、空きｉｎｏｄｅブロック数が所定値以下になったか否かを調べ（ステップＳ８０８）、所定値以下でない場合には、処理を終了する。これに対して、空きｉｎｏｄｅブロック数が所定値以下になった場合には、ｉｎｏｄｅリザーブ要求をおこない（ステップＳ８０９）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ８１０）。
次に、第２図に示したｉｎｏｄｅ開放部２２４の処理手順について説明する。なお、このｉｎｏｄｅ開放部２２４の処理は、第７図に示したｉｎｏｄｅブロック無効化処理（ステップＳ７０８）に対応する。第９図は、第２図に示したｉｎｏｄｅ開放部２２４の処理手順を示すフローチャートである。
同図に示すように、このｉｎｏｄｅ開放部２２４は、開放するｉｎｏｄｅブロックが属する区画の番号が０であるか否かを調べ（ステップＳ９０１）、０である場合には、空きｉｎｏｄｅブロックマップ４１を更新する（ステップＳ９０２）。一方、区画の番号が０でない場合には、区画の番号に対応するリザーブｉｎｏｄｅブロックマップ４７ａを更新し（ステップＳ９０３）、空きｉｎｏｄｅブロック数が所定値以上であるか否かを調べ（ステップＳ９０４）、所定値以上でない場合には、処理を終了する。
これに対して、空きｉｎｏｄｅブロック数が所定値以上である場合には、リザーブしている空きｉｎｏｄｅブロックの開放を区画０を管理しているファイルサーバに通知し（ステップＳ９０５）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ９０６）。この場合、区画０を管理しているファイルサーバは、空きｉｎｏｄｅブロックマップ４１を更新し、ｉｎｏｄｅ３２０の同期的な書き込みをおこない、該当ｉｎｏｄｅキャッシュの無効化を全ファイルサーバに依頼する。
次に、第２図に示した区画分割部２２５の処理手順について説明する。第１０図は、第２図に示した区画分割部２２５の処理手順を示すフローチャートである。同図に示すように、この区画分割部２２５は、オペレータから基点ディレクトリの名前と新区画番号を受け付け（ステップＳ１００１）、メタディスク４０から基点ディレクトリのｉｎｏｄｅ３２０を読み出す（ステップＳ１００２）。そして、読み出したｉｎｏｄｅ３２０から現区画番号３２１を取り出し（ステップＳ１００３）、再帰的区画分割処理をおこなう（ステップＳ１００４）。
ここで、この再帰的区画分割処理（ステップＳ１００４）の処理手順について説明する。第１１図は、第１０図に示した再帰的区画分割処理の処理手順を示すフローチャートである。同図に示すように、この再帰的区画分割処理は、親ディレクトリの分割処理をおこなっている親ファイルサーバが、子供のファイルまたはディレクトリが属する区画を担当する子ファイルサーバにｉｎｏｄｅ３２０および新区画番号を送信する（ステップＳ１１０１）。なお、親ファイルサーバと子ファイルサーバは、子供のファイルまたはディレクトリが生成された時点では、同一のファイルサーバとなるが、区画分割や担当区画の変更によって別のファイルサーバとなる場合もある
一方、子ファイルサーバは、ｉｎｏｄｅ３２０および新区画番号を受信し（ステップＳ１１０２）、ｉｎｏｄｅキャッシュ２１１内のｉｎｏｄｅ３２０の現区画番号３２１を新区画番号に更新する（ステップＳ１１０３）。また、更新結果をメタディスク４０に反映し（ステップＳ１１０４）、更新したｉｎｏｄｅ３２０の無効化要求を他のファイルサーバに送信し（ステップＳ１１０５）、他のファイルサーバのｉｎｏｄｅキャッシュのｉｎｏｄｅ３２０を無効化する。
そして、更新したｉｎｏｄｅ３２０がディレクトリである場合には、そのディレクトリが子供を有するか否かを調べ（ステップＳ１１０６）、子供を有する場合には、子供のｉｎｏｄｅ３２０をメタディスク４０から読み出し（ステップＳ１１０７）、読み出したｉｎｏｄｅ３２０から子供の現区画番号３２１を取り出し（ステップＳ１１０８）、子供に対して再帰的分割処理をおこなう（ステップＳ１１０９）。その後、子供の更新完了を受信すると（ステップＳ１１１０）、ステップＳ１１０６に戻って次の子供の処理をおこなう。一方、子供がない場合または子供の処理が全て終了した場合には、更新完了を親ファイルサーバに送信し（ステップＳ１１１１）、処理を終了する。
このように、この区画分割部２２５が、オペレータから基点ディレクトリと新区画番号を受け付け、再帰的区画分割処理を用いて基点ディレクトリに属する全てのファイルおよびディレクトリの現区画番号３２１を変更し、変更したｉｎｏｄｅ３２０の無効化要求を他のファイルサーバに送信することとしたので、複数のファイルサーバのｉｎｏｄｅキャッシュに記憶されているｉｎｏｄｅ３２０の整合性を保つとともに、効率良く区画分割をおこなうことができる。
なお、ｉｎｏｄｅブロックの更新は、ｉｎｏｄｅ３２０が属する区画を管理するファイルサーバでのみおこない、複数のファイルサーバが同時に更新することはない。これによりメタディスク４０上のｉｎｏｄｅ３２０が誤って破壊されることを防止している。
また、ｉｎｏｄｅ３２０中に設定される現区画番号３２１が変更されるのは、ファイルまたはディレクトリを生成あるいは削除したときと区画を分割した場合のみである。このうち、ファイルまたはディレクトリの生成および削除は、一般の運用中に発生する操作であり、ｉｎｏｄｅ３２０の更新を他ファイルサーバと同期して行う（キャッシュのパージとメタディスク４０への反映）と性能面のペナルティが大きい。そこで、このクラスタファイルシステム１００ではｉｎｏｄｅ３２０の更新結果を他ファイルサーバに直ちに伝播させることはおこなわない。何故ならば、ファイル操作要求で指定されたファイルハンドル３１０中に設定されているｉｎｏｄｅ番号から一意にディスク上のｉｎｏｄｅ３２０が求まり、矛盾が発生しないためである。
すなわち、ディスク上のｉｎｏｄｅ３２０に設定されている現区画番号３２１が一時的に不当な値となる場合がいくつかあるが、そのうち、過去に現区画番号３２１が存在し、他のファイルサーバで削除されたファイルの削除結果がまだ伝播していない場合には、ディスク上のｉｎｏｄｅ３２０に入っている現区画番号３２１で決まるファイルサーバに要求がルーティングされ、ルーティング先のファイルサーバではこのファイルが一旦削除されたことを必ず認識できるので、ファイルが既に存在しないことを応答できる。
また、他のファイルサーバで新たに作成されたファイルの作成結果がまだ伝播していない場合で、かつ、過去に存在した現区画番号３２１が他のファイルサーバで削除され、同じファイルサーバで新たに別のファイルに割り当てられた場合には、ディスク上のｉｎｏｄｅ３２０に設定されている現区画番号３２１のファイルサーバに要求をルーティングすれば、そのファイルサーバでファイル作成結果が必ずキャッシュを介して認識されるはずであるから、現区画番号は正しく認識される。
また、他のファイルサーバで新たに作成されたファイルの作成結果がまだ伝播していない場合で、かつ、過去に存在した現区画番号３２１が他のファイルサーバ（ファイルサーバＡ）で削除され、その後別のファイルサーバ（ファイルサーバＢ）で新たに別のファイルに割り当てられた場合には、ファイルサーバＡでリザーブしていたｉｎｏｄｅ３２０が別のファイルサーバＢで使用されていることから、そのｉｎｏｄｅ３２０は必ず区画番号が０である区画を管理するファイルサーバに返却されているはずである。したがって、ディスク上のｉｎｏｄｅ３２０の上塗りを防ぐため、ディスクｉｎｏｄｅ３２０の同期的書き出しとｉｎｏｄｅキャッシュの無効化が行われているはずであり、ファイルサーバＡが行った削除の結果がディスク上のｉｎｏｄｅ３２０に反映されているはずであって、ファイルサーバＡに対応する区画がディスク上のｉｎｏｄｅ３２０に設定されていることはありえない。すなわち、ディスク上のｉｎｏｄｅ３２０の現区画番号３２１には、未割り当てを示す値が設定されているはずであり、その結果、ファイルハンドル３１０に設定されている生成時区画に対応するファイルサーバ（このケースではファイルサーバＢ）にルーティングが行われ正しく処理される。
したがって、このクラスタファイルシステム１００では、通常のファイル操作要求の処理にともなうメタデータの更新結果を各ファイルサーバが保持するログディスクに書き出すのみで、メタディスク４０の更新はキャッシュを介して、適当なタイミングで非同期に書き出すことが可能となる。
また、区画分割をおこなった場合には、ｉｎｏｄｅ３２０の現区画番号３２１の変更はその区画を管理しているファイルサーバでメタディスク４０を介して同期的に行われる。したがって、他のファイルサーバには変更の結果が即座に伝わり、ルーティング上の問題は発生しない。
上述したように、本実施の形態では、全てのファイルサーバ３０１〜３０Ｎが共用するメタディスク４０にファイルおよびディレクトリのメタデータを有するｉｎｏｄｅ３２０を記憶し、ファイルおよびディレクトリをそれらの名前に基づいて複数の区画に分類し、各区画を管理するファイルサーバを定めて各区画に属するファイル、ディレクトリおよびそれらのメタデータを分割管理する。そして、ファイル操作部２２２が、新たに生成したファイルおよびディレクトリのｉｎｏｄｅ３２０にそれらの属する区画番号を書き込み、要求受付部２２１がｉｎｏｄｅ３２０が有する区画番号に基づいて要求を処理するファイルサーバを決定することとしたので、メタデータを管理するファイルサーバを変更した場合にも、ファイルサーバ間でメタデータを移動する必要がなく、管理ファイルサーバ変更にともなうオーバヘッドを少なくすることができ、スケーラブルなクラスタファイルシステムを実現することができる。
また、本実施の形態では、ファイル操作部２２２が、同一のディレクトリに属するファイルおよびディレクトリのメタデータを同一区画に記憶することとしたので、多数のファイルに関する属性情報を収集する必要がある場合にも、属性情報をまとめてファイルサーバ間で転送することができ、ファイルサーバ間のデータ転送によるオーバヘッドを少なくすることができ、安定した性能をもつスケーラブルなクラスタファイルシステムを実現することができる。
また、本実施の形態では、ファイルおよびディレクトリに関する情報を記憶するｉｎｏｄｅ３２０の更新は、そのファイルおよびディレクトリが属する区画を管理するファイルサーバだけがおこない、ｉｎｏｄｅ３２０を更新したファイルサーバは、リザーブ中ｉｎｏｄｅ３２０を区画０を管理しているファイルサーバに返却する際に、他のファイルサーバにｉｎｏｄｅキャッシュ２１１のデータを無効とする指示を送信することとしたので、複数のファイルサーバのｉｎｏｄｅキャッシュに記憶されるｉｎｏｄｅ３２０の整合性を保証することができる。
以上説明したように、本発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
また、本発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
また、本発明によれば、複数のファイルサーバで共用され、ファイルのメタ情報を記憶するメタデータ記憶装置を備え、複数のファイルサーバのそれぞれは、ファイルに対する操作要求を受け付け、受け付けた操作要求を処理するファイルサーバの決定をメタデータ記憶装置に記憶されたメタ情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
まず、本実施の形態に係るクラスタファイルシステムによるメタデータ管理の概念について説明する。第１図は、本実施の形態に係るクラスタファイルシステムによるメタデータ管理の概念を説明するための説明図である。同図（ａ）は、従来のメタデータ管理を示し、同図（ｂ）は、本実施の形態に係るメタデータ管理を示している。なお、ここでは説明の便宜上、３台のファイルサーバのみを示したが、ファイルサーバの台数は任意の数とすることができる。
同図（ａ）に示すように、従来のメタデータ管理では、各ファイルサーバが管理を分担するファイルおよびディレクトリのメタデータを独自に管理していた。このため、メタデータの管理分担を変更する場合には、メタデータを他のファイルサーバに移動するオーバヘッドが発生していた。また、一つのディレクトリに属する複数のファイルに関する情報が様々なファイルサーバに分散しているため、多くのファイルを有するディレクトリのファイル属性表示などの場合、多くのファイルサーバ間で膨大なメタデータの転送が必要であった。
一方、本実施の形態に係るメタデータ管理では、全てのファイルサーバがアクセスできる共用ディスクを用いて、各ファイルサーバがメタデータを分担して管理する。したがって、メタデータの管理分担を変更する場合にも、メタデータを変更元のメタデータサーバから変更先のメタデータサーバに移動する必要はなく、メタデータ中の管理分担を示す情報を書き換えるだけで済み、オーバヘッドを少なくすることができる。
ただし、メタデータに対して複数のファイルサーバが矛盾した更新をおこなうことを防ぐために、メタデータを複数の区画に分割し、各区画を管理するファイルサーバを定め、各区画を管理するファイルサーバだけがその区画に属するファイルおよびディレクトリについてのメタデータを更新することができることとする。たとえば、区画番号が０のメタデータはファイルサーバＡのみが更新可能であり、区画番号が１のメタデータはファイルサーバＢのみが更新可能であり、区画番号が１０のメタデータはファイルサーバＣのみが更新可能である。
また、本実施の形態に係るメタデータ管理では、同じディレクトリに属するファイルおよびディレクトリのメタデータは、まとめて同一の区画に作成する。したがって、あるディレクトリに属する全てのファイルの属性表示など多くのメタデータを必要とするファイル操作の場合にも、ファイルのメタデータがまとまって１台のファイルサーバに存在するため、データの一括転送が可能であり、他のファイルサーバからメテデータを収集するオーバヘッドを少なくすることができる。
このように、本実施の形態では、全てのファイルサーバがアクセスできる共用ディスクを用いてメタデータを管理することとしたので、メタデータの管理分担変更にともなうオーバヘッドを少なくすることができ、クラスタファイルシステムの処理能力をスケーラブルに拡張することができる。また、本実施の形態では、同じディレクトリに属するファイルおよびディレクトリのメタデータは、まとめて同一の区画に作成することとしたので、多くのメタデータを必要とするファイル操作の場合にも、ファイルサーバ間でのメタデータの転送を減らすことができ、安定した性能を保証しつつクラスタファイルシステムの処理能力をスケーラブルに拡張することができる。
次に、本実施の形態に係るクラスタファイルシステムのシステム構成について説明する。第２図は、本実施の形態に係るクラスタファイルシステム１００のシステム構成を示す機能ブロック図である。同図に示すように、このクラスタファイルシステム１００は、クライアント１０１〜１０Ｍと、ファイルサーバ３０１〜３０Ｎと、メタディスク４０と、データディスク５０とから構成される。また、クライアント１０１〜１０Ｍとファイルサーバ３０１〜３０Ｎはネットワーク２０を介して接続され、ファイルサーバ３０１〜３０Ｎはメタディスク４０およびデータディスク５０を共用している。
クライアント１０１〜１０Ｍは、ネットワーク２０を介してファイルサーバ３０１〜３０Ｎにファイル処理を依頼する装置である。これらのクライアント１０１〜１０Ｍは、ファイルサーバ３０１〜３０Ｎにファイル処理を依頼する場合に、処理の対象となるファイルまたはディレクトリを、ファイルハンドルを用いて指定する。ここで、ファイルハンドルとは、クラスタファイルシステム１００がディスクに格納されたファイルおよびディレクトリを特定するためのもので、クライアント１０１〜１０Ｍは、ＬＯＯＫＵＰなどのファイル検索要求の結果、このファイルハンドルをファイルサーバ３０１〜３０Ｎから受け取る。また、クライアント１０１〜１０Ｍは、常にこのファイルハンドルを用いてファイルサーバ３０１〜３０Ｎにファイル処理を依頼する。したがって、ファイルサーバ３０１〜３０Ｎは、同一のファイルおよびディレクトリに対しては常に同じファイルハンドルをクライアント１０１〜１０Ｍに応答する必要がある。
第３図は、ファイルハンドルのデータ構造の一例を示す図である。同図に示すように、ファイルハンドル３１０は、ｉｎｏｄｅ番号３１１と、生成時区画番号３１２から構成される。ここで、ｉｎｏｄｅ番号３１１は、ファイルまたはディレクトリについての情報を記憶したｉｎｏｄｅを特定するための番号であり、生成時区画番号３１２は、ファイルまたはディレクトリが生成された時に割り当てられたメタディスク４０の区画の番号である。これらのｉｎｏｄｅ番号および生成時区画番号３１２は、ファイルまたはディレクトリが削除されるまで変わることがなく、内部識別情報としてのファイルハンドル３１０を不変なものとしている。なお、メタディスク４０の区画の詳細については後述する。
また、第３図に示すように、ｉｎｏｄｅ３２０には、現区画番号３２１と、生成時区画番号３２２と、位置情報３２３と、属性３２４と、サイズ３２５が含まれ、このｉｎｏｄｅ３２０は、ファイル制御ブロックとして機能する。現区画番号３２１は、ファイルまたはディレクトリに現在割り当てられているメタディスク４０の区画の番号であり、生成時区画番号３２２は、ファイルまたはディレクトリが生成された時に割り当てられたメタディスク４０の区画の番号である。位置情報３２３は、ファイルまたはディレクトリのデータが格納されたデータディスク５０またはメタディスク４０の位置を示し、属性３２４は、ファイルまたはディレクトリのアクセス属性を示し、サイズ３２５はファイルまたはディレクトリの大きさを示している。
ここで、メタディスク４０の区画について説明する。このクラスタファイルシステム１００では、メタデータを記憶するメタディスク４０をファイルおよびディレクトリの名前に基づいて複数の区画に分割して管理しており、それぞれの区画を、ファイルサーバ３０１〜３０Ｎのいずれかのファイルサーバが管理する。第４図は、区画分割によるメタデータ管理を説明するための説明図である。同図は、ファイルおよびディレクトリの名前空間を１１個の区画に分割した例を示しており、ディレクトリＤは区画番号が０である区画に属し、ディレクトリＸは区画番号が１０である区画に属することを示している。ここで、ディレクトリＤに属するディレクトリＭおよびファイルｙ、ならびにディレクトリＭに属するファイルｗおよびｚは、親のディレクトリと同じ区画、すなわち区画番号が０である区画に属する。また、ディレクトリＸに属するディレクトリＭおよびファイルｘ、ならびにディレクトリＭに属するファイルｖおよびｗは、親のディレクトリと同じ区画、すなわち区画番号が１０である区画に属する。ただし、後述する区画分割によって区画が分割され、分割された区画に属するディレクトリ以下のファイルおよびディレクトリが別の区画に属するように変更された場合には、親のディレクトリと、子のファイルおよびディレクトリの区画番号が異なる場合も発生する。その場合でも、同一のディレクトリに属するファイルおよびディレクトリのメタデータが多くの区画にばらばらに分散されることはない。
第２図に示したファイルサーバ３０１〜３０Ｎは、クライアント１０１〜１０Ｍからの依頼を受けてクラスタファイルシステム１００のファイル処理をおこなう計算機であり、メタディスク４０に記憶されたメタデータを用いてファイルおよびディレクトリの管理をおこなう。
メタディスク４０は、クラスタファイルシステム１００のファイルおよびディレクトリを管理するためのデータであるメタデータを記憶した記憶装置であり、空きｉｎｏｄｅブロックマップ４１と、空きメタブロックマップ４２と、使用中メタブロック群４３と、使用中ｉｎｏｄｅブロック群４４と、未使用メタブロック群４５と、未使用ｉｎｏｄｅブロック群４６と、区画別リザーブマップ群４７とを有する。
空きｉｎｏｄｅブロックマップ４１は、ｉｎｏｄｅ３２０を記憶するｉｎｏｄｅブロックのうち使用されていないｉｎｏｄｅブロックを示す記憶部であり、空きメタブロックマップ４２は、メタデータを記憶するメタブロックのうち使用されていないメタブロックを示す記憶部である。
使用中メタブロック群４３は、メタデータを記憶するために使用されているメタブロックの集まりであり、使用中ｉｎｏｄｅブロック群４４は、ｉｎｏｄｅ３２０を記憶するために使用されているｉｎｏｄｅブロックの集まりである。また、未使用メタブロック群４５は、メタデータを記憶するメタブロックのうち使用されていないメタブロックの集まりであり、未使用ｉｎｏｄｅブロック群４６は、ｉｎｏｄｅ３２０を記憶するブロックのうち使用されていないｉｎｏｄｅブロックの集まりである。
区画別リザーブマップ群４７は、区画ごとに予約したｉｎｏｄｅブロックを示すリザーブｉｎｏｄｅブロックマップ４７ａと区画ごとに予約したメタブロックを示すリザーブメタブロックマップ４７ｂを有する区画別リザーブマップの集まりである。クラスタファイルシステム１００では、各区画はファイルサーバ３０１〜３０Ｎのうちのいずれかのファイルサーバによって管理されており、各ファイルサーバは、ｉｎｏｄｅブロックおよびメタブロックが必要になった場合に、各区画のリザーブｉｎｏｄｅブロックマップ４７ａおよびリザーブメタブロックマップ４７ｂを用いて新たなブロックを確保する。同様に、各ファイルサーバは、ｉｎｏｄｅブロックおよびメタブロックが不要になった場合に、各区画のリザーブｉｎｏｄｅブロックマップ４７ａおよびリザーブメタブロックマップ４７ｂを更新することによってブロックを開放する。
ただし、区画番号が０である区画は、空きｉｎｏｄｅブロックマップ４１および空きメタブロックマップ４２を用いて全体の空きｉｎｏｄｅブロックおよび空きメタブロックを管理するための区画であり、区画番号が０である区画については、区画別リザーブマップはない。また、区画番号が０以外の区画を管理するファイルサーバは、予約した空きｉｎｏｄｅブロックまたは空きメタブロックが所定の数以下になった場合に、区画番号が０である区画を管理するファイルサーバに対して、空きｉｎｏｄｅブロックおよび空きメタブロックの予約を要求する。同様に、区画番号が０以外の区画を管理するファイルサーバは、開放された空きｉｎｏｄｅブロックまたは空きメタブロックが所定の数以上になった場合に、区画番号が０である区画を管理するファイルサーバに対して、空きｉｎｏｄｅブロックおよび空きメタブロックを返却する。
データディスク５０は、クラスタファイルシステム１００のファイルに格納されるデータを記憶する記憶装置である。なお、このクラスタファイルシステム１００では、メタディスク４０とデータディスク５０を別のディスクとしているが、メタディスク４０とデータディスク５０を同一のディスクとすることもできる。また、それぞれのディスクを複数のディスクとすることもできる。
次に、ファイルサーバ３０１〜３０Ｎの構成について説明する。なお、これらのファイルサーバ３０１〜３０Ｎはいずれも同様の構成を有するので、ここではファイルサーバ３０１を例にとって説明する。
このファイルサーバ３０１は、アプリケーション３１とクラスタファイル管理部２００とを有する。アプリケーション３１は、ファイルサーバ３０１上で動作するプログラムであり、クラスタファイル管理部２００にファイル処理を依頼する。
クラスタファイル管理部２００は、クライアント１０１〜１０Ｍおよびアプリケーション３１からの依頼を受けてクラスタファイルシステム１００のファイル処理をおこなう処理部であり、記憶部２１０と制御部２２０とを有する。
記憶部２１０は、制御部２２０が使用するデータを記憶した記憶部であり、担当表２１１と、ｉｎｏｄｅキャッシュ２１２と、メタキャッシュ２１３とを有する。
担当表２１１は、ファイルサーバ名とファイルサーバが管理する区画の番号をファイルサーバごとに対応させて記憶した表である。第５図は、担当表２１１の一例を示す図である。同図は、ファイルサーバ名がファイルサーバＡであるファイルサーバは区画番号０の区画を管理し、ファイルサーバ名がファイルサーバＢであるファイルサーバは区画番号１および１０の区画を管理していることを示している。このように、一つのファイルサーバは、複数の区画を管理しており、また、後述する区画分割や担当区画変更によって、各ファイルサーバが管理する区画が変更される場合もある。
また、ｉｎｏｄｅキャッシュ２１２は、メタディスク４０に記憶されたｉｎｏｄｅ３２０を高速にアクセスするために利用される記憶部であり、メタキャッシュ２１３は、メタディスク４０に記憶されたメタデータを高速にアクセスするために利用される記憶部である。すなわち、メタディスク４０に記憶されたｉｎｏｄｅ３２０およびメタデータをアクセスする場合には、これらのキャッシュがまず検索され、キャッシュ上にｉｎｏｄｅ３２０およびメタデータ見つからない場合に、メタディスク４０がアクセスされる。また、これらｉｎｏｄｅキャッシュ２１２およびメタキャッシュ２１３上で更新されたデータは、ｉｎｏｄｅ３２０およびメタデータが属する区画を管理するファイルサーバによってのみメタディスク４０に反映される。
このように、ｉｎｏｄｅキャッシュ２１２およびメタキャッシュ２１３上で更新されたデータを、ｉｎｏｄｅ３２０およびメタデータが属する区画を管理するファイルサーバだけがメタディスク４０に反映することとしたので、複数のファイルサーバに記憶されるｉｎｏｄｅ３２０およびメタデータ間での整合性をとることができる。
制御部２２０は、クライアント１０１〜１０Ｍおよびアプリケーション３１からのファイル操作要求を受け付けて要求に対応する処理をおこなう処理部であり、要求受付部２２１と、ファイル操作部２２２と、ｉｎｏｄｅ割当部２２３と、ｉｎｏｄｅ開放部２２４と、区画分割部２２５と、担当区画変更部２２６とを有する。
要求受付部２２１は、クライアント１０１〜１０Ｍおよびアプリケーション３１からのファイル操作要求を受け付け、要求を処理するファイルサーバを決定する処理部である。すなわち、この要求受付部２２１は、ファイル操作要求とともにファイルハンドル３１０を受け取り、受け取ったファイルハンドル３１０中のｉｎｏｄｅ番号で特定されるｉｎｏｄｅ３２０をメタディスク４０から読み出し、ｉｎｏｄｅ３２０の有する現区画番号に基づいて要求を処理するファイルサーバを決定する。ただし、ファイルからのデータの読み出しとファイルへのデータの書き込みについては、ｉｎｏｄｅ３２０の有する区画を管理するファイルサーバからファイルの位置情報を取得して要求受付部２２１が処理をおこなう。
ファイル操作部２２２は、自ファイルサーバが管理する区画に属するファイルまたはディレクトリに対する操作要求を処理する処理部であり、ファイルからのデータの読み出しとファイルへのデータの書き込み以外の処理をおこなう。また、このファイル操作部２２２は、ファイルおよびディレクトリを生成する場合に、生成するファイルおよびディレクトリのメタ情報を格納するｉｎｏｄｅ３２０に親ディレクトリの現区画番号３２１を書き込む。このように、このファイル操作部２２２がｉｎｏｄｅ３２０に区画番号を書き込むことにより、生成したファイルおよびディレクトリを管理するサーバを指定することができる。
ｉｎｏｄｅ割当部２２３は、ファイルまたはディレクトリを生成する場合に必要なｉｎｏｄｅブロックを取得する処理部であり、区画番号が０である区画を管理するファイルサーバは、空きｉｎｏｄｅブロックマップ４１を用いて空きｉｎｏｄｅブロックを取得し、区画番号が０以外である区画を管理するファイルサーバは、リザーブｉｎｏｄｅブロックマップ４７ａを用いて空きｉｎｏｄｅブロックを取得する。
ｉｎｏｄｅ開放部２２４は、ファイルまたはディレクトリを削除する場合に不要となったｉｎｏｄｅブロックを開放する処理部であり、区画番号が０である区画を管理するファイルサーバは、空きｉｎｏｄｅブロックマップ４１を更新し、区画番号が０以外である区画を管理するファイルサーバは、リザーブｉｎｏｄｅブロックマップ４７ａを更新することによってｉｎｏｄｅブロックを開放する。
区画分割部２２５は、オペレータより区画分割の要求を受け、区画分割をおこなう処理部である。具体的には、オペレータから分割の基点となるディレクトリの名前と新区画番号を受け取り、再帰的処理によって、基点となるディレクトリ以下の全てのファイルおよびディレクトリの現区画番号３２１を更新する。この区画分割部２２５が、現区画番号３２１を更新することによって区画分割をおこなうこととしたので、効率良く区画の分割をおこなうことができる。
担当区画変更部２２６は、オペレータより担当区画変更要求を受け、担当区画の変更を動的におこなう処理部である。具体的には、担当表２１１を更新することによって、各ファイルサーバが担当する区画を動的に変更する。
次に、第２図に示した要求受付部２２１の処理手順について説明する。第６図は、第２図に示した要求受付部２２１の処理手順を示すフローチャートである。同図に示すように、この要求受付部２２１は、操作要求を受け付けたファイルまたはディレクトリに対するファイルハンドル３１０を受け取り、受け取ったファイルハンドル３１０のｉｎｏｄｅ番号を用いてｉｎｏｄｅキャッシュ２１２またはメタディスク４０からｉｎｏｄｅ３２０を読み込む（ステップＳ６０１）。
そして、ｉｎｏｄｅ３２０の現区画番号３２１および担当表２１１を用いてｉｎｏｄｅ３２０の現区画が自ファイルサーバの担当する区画であるか否かを調べ（ステップＳ６０２）、自ファイルサーバが担当する区画でない場合には、現区画番号３２１が設定済みであるか否かを調べる（ステップＳ６０３）。ここで、現区画番号３２１が設定済みであれば、他のファイルサーバが現区画を担当している場合であるので、受け取った操作要求がファイルの読み出しまたは書き込みであるか否かを調べ（ステップＳ６０４）、ファイルの読み出しまたは書き込みである場合には、現区画を担当するファイルサーバにファイルの格納位置を問い合わせる（ステップＳ６０５）。そして、問い合わせた位置に基づいてデータディスク５０をアクセスし（ステップＳ６０６）、結果を操作要求元に応答する（ステップＳ６０７）。
一方、受け取った操作要求がファイルの読み出しでも書き込みでもない場合には、現区画を担当するファイルサーバへ操作要求をルーティングする（ステップＳ６０８）。そして、ルーティング先のファイルサーバから操作結果を受信すると（ステップＳ６０９）、その結果を操作要求元に応答する（ステップＳ６０７）。
また、現区画番号３２１が設定済みでなければ、ファイルまたはディレクトリが作成されたことが自ファイルサーバのｉｎｏｄｅキャッシュ２１１に伝播されていない場合であるので、ファイルハンドル３１０の生成時区画番号３１２および担当表２１１を用いて生成時区画が担当区画であるか否かを調べ（ステップＳ６１０）、担当区画でない場合には、受け取った操作要求がファイルの読み出しまたは書き込みであるか否かを調べる（ステップＳ６１１）。そして、受け取った操作要求がファイルの読み出しでも書き込みでもない場合には、生成時区画を担当するファイルサーバへ操作要求をルーティングする（ステップＳ６１２）。そして、ルーティング先のファイルサーバから操作結果を受信すると（ステップＳ６０９）、その結果を操作要求元に応答する（ステップＳ６０７）。
一方、受け取った操作要求がファイルの読み出しまたは書き込みである場合には、生成時区画を担当するファイルサーバにファイルの格納位置を問い合わせ（ステップＳ６１３）、問い合わせた位置に基づいてデータディスク５０をアクセスし（ステップＳ６１４）、結果を操作要求元に応答する（ステップＳ６０７）。
また、ファイルハンドル３１０の生成時区画が担当区画でない場合には、エラー処理をおこない（ステップＳ６１５）、その結果を操作要求元に応答する（ステップＳ６０７）。
また、ｉｎｏｄｅ３２０の現区画が自ファイルサーバの担当する区画である場合には、自ファイルサーバで操作要求に対するファイル処理をおこない（ステップＳ６１６）、結果を操作要求元に応答する（ステップＳ６０７）。
このように、この要求受付部２２１は、操作要求とともに受け取ったファイルハンドル３１０および担当表２１１を用いて操作要求対象のファイルまたはディレクトリの属する区画番号を認識することができ、ファイル処理をおこなうファイルサーバを決定することができる。
次に、第２図に示したファイル操作部２２２の処理手順について説明する。なお、このファイル操作部２２２の処理は、第６図に示したファイル処理（ステップＳ６１６）の処理に対応する。また、このファイル操作部２２２は、自サーバからの処理要求に対する処理だけでなく、他のファイルサーバがルーティングした処理要求に対する処理もおこなう。第７図は、第２図に示したファイル操作部２２２の処理手順を示すフローチャートである。
同図に示すように、このファイル操作部２２２は、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理であるか否かを調べる（ステップＳ７０１）。そして、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理である場合には、ｉｎｏｄｅブロック割り当て処理によって空きｉｎｏｄｅブロックを取得し（ステップＳ７０２）、取得したｉｎｏｄｅ３２０の現区画番号３２１と生成時区画番号３２２としてファイルハンドル３１０で指定された親ディレクトリの区画番号を設定し（ステップＳ７０３）、生成したファイルまたはディレクトリを親ディレクトリに登録する（ステップＳ７０４）。このように、生成したファイルまたはディスレクトリは、親のディレクトリと同じ区画に分類される。
一方、受け取ったファイル操作要求がファイルまたはディレクトリの生成処理でない場合には、受け取ったファイル操作要求がファイルまたはディレクトリの削除要求であるか否かを調べ（ステップＳ７０５）、ファイルまたはディレクトリの削除要求である場合には、ファイルハンドル３１０で指定された親のディレクトリ情報を読み込み（ステップＳ７０６）、削除要求のあったファイルまたはディレクトリを削除して親のディレクトリ情報を更新し（ステップＳ７０７）、削除したファイルまたはディレクトリに使用されていたｉｎｏｄｅ３２０に対してｉｎｏｄｅブロック無効化処理をおこなう（ステップＳ７０８）。
一方、受け取ったファイル操作要求がファイルまたはディレクトリの削除要求でない場合には、ファイルハンドル３１０で指定されたファイルまたはディレクトリについての情報を読み込んでファイル操作要求元へ送信する（ステップＳ７０９）。
そして、最後に、操作要求を受け付けたファイルサーバが自ファイルサーバであるか否かを調べ（ステップＳ７１０）、要求を受け付けたファイルサーバが自ファイルサーバでない場合には、要求元ファイルサーバに応答する（ステップＳ７１１）。
このように、このファイル操作部２２２が、生成したファイルまたはディレクトリのｉｎｏｄｅ中の現区画番号３２１に親ディレクトリの区画番号を書き込むことによって、生成したファイルまたはディレクトリに対する操作要求を処理するファイルサーバを指定することができる。
次に、第２図に示したｉｎｏｄｅ割当部２２３の処理手順について説明する。なお、このｉｎｏｄｅ割当部２２３の処理は、第７図に示したｉｎｏｄｅブロック割り当て処理（ステップＳ７０２）に対応する。第８図は、第２図に示したｉｎｏｄｅ割当部２２３の処理手順を示すフローチャートである。
同図に示すように、このｉｎｏｄｅ割当部２２３は、割り当てるｉｎｏｄｅブロックの区画番号が０であるか否かを調べる（ステップＳ８０１）。そして、区画番号が０である場合には、空きｉｎｏｄｅブロックマップ４１を用いて未使用ｉｎｏｄｅ番号を取得し（ステップＳ８０２）、ｉｎｏｄｅブロックを割り当て（ステップＳ８０３）、空きｉｎｏｄｅブロックマップ４１を更新する（ステップＳ８０４）。
一方、割り当てるｉｎｏｄｅブロックの区画番号が０でない場合には、区画番号に対応するリザーブｉｎｏｄｅブロックマップ４７ａを用いて空きｉｎｏｄｅ番号を取得し（ステップＳ８０５）、ｉｎｏｄｅブロックを割り当て（ステップＳ８０６）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ８０７）。そして、空きｉｎｏｄｅブロック数が所定値以下になったか否かを調べ（ステップＳ８０８）、所定値以下でない場合には、処理を終了する。これに対して、空きｉｎｏｄｅブロック数が所定値以下になった場合には、ｉｎｏｄｅリザーブ要求をおこない（ステップＳ８０９）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ８１０）。
次に、第２図に示したｉｎｏｄｅ開放部２２４の処理手順について説明する。なお、このｉｎｏｄｅ開放部２２４の処理は、第７図に示したｉｎｏｄｅブロック無効化処理（ステップＳ７０８）に対応する。第９図は、第２図に示したｉｎｏｄｅ開放部２２４の処理手順を示すフローチャートである。
同図に示すように、このｉｎｏｄｅ開放部２２４は、開放するｉｎｏｄｅブロックが属する区画の番号が０であるか否かを調べ（ステップＳ９０１）、０である場合には、空きｉｎｏｄｅブロックマップ４１を更新する（ステップＳ９０２）。一方、区画の番号が０でない場合には、区画の番号に対応するリザーブｉｎｏｄｅブロックマップ４７ａを更新し（ステップＳ９０３）、空きｉｎｏｄｅブロック数が所定値以上であるか否かを調べ（ステップＳ９０４）、所定値以上でない場合には、処理を終了する。
これに対して、空きｉｎｏｄｅブロック数が所定値以上である場合には、リザーブしている空きｉｎｏｄｅブロックの開放を区画０を管理しているファイルサーバに通知し（ステップＳ９０５）、リザーブｉｎｏｄｅブロックマップ４７ａを更新する（ステップＳ９０６）。この場合、区画０を管理しているファイルサーバは、空きｉｎｏｄｅブロックマップ４１を更新し、ｉｎｏｄｅ３２０の同期的な書き込みをおこない、該当ｉｎｏｄｅキャッシュの無効化を全ファイルサーバに依頼する。
次に、第２図に示した区画分割部２２５の処理手順について説明する。第１０図は、第２図に示した区画分割部２２５の処理手順を示すフローチャートである。同図に示すように、この区画分割部２２５は、オペレータから基点ディレクトリの名前と新区画番号を受け付け（ステップＳ１００１）、メタディスク４０から基点ディレクトリのｉｎｏｄｅ３２０を読み出す（ステップＳ１００２）。そして、読み出したｉｎｏｄｅ３２０から現区画番号３２１を取り出し（ステップＳ１００３）、再帰的区画分割処理をおこなう（ステップＳ１００４）。
ここで、この再帰的区画分割処理（ステップＳ１００４）の処理手順について説明する。第１１図は、第１０図に示した再帰的区画分割処理の処理手順を示すフローチャートである。同図に示すように、この再帰的区画分割処理は、親ディレクトリの分割処理をおこなっている親ファイルサーバが、子供のファイルまたはディレクトリが属する区画を担当する子ファイルサーバにｉｎｏｄｅ３２０および新区画番号を送信する（ステップＳ１１０１）。なお、親ファイルサーバと子ファイルサーバは、子供のファイルまたはディレクトリが生成された時点では、同一のファイルサーバとなるが、区画分割や担当区画の変更によって別のファイルサーバとなる場合もある
一方、子ファイルサーバは、ｉｎｏｄｅ３２０および新区画番号を受信し（ステップＳ１１０２）、ｉｎｏｄｅキャッシュ２１１内のｉｎｏｄｅ３２０の現区画番号３２１を新区画番号に更新する（ステップＳ１１０３）。また、更新結果をメタディスク４０に反映し（ステップＳ１１０４）、更新したｉｎｏｄｅ３２０の無効化要求を他のファイルサーバに送信し（ステップＳ１１０５）、他のファイルサーバのｉｎｏｄｅキャッシュのｉｎｏｄｅ３２０を無効化する。
そして、更新したｉｎｏｄｅ３２０がディレクトリである場合には、そのディレクトリが子供を有するか否かを調べ（ステップＳ１１０６）、子供を有する場合には、子供のｉｎｏｄｅ３２０をメタディスク４０から読み出し（ステップＳ１１０７）、読み出したｉｎｏｄｅ３２０から子供の現区画番号３２１を取り出し（ステップＳ１１０８）、子供に対して再帰的分割処理をおこなう（ステップＳ１１０９）。その後、子供の更新完了を受信すると（ステップＳ１１１０）、ステップＳ１１０６に戻って次の子供の処理をおこなう。一方、子供がない場合または子供の処理が全て終了した場合には、更新完了を親ファイルサーバに送信し（ステップＳ１１１１）、処理を終了する。
このように、この区画分割部２２５が、オペレータから基点ディレクトリと新区画番号を受け付け、再帰的区画分割処理を用いて基点ディレクトリに属する全てのファイルおよびディレクトリの現区画番号３２１を変更し、変更したｉｎｏｄｅ３２０の無効化要求を他のファイルサーバに送信することとしたので、複数のファイルサーバのｉｎｏｄｅキャッシュに記憶されているｉｎｏｄｅ３２０の整合性を保つとともに、効率良く区画分割をおこなうことができる。
なお、ｉｎｏｄｅブロックの更新は、ｉｎｏｄｅ３２０が属する区画を管理するファイルサーバでのみおこない、複数のファイルサーバが同時に更新することはない。これによりメタディスク４０上のｉｎｏｄｅ３２０が誤って破壊されることを防止している。
また、ｉｎｏｄｅ３２０中に設定される現区画番号３２１が変更されるのは、ファイルまたはディレクトリを生成あるいは削除したときと区画を分割した場合のみである。このうち、ファイルまたはディレクトリの生成および削除は、一般の運用中に発生する操作であり、ｉｎｏｄｅ３２０の更新を他ファイルサーバと同期して行う（キャッシュのパージとメタディスク４０への反映）と性能面のペナルティが大きい。そこで、このクラスタファイルシステム１００ではｉｎｏｄｅ３２０の更新結果を他ファイルサーバに直ちに伝播させることはおこなわない。何故ならば、ファイル操作要求で指定されたファイルハンドル３１０中に設定されているｉｎｏｄｅ番号から一意にディスク上のｉｎｏｄｅ３２０が求まり、矛盾が発生しないためである。
すなわち、ディスク上のｉｎｏｄｅ３２０に設定されている現区画番号３２１が一時的に不当な値となる場合がいくつかあるが、そのうち、過去に現区画番号３２１が存在し、他のファイルサーバで削除されたファイルの削除結果がまだ伝播していない場合には、ディスク上のｉｎｏｄｅ３２０に入っている現区画番号３２１で決まるファイルサーバに要求がルーティングされ、ルーティング先のファイルサーバではこのファイルが一旦削除されたことを必ず認識できるので、ファイルが既に存在しないことを応答できる。
また、他のファイルサーバで新たに作成されたファイルの作成結果がまだ伝播していない場合で、かつ、過去に存在した現区画番号３２１が他のファイルサーバで削除され、同じファイルサーバで新たに別のファイルに割り当てられた場合には、ディスク上のｉｎｏｄｅ３２０に設定されている現区画番号３２１のファイルサーバに要求をルーティングすれば、そのファイルサーバでファイル作成結果が必ずキャッシュを介して認識されるはずであるから、現区画番号は正しく認識される。
また、他のファイルサーバで新たに作成されたファイルの作成結果がまだ伝播していない場合で、かつ、過去に存在した現区画番号３２１が他のファイルサーバ（ファイルサーバＡ）で削除され、その後別のファイルサーバ（ファイルサーバＢ）で新たに別のファイルに割り当てられた場合には、ファイルサーバＡでリザーブしていたｉｎｏｄｅ３２０が別のファイルサーバＢで使用されていることから、そのｉｎｏｄｅ３２０は必ず区画番号が０である区画を管理するファイルサーバに返却されているはずである。したがって、ディスク上のｉｎｏｄｅ３２０の上塗りを防ぐため、ディスクｉｎｏｄｅ３２０の同期的書き出しとｉｎｏｄｅキャッシュの無効化が行われているはずであり、ファイルサーバＡが行った削除の結果がディスク上のｉｎｏｄｅ３２０に反映されているはずであって、ファイルサーバＡに対応する区画がディスク上のｉｎｏｄｅ３２０に設定されていることはありえない。すなわち、ディスク上のｉｎｏｄｅ３２０の現区画番号３２１には、未割り当てを示す値が設定されているはずであり、その結果、ファイルハンドル３１０に設定されている生成時区画に対応するファイルサーバ（このケースではファイルサーバＢ）にルーティングが行われ正しく処理される。
したがって、このクラスタファイルシステム１００では、通常のファイル操作要求の処理にともなうメタデータの更新結果を各ファイルサーバが保持するログディスクに書き出すのみで、メタディスク４０の更新はキャッシュを介して、適当なタイミングで非同期に書き出すことが可能となる。
また、区画分割をおこなった場合には、ｉｎｏｄｅ３２０の現区画番号３２１の変更はその区画を管理しているファイルサーバでメタディスク４０を介して同期的に行われる。したがって、他のファイルサーバには変更の結果が即座に伝わり、ルーティング上の問題は発生しない。
上述したように、本実施の形態では、全てのファイルサーバ３０１〜３０Ｎが共用するメタディスク４０にファイルおよびディレクトリのメタデータを有するｉｎｏｄｅ３２０を記憶し、ファイルおよびディレクトリをそれらの名前に基づいて複数の区画に分類し、各区画を管理するファイルサーバを定めて各区画に属するファイル、ディレクトリおよびそれらのメタデータを分割管理する。そして、ファイル操作部２２２が、新たに生成したファイルおよびディレクトリのｉｎｏｄｅ３２０にそれらの属する区画番号を書き込み、要求受付部２２１がｉｎｏｄｅ３２０が有する区画番号に基づいて要求を処理するファイルサーバを決定することとしたので、メタデータを管理するファイルサーバを変更した場合にも、ファイルサーバ間でメタデータを移動する必要がなく、管理ファイルサーバ変更にともなうオーバヘッドを少なくすることができ、スケーラブルなクラスタファイルシステムを実現することができる。
また、本実施の形態では、ファイル操作部２２２が、同一のディレクトリに属するファイルおよびディレクトリのメタデータを同一区画に記憶することとしたので、多数のファイルに関する属性情報を収集する必要がある場合にも、属性情報をまとめてファイルサーバ間で転送することができ、ファイルサーバ間のデータ転送によるオーバヘッドを少なくすることができ、安定した性能をもつスケーラブルなクラスタファイルシステムを実現することができる。
また、本実施の形態では、ファイルおよびディレクトリに関する情報を記憶するｉｎｏｄｅ３２０の更新は、そのファイルおよびディレクトリが属する区画を管理するファイルサーバだけがおこない、ｉｎｏｄｅ３２０を更新したファイルサーバは、リザーブ中ｉｎｏｄｅ３２０を区画０を管理しているファイルサーバに返却する際に、他のファイルサーバにｉｎｏｄｅキャッシュ２１１のデータを無効とする指示を送信することとしたので、複数のファイルサーバのｉｎｏｄｅキャッシュに記憶されるｉｎｏｄｅ３２０の整合性を保証することができる。
以上説明したように、本発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
また、本発明によれば、ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含むファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込み、操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
また、本発明によれば、複数のファイルサーバで共用され、ファイルのメタ情報を記憶するメタデータ記憶装置を備え、複数のファイルサーバのそれぞれは、ファイルに対する操作要求を受け付け、受け付けた操作要求を処理するファイルサーバの決定をメタデータ記憶装置に記憶されたメタ情報に基づいておこなうよう構成したので、メタデータを管理するファイルサーバの変更にともなうオーバヘッドを少なくするとともに、メタデータの移動に起因するファイル識別情報の変更を不要とし、もってファイルシステムの処理能力をスケーラブルに拡張することができるという効果を奏する。
以上のように、本発明に係るファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステムは、複数のファイルサーバが同じファイルを共用するとともにスケーラブルな処理能力を必要とするファイルシステムに適している。
Claims (20)
- 複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理装置であって、
ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイル管理装置が共用する記憶装置に書き込む分担ファイル処理手段と、
操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理手段により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定手段と、
を備えたことを特徴とするファイル管理装置。 - ファイルの名前に基づいてファイルの名前空間を複数の区画に分割し、各ファイルを名前が属する区画に分類し、前記分担ファイル処理手段は、前記区画を識別する区画識別子を前記管理分担情報とし、前記分担判定手段は、前記区画識別子に基づいて前記判定をおこなうことを特徴とする請求の範囲第１項に記載のファイル管理装置。
- 前記分担判定手段によりおこなわれた判定に基づいて、管理を分担する区画に属するファイル以外に対する操作要求を処理する分担外ファイル処理手段をさらに備え、前記分担ファイル処理手段は、前記分担判定手段によりおこなわれた判定に基づいて、管理を分担する区画に属するファイルに対する操作要求を前記ファイル生成要求に加えて処理することを特徴とする請求の範囲第２項に記載のファイル管理装置。
- 前記分担ファイル処理手段は、生成したファイルのメタ情報を前記記憶装置にファイル制御ブロックとして書き込み、該ファイル制御ブロックは、ファイルが現在属する区画を識別する現区画識別子と該ファイルが生成された際に属した区画を識別する生成時区画識別子を有することを特徴とする請求の範囲第３項に記載のファイル管理装置。
- 前記分担ファイル処理手段は、自分が管理を分担する区画に属する親ディレクトリの下に生成するファイルおよびディレクトリが属する区画を該親ディレクトリが属する区画とすることを特徴とする請求の範囲第３項または第４項に記載のファイル管理装置。
- 前記分担ファイル処理手段は、前記操作要求でファイルを指定する場合に使用するファイルハンドルに前記生成時区画識別子を含めることを特徴とする請求の範囲第４項に記載のファイル管理装置。
- 前記分担判定手段は、前記現区画識別子および前記ファイルハンドルに含まれる生成時区画識別子を用いて前記判定をおこなうことを特徴とする請求の範囲第６項に記載のファイル管理装置。
- 各ファイル管理装置が分担して管理する区画の区画識別子と各ファイル管理装置を対応させて記憶した管理区画分担記憶手段と、オペレータの指示に基づいて前記管理区画分担記憶手段を動的に変更する区画分担変更手段と、をさらに備え、前記分担判定手段は、前記管理区画分担記憶手段を用いて前記判定をおこなうことを特徴とする請求の範囲第２項に記載のファイル管理装置。
- 前記区画の分割を変更する区画分割手段をさらに備えたことを特徴とする請求の範囲第４項に記載のファイル管理装置。
- 前記区画分割手段は、オペレータが指定した新区画識別子とディレクトリに基づいて、該ディレクトリの下にある全てのファイルおよびディレクトリの現区画識別子を新区画識別子に変更することを特徴とする請求の範囲第９項に記載のファイル管理装置。
- 前記記憶装置に記憶されるファイル制御ブロックのアクセスを高速にするキャッシュ記憶手段をさらに備え、前記区画分割手段は、他のファイル管理装置に備えられた前記キャッシュ記憶手段に記憶されたファイル制御ブロックのうち現区画識別子を新区画識別子に変更したファイル制御ブロックを無効とする指示をおこなうことを特徴とする請求の範囲第１０項に記載のファイル管理装置。
- 前記分担外ファイル処理手段は、前記操作要求の対象であるファイルの管理を分担するファイル管理装置から該ファイルのメタ情報を受け取って該操作要求を処理する分担外要求処理手段と、前記管理を分担するファイル以外に対する操作要求を、該ファイルの管理を分担するファイル管理装置に転送する分担外要求転送手段と、を備えたことを特徴とする請求の範囲第３項に記載のファイル管理装置。
- 複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理プログラムであって、
ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理手順と、
操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理手順により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定手順と、
をファイルサーバで実行することを特徴とするファイル管理プログラム。 - ファイルの名前に基づいてファイルの名前空間を複数の区画に分割し、各ファイルを名前が属する区画に分類し、前記分担ファイル処理手順は、前記区画を識別する区画識別子を前記管理分担情報とし、前記分担判定手順は、前記区画識別子に基づいて前記判定をおこなうことを特徴とする請求の範囲第１３項に記載のファイル管理プログラム。
- 前記分担判定手順によりおこなわれた判定に基づいて、管理を分担する区画に属するファイル以外に対する操作要求を処理する分担外ファイル処理手順をさらに実行し、前記分担ファイル処理手順は、前記分担判定手順によりおこなわれた判定に基づいて、管理を分担する区画に属するファイルに対する操作要求を前記ファイル生成要求に加えて処理することを特徴とする請求の範囲第１４項に記載のファイル管理プログラム。
- 複数のファイルサーバが同じファイルを共用することができるファイルシステムのファイルおよび該ファイルのメタ情報を分担して管理するファイル管理方法であって、
ファイル生成要求を受け付けて生成したファイルが管理分担の対象ファイルであることを示す管理分担情報を含む該ファイルのメタ情報を、全てのファイルサーバが共用する記憶装置に書き込む分担ファイル処理工程と、
操作要求を受け付けたファイルが管理分担の対象ファイルであるか否かの判定を、前記分担ファイル処理工程により前記記憶装置に書き込まれたメタ情報に含まれる管理分担情報に基づいておこなう分担判定工程と、
を含んだことを特徴とするファイル管理方法。 - ファイルの名前に基づいてファイルの名前空間を複数の区画に分割し、各ファイルを名前が属する区画に分類し、前記分担ファイル処理工程は、前記区画を識別する区画識別子を前記管理分担情報とし、前記分担判定工程は、前記区画識別子に基づいて前記判定をおこなうことを特徴とする請求の範囲第１６項に記載のファイル管理方法。
- 複数のファイルサーバが同じファイルを共用することができるファイルシステムであって、
前記複数のファイルサーバで共用され、前記ファイルのメタ情報を記憶するメタデータ記憶装置を備え、
前記複数のファイルサーバのそれぞれは、前記ファイルに対する操作要求を受け付け、該受け付けた操作要求を処理するファイルサーバの決定を前記メタデータ記憶装置に記憶されたメタ情報に基づいておこなうことを特徴とするファイルシステム。 - 前記複数のファイルサーバのうち１台のファイルサーバが全体管理ファイルサーバとして前記メタデータ記憶装置の空き領域を管理することを特徴とする請求の範囲第１８項に記載のファイルシステム。
- 前記複数のファイルサーバのうち前記全体管理ファイルサーバ以外のファイルサーバは、該全体管理ファイルサーバから一括して所定の大きさの空き領域を予約し、該予約した空き領域を用いて分担して管理するメタ情報を記憶することを特徴とする請求の範囲第１９項に記載のファイルシステム。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2002/013252 WO2004055675A1 (ja) | 2002-12-18 | 2002-12-18 | ファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPWO2004055675A1 true JPWO2004055675A1 (ja) | 2006-04-20 |
Family
ID=32587970
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004560587A Pending JPWO2004055675A1 (ja) | 2002-12-18 | 2002-12-18 | ファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20050234867A1 (ja) |
| JP (1) | JPWO2004055675A1 (ja) |
| WO (1) | WO2004055675A1 (ja) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7647355B2 (en) * | 2003-10-30 | 2010-01-12 | International Business Machines Corporation | Method and apparatus for increasing efficiency of data storage in a file system |
| US7548918B2 (en) * | 2004-12-16 | 2009-06-16 | Oracle International Corporation | Techniques for maintaining consistency for different requestors of files in a database management system |
| US7716260B2 (en) * | 2004-12-16 | 2010-05-11 | Oracle International Corporation | Techniques for transaction semantics for a database server performing file operations |
| US7627574B2 (en) * | 2004-12-16 | 2009-12-01 | Oracle International Corporation | Infrastructure for performing file operations by a database server |
| US7809675B2 (en) * | 2005-06-29 | 2010-10-05 | Oracle International Corporation | Sharing state information among a plurality of file operation servers |
| US8224837B2 (en) * | 2005-06-29 | 2012-07-17 | Oracle International Corporation | Method and mechanism for supporting virtual content in performing file operations at a RDBMS |
| US8091089B2 (en) | 2005-09-22 | 2012-01-03 | International Business Machines Corporation | Apparatus, system, and method for dynamically allocating and adjusting meta-data repository resources for handling concurrent I/O requests to a meta-data repository |
| US7610304B2 (en) * | 2005-12-05 | 2009-10-27 | Oracle International Corporation | Techniques for performing file operations involving a link at a database management system |
| US20070150492A1 (en) * | 2005-12-27 | 2007-06-28 | Hitachi, Ltd. | Method and system for allocating file in clustered file system |
| US8156507B2 (en) * | 2006-12-08 | 2012-04-10 | Microsoft Corporation | User mode file system serialization and reliability |
| US9292547B1 (en) * | 2010-01-26 | 2016-03-22 | Hewlett Packard Enterprise Development Lp | Computer data archive operations |
| US8453145B1 (en) * | 2010-05-06 | 2013-05-28 | Quest Software, Inc. | Systems and methods for instant provisioning of virtual machine files |
| US9547562B1 (en) | 2010-08-11 | 2017-01-17 | Dell Software Inc. | Boot restore system for rapidly restoring virtual machine backups |
| US8495112B2 (en) | 2010-09-10 | 2013-07-23 | International Business Machines Corporation | Distributed file hierarchy management in a clustered redirect-on-write file system |
| US20120151005A1 (en) * | 2010-12-10 | 2012-06-14 | Inventec Corporation | Image file download method |
| CN102693232B (zh) * | 2011-03-23 | 2014-05-21 | 腾讯科技（深圳）有限公司 | 一种删除文件的方法及文件删除装置 |
| US9852139B1 (en) * | 2012-07-02 | 2017-12-26 | Veritas Technologies Llc | Directory partitioning with concurrent directory access |
| CN102937918B (zh) * | 2012-10-16 | 2016-03-30 | 西安交通大学 | 一种hdfs运行时数据块平衡方法 |
| US10127236B1 (en) * | 2013-06-27 | 2018-11-13 | EMC IP Holding Company | Filesystem storing file data in larger units than used for metadata |
| US10103946B2 (en) * | 2014-01-21 | 2018-10-16 | Oracle International Corporation | System and method for JMS integration in a multitenant application server environment |
| US9961011B2 (en) | 2014-01-21 | 2018-05-01 | Oracle International Corporation | System and method for supporting multi-tenancy in an application server, cloud, or other environment |
| US9965361B2 (en) * | 2015-10-29 | 2018-05-08 | International Business Machines Corporation | Avoiding inode number conflict during metadata restoration |
| US10713215B2 (en) | 2015-11-13 | 2020-07-14 | International Business Machines Corporation | Allocating non-conflicting inode numbers |
| US11579978B2 (en) * | 2018-02-14 | 2023-02-14 | Rubrik, Inc. | Fileset partitioning for data storage and management |
| CN109491772B (zh) * | 2018-09-28 | 2020-10-27 | 深圳财富农场互联网金融服务有限公司 | 业务序号生成方法、装置、计算机设备和存储介质 |
| JP7270755B2 (ja) * | 2019-03-04 | 2023-05-10 | ヒタチ ヴァンタラ エルエルシー | 分散システムでのメタデータルーティング |
| CN113703667A (zh) * | 2021-07-14 | 2021-11-26 | 深圳市有为信息技术发展有限公司 | 实时存储数据的文件系统处理方法、装置、车载终端及商用车 |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6658417B1 (en) * | 1997-12-31 | 2003-12-02 | International Business Machines Corporation | Term-based methods and apparatus for access to files on shared storage devices |
| AU3304699A (en) * | 1998-02-20 | 1999-09-06 | Storm Systems Llc | File system performance enhancement |
| US20030140112A1 (en) * | 1999-11-04 | 2003-07-24 | Satish Ramachandran | Electronic messaging system method and apparatus |
| JP2001306403A (ja) * | 2000-04-27 | 2001-11-02 | Toshiba Corp | ストレージ装置およびファイル共有システム |
| JP2001318905A (ja) * | 2000-05-02 | 2001-11-16 | Matsushita Electric Ind Co Ltd | ディスク共有型分散サーバシステム |
| EP1532543A4 (en) * | 2000-09-11 | 2008-04-16 | Agami Systems Inc | STORAGE SYSTEM COMPRISING PARTITIONED METADATA THAT MIGRATE LIKELY |
| JP2002108673A (ja) * | 2000-09-29 | 2002-04-12 | Toshiba Corp | 共有ファイルシステム及び同システムに適用されるメタデータサーバコンピュータ |
| US6883029B2 (en) * | 2001-02-14 | 2005-04-19 | Hewlett-Packard Development Company, L.P. | Separate read and write servers in a distributed file system |
| US7062490B2 (en) * | 2001-03-26 | 2006-06-13 | Microsoft Corporation | Serverless distributed file system |
| US7191190B2 (en) * | 2001-03-27 | 2007-03-13 | Microsoft Corporation | Meta data management for media content objects |
| US7024427B2 (en) * | 2001-12-19 | 2006-04-04 | Emc Corporation | Virtual file system |
| US7177868B2 (en) * | 2002-01-02 | 2007-02-13 | International Business Machines Corporation | Method, system and program for direct client file access in a data management system |
| US6829617B2 (en) * | 2002-02-15 | 2004-12-07 | International Business Machines Corporation | Providing a snapshot of a subset of a file system |
| JP4146653B2 (ja) * | 2002-02-28 | 2008-09-10 | 株式会社日立製作所 | 記憶装置 |
| US7115919B2 (en) * | 2002-03-21 | 2006-10-03 | Hitachi, Ltd. | Storage system for content distribution |
-
2002
- 2002-12-18 WO PCT/JP2002/013252 patent/WO2004055675A1/ja active Application Filing
- 2002-12-18 JP JP2004560587A patent/JPWO2004055675A1/ja active Pending
-
2005
- 2005-06-14 US US11/151,197 patent/US20050234867A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20050234867A1 (en) | 2005-10-20 |
| WO2004055675A1 (ja) | 2004-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPWO2004055675A1 (ja) | ファイル管理装置、ファイル管理プログラム、ファイル管理方法およびファイルシステム | |
| CN110554834B (zh) | 文件系统数据访问方法和文件系统 | |
| JP4349301B2 (ja) | ストレージ管理システムと方法並びにプログラム | |
| US6766430B2 (en) | Data reallocation among storage systems | |
| US8316066B1 (en) | Shadow directory structure in a distributed segmented file system | |
| JP5007350B2 (ja) | ハードウェアベースのファイルシステムのための装置および方法 | |
| JP4115093B2 (ja) | 計算機システム | |
| US7194492B2 (en) | Method and apparatus for efficiently copying distributed data files | |
| US7836017B1 (en) | File replication in a distributed segmented file system | |
| US20030236850A1 (en) | Storage system for content distribution | |
| US20090240880A1 (en) | High availability and low capacity thin provisioning | |
| EP0398494A2 (en) | Maintenance of file attributes in a distributed data processing system | |
| JP4615344B2 (ja) | データ処理システム及びデータベースの管理方法 | |
| US20070192375A1 (en) | Method and computer system for updating data when reference load is balanced by mirroring | |
| JP2010533324A (ja) | クラスタ化されたファイル・システムへのファイル・システムのマウンティング | |
| JPH10254761A (ja) | 共用メモリ・コンピュータ・ネットワーク | |
| JP2009064120A (ja) | 検索システム | |
| CN111881107B (zh) | 支持多文件系统挂载的分布式存储方法 | |
| CN113032356A (zh) | 一种客舱分布式文件存储系统及实现方法 | |
| JP2006164218A (ja) | ストレージシステム及びそのキャッシュ制御方法 | |
| KR100472207B1 (ko) | 다중 레이드 제어기를 통한 데이터 분산 공유 레이드 제어시스템 | |
| JP4005102B2 (ja) | ゲートウェイ装置 | |
| CN114297243A (zh) | 一种用于云数据库的远程存储服务本地缓存管理方法 | |
| Aladyshev et al. | Expectations of the High Performance Computing Cluster File System Selection | |
| JP2022070669A (ja) | データベースシステム、及びクエリ実行方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081020 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090106 |