JP2010287036A - ストレージサーバー装置及びコンピュータプログラム - Google Patents

Abstract

【課題】ネットワークを介して接続された複数のストレージサーバー装置から構成される分散ファイル管理システムにおいて、ファイルやディレクトリを分散して管理する。
【解決手段】分散ファイル管理システムを構成するストレージサーバー装置は、当該分散ファイル管理システム内で一意なファイル名を付けられたｉノードファイル、ディレクトリファイル、データファイルを分散してファイル蓄積部３２に記憶している。高レベルインタフェース部２４が、ディレクトリ名及びユーザ利用ファイル名によるファイル操作要求を受信した場合、パス検索部５は、ｉノードファイル、及び、ディレクトリファイルを参照して、ユーザ利用ファイル名に対応したデータファイル名を取得する。低レベルインタフェース部２３は、高レベルインタフェース部２４からの指示を受け、取得したデータファイル名のファイルに対して要求されたファイル操作を行なう。
【選択図】図１

Description

本発明は、ネットワークを介して接続された複数のストレージサーバー装置から構成される分散ファイル管理システムにおけるストレージサーバー装置及びコンピュータプログラムに関する。

コンピュータではユーザが保存するデータをファイルと呼ばれる一連のデータの塊として取り扱う。ファイルはハードディスクドライブ等の蓄積装置に記録される。ファイルのどこのデータを蓄積装置のどの場所に記録したかを管理している部分をファイルシステムと呼び、ＯＳ（オペレーティングシステム）の一部として動作している。ファイルシステムが利用する各ファイルの管理情報もまた蓄積装置内にデータ本体とともに記録される。また、多くのファイルシステムではファイルの管理だけでなく、複数のファイルを階層的に管理するため、ディレクトリとよばれる階層構造の管理も可能としている。

ファイルシステムには、主にＭＳ−ＤＯＳ（登録商標）やＷｉｎｄｏｗｓ（登録商標）で使われているＦＡＴ（File Allocation Table）ファイルシステム、ＮＴＳＦ（NT File System）や、ＵＮＩＸ（登録商標）系ＯＳで使われているＵＦＳ（ＵＮＩＸ（登録商標） File System）、ＦＦＳ（Fast File System）、ｅｘｔ２／３（Second Extended File System／Third Extended File System）、また、Ｍａｃｉｎｔｏｓｈ（登録商標）で使われているＨＦＳ（Hierarchical File System）＋、ＢＴＲＯＮ（Business TRON）系ＯＳで使われているファイルシステムなど様々な方式が存在する。

ここで、ＵＮＩＸ（登録商標）系ＯＳで使われているＵＦＳ、ＦＦＳ、ｅｘｔ２／３などのファイルシステムについて図３３を使って説明する。
図３３は、iノードによるファイル管理を説明する図である。ＵＦＳ、ＦＦＳ、ｅｘｔ２／３などのファイルシステムでは、ファイルのデータおよびディレクトリのデータはiノードと呼ばれる情報により管理され、１つのファイルのデータまたは１つのディレクトのデータ毎に１つのiノードが割り当てられる。iノードにはファイルのデータまたはディレクトリのデータが格納されているディスク上の位置、ファイルの作成時刻、ファイルサイズ等のファイルに関する情報が保存されている。iノードには一意な番号が割り振られ、このiノード番号によりファイルシステム内で一意に特定できる。

同図に示すように、iノードはディスク領域の特定の場所にその情報が保存される。一方、ディレクトリに関する基本的な情報を定義するディレクトリのデータや、ファイルのデータ本体は、データ格納領域に保存される。同図では「/usr」ディレクトリに保存されている「test.txt」ファイルを例に、iノードとディレクトリのデータ及びファイルのデータ本体との関係を示している。ディレクトリのデータには、そのディレクトリ内に作成されたディレクトリやファイルの名前とそのディレクトリやファイルのiノード番号が保存されている。そこで、「/usr/test.txt」のファイルを見つけ出すには、まず、iノード番号（i_no）が２のルートiノードから開始し、当該ルートiノードにより示されるディレクトリのデータを得る。このディレクトリのデータから「usr」ディレクトリのiノード番号が１０であることがわかる。さらに、iノード番号１０のディレクトリのデータから、「test.txt」という名前のファイルはiノード番号４４のファイルということがわかる。以上のように、ルートiノードを始点として、すべてのファイルに到達することができる。

また、Ｍａｃｉｎｔｏｓｈ（登録商標）系ＯＳで主に使われているＨＦＳ＋ファイルシステムでは、ファイルはデータフォークとリソースフォークと呼ばれる２つの領域を扱うことができる。データフォークはアプリケーションが自由にデータを書き込む領域である。一方、リソースフォークにはアイコンやウインドウの形状、メニューの内容や定義など、メタデータを保存する領域として使われる。さらにＢＴＲＯＮ系ＯＳで使われるファイルシステムでは、ファイルは複数のレコード列から構成される。レコードにはタイプ番号が付けられ、利用用途によって番号を決め、そのレコードのデータを利用目的により使い分けている。
このように、ＵＮＩＸ（登録商標）／Ｗｉｎｄｏｗｓ（登録商標）系ＯＳでは１ファイル１レコード、Ｍａｃｉｎｔｏｓｈ（登録商標）系ＯＳでは１ファイル２レコード、ＢＴＲＯＮ系ＯＳでは１ファイル複数レコードのファイル構造に対応してファイルシステムが作られている。

以上説明したファイルシステムは、１つのディスク内または１つのコンピュータ内でのファイルの管理であるため、ローカルファイルシステムとも呼ばれる。

一方、近年、コンピュータの高性能化、ネットワーク技術の向上により、複数のコンピュータをネットワークで接続し、複数のユーザがファイルを共有して扱うことが可能となり始めた。複数のコンピュータに保管されたファイルを仮想的に同一のディレクトリ構造で管理するための機構を分散ファイルシステムと呼ぶ。分散ファイルシステムでは、どのコンピュータのユーザからも同一のディレクトリパスによりファイルにアクセスできる。例えば、「/usr/test.txt」というファイルは、どのコンピュータのユーザからでも、ファイル本体がどこに保存されているかを気にすることなく「/usr/test.txt」というパス付きのファイル名でファイルにアクセスできる。

図３４は、分散ファイルシステムの一つであるＧＦＳ（Google File system）の例を示す。ＧＦＳではファイルを６４ＭＢ毎に分割したチャンクと呼ばれる単位でファイルが保存される。これらのチャンクはチャンクサーバーと呼ばれるサーバー群に分散して保存する。どのファイルのどのチャンクがどこのチャンクサーバーに保管されているかはマスターサーバーが管理しており、ユーザ（クライアント）は、まずマスターサーバーに問い合わせを行い、目的のファイルのチャンクがどのチャンクサーバーに保存されているかを知り、そのチャンクサーバーにアクセスすることで、目的のファイルにアクセスする。ディレクトリに関しても同様にマスターサーバーにより管理されている。これは、例えば、非特許文献１に記述されている。

また、分散ファイルシステムの他の例としてＧｆａｒｍがある。ＧｆａｒｍでもＧＦＳ同様にファイルは断片化して複数のサーバーに保存される。断片化の分割数、サイズなどは自由に決めることができる。これらの情報はＧＦＳ同様、メタデータサーバーにより一元的に管理されている。これは、例えば、非特許文献２に記述されている。

一方、ファイル名等から分散的に保存されたファイルの保管場所を高速に検索する方法として、Ｐ２Ｐ（Peer-to-Peer）型のファイル管理方法がある。Ｐ２Ｐ型の検索方法では、ファイル名とその保管先を一元管理しているサーバーが存在しないため、障害に強い特長を持つ。
Ｐ２Ｐ型のファイル管理方法は、非構造型と構造型に分類されるが、ここでは、ＤＨＴ（Distributed Hash Table）を使った構造型Ｐ２Ｐによるファイル管理技術を説明する。

ＤＨＴを使ったＰ２Ｐでは、複数のサーバーによりオーバーレイネットワークを構成する。図３５はＤＨＴを用いたＰ２Ｐオーバーレイネットワークを図示したものであり、この例では、円形のオーバーレイネットワークを形成している。オーバーレイネットワークに参加するサーバーは、例えばサーバーのアドレスを、ある決められたハッシュ関数（例えば、ＳＨＡ−１（Secure Hash Algorithm 1）、ＭＤ−５（Message Digest 5）)により演算して得たハッシュ値を当該サーバーのノードＩＤとして生成し、オーバーレイネットワーク内では、このノードＩＤにより各サーバーを識別する。円形のオーバーレイネットワークはノードＩＤを小さい順に時計周りに並べた状態を示している。各サーバーが記憶しているファイルには、例えばファイル名を元にハッシュ関数を用いて演算したハッシュ値をファイルＩＤとして用いる。オーバーレイネットワーク内では、ファイルＩＤに近いノードＩＤのサーバーがそのファイルを管理する。ここで、ファイルの管理とは、ファイルＩＤとそのファイルを記憶しているサーバーの情報（例えば、アドレスや、ポート番号）を保存することである。そこで、ファイルを利用したいユーザは、利用したいファイルＩＤから、ファイルＩＤに時計周りに近いノードＩＤのサーバーをオーバーレイネットワーク上で発見し、発見したサーバーから、その利用したいファイルを保有するサーバーのアドレスを読み出す。そして、この読み出したアドレスを用いることによって、利用したいファイルにアクセスすることができる。
上記のＤＨＴの代表的な例であるＣｈｏｒｄは、非特許文献３に記述されている。

Ｓ.Ｇｈｅｍａｗａｔ， Ｈ．ｇｏｂｏｆｆ， Ｓ−Ｔ．Ｌｅｕｎｇ, "Ｔｈｅ Ｇｏｏｇｌｅ Ｆｉｌｅ Ｓｙｓｔｅｍ, "Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ（ＡＣＭ ＳＩＧＯＰＳ）， ｐｐ．２９−４３， ２００３ 建部、森田、松岡、関口、曾田，"ペタスケール広域分散データ解析のためのＧｒｉｄ Ｄａｔａｆａｒｍアーキテクチャ"，情報処理学会研究報告，ハイパフォーマンスコンピューティング８７−３１，ｐｐ．１７７−１８２，２００１ Ｉ．Ｓｔｏｉｃａ ｅｔ ａｌ， "Ｃｈｏｒｄ：Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｌｏｏｋ ｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ"， Ｐｒｏｃ. ＡＣＭ ＳＩＧＣＯＭＭ'０１, Ａｕｇ. ２００１

以上説明したように、従来の分散ファイルシステムでは、ファイルの保管場所は複数のストレージサーバーに分散されて保存されているが、ファイルの管理、ディレクトリの管理などは特定のサーバーにより一元的に管理する方式がとられているため、ＳＰＯＦ（単一障害点）がある不完全な分散型ファイルシステムであった。つまり、ファイルやディレクトリを管理するサーバーが障害となった場合は、いずれのファイルにもアクセスすることができなくなってしまう。また、このようにファイルの管理やディレクトリの管理を特定の管理サーバーにより一元的に管理するシステムでは、同時に多数のユーザがファイルを利用した場合、この管理サーバーにアクセスが集中してしまうため、速度性能が低下するという問題があった。さらに、管理するファイル数やディレクトリ数が多くなると、管理サーバーにおいて管理するデータ量が大きくなり、検索時間が長くなってしまうという問題もあった。

また、Ｐ２Ｐ型のファイル管理方法では、ファイルの管理は参加しているホストによって分散して行なっているため、ＳＰＯＦの無い完全分散型として管理されるものの、ここでのファイル管理とはファイル名からファイルの保存先サーバーを検索するという単純な管理のみであり、従来のローカルファイルシステムがもつディレクトリ管理やファイルの情報を管理する方法はなかった。

さらに、従来のローカルファイルシステムではＯＳによりファイルを複数のレコードで扱うものもあり、ＯＳごとに異なるファイルシステムを用いる必要があったため、分散ファイルシステムでは対応が難しかった。

本発明は、このような事情を考慮してなされたもので、その目的は、ネットワークを介して接続された複数のストレージサーバー装置から構成される分散ファイル管理システムにおいて、ファイルやディレクトリを、特定のストレージサーバー装置において一元的に管理することなく、分散して管理することができるストレージサーバー装置及びコンピュータプログラムを提供することにある。

［１］ 本発明の一態様は、他のストレージサーバー装置と協同して、データファイルおよびディレクトリファイルを含むファイルを分散管理するストレージサーバー装置であって、配下のディレクトリ名とディレクトリファイルのファイル名との対応関係、および、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係に関する管理情報を含む前記ディレクトリファイルと、前記データファイルと、を記憶するファイル蓄積部と、ファイル名とファイルを記憶するストレージサーバー装置とを対応付けるテーブルを記憶する所在管理テーブル蓄積部と、当該ストレージサーバー装置が所在を管理する前記ファイルについて、指定されるファイル名に基づいて前記テーブルを参照することにより、前記ファイルを記憶するストレージサーバー装置を特定する所在検索部と、指定されたファイル名に基づいて前記ファイルの所在を管理するストレージサーバー装置を選択し、選択されたストレージサーバー装置の前記所在検索部に対して前記ファイルを記憶するストレージサーバー装置の特定を指示する検索インタフェース部と、ファイル名の指定に基づき前記ファイル蓄積部が記憶する前記ファイルに対する操作を行なう低レベルインタフェース部と、ファイル名を指定して前記ファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示し、特定されたストレージサーバー装置の前記低レベルインタフェース部に対してファイル名を指定した読出指示を行うことによって前記ディレクトリファイルを読み出し、読み出した前記ディレクトリファイル内の前記管理情報に基づいて、指定されたディレクトリ名またはユーザ利用ファイル名に対応するファイル名を取得するとともに、取得したファイル名が配下のディレクトリファイルのファイル名である場合には取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置から再帰的にディレクトリファイルの読み出しを行い、取得したファイル名が配下のデータファイルのファイル名である場合には取得した前記ファイル名を出力するパス検索部と、指定されたディレクトリ名およびユーザ利用ファイル名を用いて前記パス検索部から前記データファイルのファイル名を取得し、取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置の前記低レベルインタフェース部に操作指示を行う高レベルインタフェース部と、を備えることを特徴とするストレージサーバー装置である。
この発明によれば、データファイルとディレクトリファイルを複数のストレージサーバー装置からなる分散ファイル管理システム内で分散して記憶し、ストレージサーバー装置の高レベルインタフェース部が、ディレクトリ名及びユーザ利用ファイル名によるファイル操作指示を受信した場合、パス検索部が、ディレクトリファイルを参照してユーザ利用ファイル名に対応したデータファイル名を取得する。高レベルインタフェース部は、取得されたデータファイル名を用いたファイル操作指示を低レベルインタフェース部へ出力し、低レベルインタフェース部は、ファイル蓄積部に記憶されている当該データファイル名のデータファイルに対するファイル操作を行なう。データファイルの所在は、予め分散ファイル管理システム内に登録しておいた、ファイル名と、ストレージサーバー装置との対応を示すテーブルから取得する。
これにより、分散ファイル管理システムを構成する複数のストレージサーバー装置によって、ファイルおよびディレクトリの分散管理が可能となり、多数のファイルおよびディレクトリを一元的に管理するサーバーが不要である。従って、多数のユーザから同時にファイルへのアクセスがあった場合でも特定のストレージサーバー装置に負荷が集中することがなく、また、多くのファイルやディレクトリが作成された場合でも、各ストレージサーバー装置が管理するファイルは少なくてよいため、ファイルの検索に要する時間が長くならないようにすることができる。

［２］ 本発明の一態様は、上述するストレージサーバー装置であって、前記ファイル蓄積部は、ディレクトリファイルまたはデータファイルのファイル名を含むｉノードファイルを更に記憶し、前記ディレクトリファイル内の前記管理情報は、配下のディレクトリの前記ディレクトリ名または配下のデータファイルの前記ユーザ利用ファイル名と、対応する前記ｉノードファイルのファイル名との対応関係を含むものであり、前記パス検索部は、読み出した前記ディレクトリファイルから、指定された前記ディレクトリ名または前記ユーザ利用ファイル名に基づいて前記ｉノードファイルのファイル名を取得し、取得した前記ファイル名を指定して前記ｉノードファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示するとともに、特定されたストレージサーバー装置の前記低レベルインタフェース部に対して前記ファイル名を指定した読出指示を行うことにより前記ｉノードファイルを読み出し、読み出した前記ｉノードファイルから前記ディレクトリファイルまたは前記データファイルの前記ファイル名を取得する、ことを特徴とする。
この発明によれば、ディレクトリファイルまたはデータファイルのファイル名を含むｉノードファイル、配下のディレクトリのディレクトリ名または配下のデータファイルのユーザ利用ファイル名と、対応するｉノードファイルのファイル名との対応関係を含むディレクトリファイル、及び、データファイルを、複数のストレージサーバー装置からなる分散ファイル管理システム内で分散して記憶し、ストレージサーバー装置の高レベルインタフェース部が、ディレクトリ名及びユーザ利用ファイル名によるファイル操作指示を受信した場合、パス検索部が、ｉノードファイル、及び、ディレクトリファイルを参照して、ユーザ利用ファイル名に対応したデータファイル名を取得する。
これにより、分散ファイル管理システムを構成する複数のストレージサーバー装置において、ｉノードファイル及びディレクトリファイルを用いて、ファイルおよびディレクトリを分散管理することが可能となる。

［３］ 本発明の一態様は、上述するストレージサーバー装置であって、読み出したファイルを記憶するキャッシュ蓄積部をさらに有し、前記パス検索部は、読み出した前記ｉノードファイルまたは前記ディレクトリファイルを前記キャッシュ蓄積部に書き込み、取得した前記ファイル名のｉノードファイルまたはディレクトリファイルが前記キャッシュ蓄積部に記憶されている場合は、当該ｉノードファイルまたはディレクトリファイルを当該キャッシュ蓄積部から読み出す、ことを特徴とする。
この発明によれば、一旦ダウンロードしたｉノードファイルやディレクトリファイルをキャッシュ蓄積部に記憶しておき、パス検索時に読み出しが必要となったｉノードファイルやディレクトリファイルがキャッシュ蓄積部に記憶されている場合は、その記憶されているファイルを使用する。
これにより、キャッシュ蓄積部に記憶したダウンロード済みファイルを利用し、パス検索部によるパス検索処理を高速にすることができる。

［４］ 本発明の一態様は、上述するストレージサーバー装置であって、前記ｉノードファイルは、複数に分割されたデータファイルのファイル名と、当該分割されたデータファイルの番号とを含み、前記ユーザ利用ファイル名には、前記分割されたデータファイルの番号が付加され、前記パス検索部は、指定された前記ユーザ利用ファイル名に基づいて読み出した前記ファイル名の前記ｉノードファイルから、前記データファイルの番号に対応したデータファイルのファイル名を出力する、ことを特徴とする。
この発明によれば、ユーザ利用ファイルを複数のデータファイルに分割して複数のストレージサーバー装置において分散して記憶しておき、この分割されたデータファイルのうちファイル操作の対象となるデータファイルのファイル名を特定する。
これにより、マルチレコード構造のファイルに対応した分散ファイル管理システムを提供することができる。

［５］ 本発明の一態様は、上述するストレージサーバー装置であって、前記ｉノードファイルは、メタデータを含み、前記ファイル入出力部は、前記操作がメタデータの読み出しである場合、読み出した前記ｉノードファイルから前記メタデータを読み出し、前記操作がメタデータの書き込みである場合、読み出した前記ｉノードファイルへメタデータの書き込みを行なう、ことを特徴とする。
この発明によれば、ｉノードファイルにディレクトリやユーザ利用ファイルに関する付加的な情報を示すメタデータ書き込んだり、ｉノードファイルに記述されたメタデータを読み出したりする。
これにより、ディレクトリ及びユーザ利用ファイルに任意のメタデータを追加して利用することができる。

［６］ 本発明の一態様は、他のストレージサーバー装置と協同して、データファイルおよびディレクトリファイルを含むファイルを分散管理するストレージサーバー装置として用いられるコンピュータを、配下のディレクトリ名とディレクトリファイルのファイル名との対応関係、および、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係に関する管理情報を含む前記ディレクトリファイルと、前記データファイルと、を記憶するファイル蓄積部、ファイル名とファイルを記憶するストレージサーバー装置とを対応付けるテーブルを記憶する所在管理テーブル蓄積部、当該ストレージサーバー装置が所在を管理する前記ファイルについて、指定されるファイル名に基づいて前記テーブルを参照することにより、前記ファイルを記憶するストレージサーバー装置を特定する所在検索部、指定されたファイル名に基づいて前記ファイルの所在を管理するストレージサーバー装置を選択し、選択されたストレージサーバー装置の前記所在検索部に対して前記ファイルを記憶するストレージサーバー装置の特定を指示する検索インタフェース部、ファイル名の指定に基づき前記ファイル蓄積部が記憶する前記ファイルに対する操作を行なう低レベルインタフェース部、ファイル名を指定して前記ファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示し、特定されたストレージサーバー装置の前記低レベルインタフェース部に対してファイル名を指定した読出指示を行うことによって前記ディレクトリファイルを読み出し、読み出した前記ディレクトリファイル内の前記管理情報に基づいて、指定されたディレクトリ名またはユーザ利用ファイル名に対応するファイル名を取得するとともに、取得したファイル名が配下のディレクトリファイルのファイル名である場合には取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置から再帰的にディレクトリファイルの読み出しを行い、取得したファイル名が配下のデータファイルのファイル名である場合には取得した前記ファイル名を出力するパス検索部、指定されたディレクトリ名およびユーザ利用ファイル名を用いて前記パス検索部から前記データファイルのファイル名を取得し、取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置の前記低レベルインタフェース部に操作指示を行う高レベルインタフェース部、として機能させることを特徴とするコンピュータプログラムである。
この発明によれば、データファイルとディレクトリファイルを複数のストレージサーバー装置からなる分散ファイル管理システム内で分散して記憶し、ストレージサーバー装置の高レベルインタフェース部が、ディレクトリ名及びユーザ利用ファイル名によるファイル操作指示を受信した場合、パス検索部が、ディレクトリファイルを参照してユーザ利用ファイル名に対応したデータファイル名を取得する。高レベルインタフェース部は、取得されたデータファイル名を用いたファイル操作指示を低レベルインタフェース部へ出力し、低レベルインタフェース部は、ファイル蓄積部に記憶されている当該データファイル名のデータファイルに対するファイル操作を行なう。データファイルの所在は、予め分散ファイル管理システム内に登録しておいた、ファイル名と、ストレージサーバー装置との対応を示すテーブルから取得する。
これにより、分散ファイル管理システムを構成する複数のストレージサーバー装置によって、ファイルおよびディレクトリの分散管理が可能となるり、多数のファイルおよびディレクトリを一元的に管理するサーバーが不要である。従って、多数のユーザから同時にファイルへのアクセスがあった場合でも特定のストレージサーバー装置に負荷が集中することがなく、また、多くのファイルやディレクトリが作成された場合でも、各ストレージサーバー装置が管理するファイルは少なくてよいため、ファイルの検索に要する時間が長くならないようにすることができる。

本発明によれば、ディレクトリやユーザ利用ファイルの管理情報をファイル化して複数のストレージサーバー装置に分散して保存し、ディレクトリ名及びユーザ利用ファイル名によって指定されたディレクトリ配下のファイルに対するファイル操作を行なうことができる。これにより、一元的に集中管理するサーバーを必要としないＰ２Ｐ型の分散ファイルシステムにおいて、ファイルの管理およびディレクトリの管理を実現することが可能となる。

本発明の第１の実施形態による分散ファイル管理システムのブロック図である。 第１の実施形態によるホストテーブル蓄積部３１に保存されるホストテーブルの例を示す図である。 第１の実施形態による所在管理テーブル蓄積部３３に保存されるキーテーブルの例を示す図である。 第１の実施形態によるｉノードファイル、ディレクトリファイル、データファイルの関係を示す図である。 第１の実施形態によるｉノードファイルのＸＭＬタグの一覧を示す図である。 第１の実施形態によるディレクトリファイルのＸＭＬタグの一覧を示す図である。 第１の実施形態による登録インタフェース部２１におけるput(key, value)関数実行処理の流れ図である。 第１の実施形態によるファイル登録部３におけるファイル登録処理の流れ図である。 第１の実施形態による検索インタフェース部２２におけるget(key)関数実行処理の流れ図である。 第１の実施形態による低レベルインタフェース部２３において実行されるインタフェース関数の一覧である。 第１の実施形態による高レベルインタフェース部２４において実行されるインタフェース関数の一覧である。 第１の実施形態によるhi_read関数実行処理の流れ図である。 第１の実施形態によるパス検索部５におけるパス検索処理の流れ図である。 第１の実施形態によるパス検索部５におけるファイルのダウンロード処理の流れ図である。 第１の実施形態によるhi_write関数実行処理の流れ図である。 第１の実施形態によるファイル生成削除部６におけるファイル作成処理の流れ図である。 第１の実施形態によるファイルアップロード処理の流れ図である。 第１の実施形態によるファイル生成削除部６におけるファイル削除処理の流れ図である。 第１の実施形態によるファイル生成削除部６におけるｉノードファイル削除処理の流れ図である。 第１の実施形態によるファイル生成削除部６におけるディレクトリ作成処理の流れ図である。 第１の実施形態によるファイル生成削除部６におけるディレクトリ削除処理の流れ図である。 第２の実施形態による分散ファイル管理システムのブロック図である。 第２の実施形態によるキーテーブルの構成を示す図である。 第２の実施形態によるput（key, value）関数のパラメータ構造を示す図である。 第２の実施形態によるlow_write関数実行処理の流れ図である。 第２の実施形態によるファイルのダウンロード処理の流れ図である。 第３の実施形態によるｉノードファイルの記述例を示す図である。 第３の実施形態による高レベルインタフェース部２４において実行されるhi_read関数およびhi_write関数を示す図である。 第４の同実施形態によるｉノードファイルの記述例を示す図である。 第４の実施形態による高レベルインタフェース部２４の追加関数の一覧を示す図である。 第４の実施形態によるhi_read_param関数実行動作の流れ図である。 第４の実施形態によるhi_write_param関数実行処理の流れ図である。 従来技術のiノードによるファイル管理を説明する図である。 従来技術のＧＦＳにおけるファイル管理を説明する図である。 従来技術のＰ２Ｐ方式におけるコンテンツの分散管理を説明する図である。

以下、図面を参照しながら本発明の実施形態を詳細に説明する。

［１． 第１の実施形態］
［１．１ 構成］
図１は、本発明の第１の実施形態による分散ファイル管理システムのブロック図であり、本発明と関係する機能ブロックのみ抽出して示している。同図に示すように、第１の実施形態による分散ファイル管理システムは、複数のストレージサーバー装置１を、ネットワーク装置１００に接続することにより構成されている。ネットワーク装置１００は、例えば、ルータなどの通信装置やケーブルなどの通信線からなり、ＩＰ（Internet Protocol）による通信ネットワークを構成する。ネットワーク装置１００にはさらに、ユーザ端末装置５０が接続されており、分散ファイル管理システムは、複数のサーバー装置１に記憶されているファイルの共有利用をユーザ端末装置５０へ提供する。

また、第１の実施形態による分散ファイル管理システムは、ネットワークを介して接続される複数のストレージサーバー装置１により、ＤＨＴ（分散ハッシュテーブル、Distributed Hash Table）を用いたＰ２Ｐ（Peer-to-Peer）型のオーバーレイネットワークを実現し、各ストレージサーバー装置１に記憶されているファイル、及び、分散ファイル管理システム全体に共通したディレクトリの管理を、当該オーバーレイネットワークに参加しているストレージサーバー装置１で分散して行なう。これにより、第１の実施形態では、ユーザ端末装置５０から、分散ファイル管理システム全体で共通のディレクトリ構造により、複数のストレージサーバー装置１に分散して記憶されているファイルへのアクセスが可能である。
なお、ＤＨＴを用いたＰ２Ｐ型のオーバーレイネットワークの構成方法として複数の方法が考案されているが、ここではOneHop方式を用いるものとして説明を行う。OneHop方式では、従来技術における図３５で示したように、ストレージサーバー装置１により円形のオーバーレイネットワークを構成する。これは、例えば、（文献）Ａ．Ｇｕｐｔａ， Ｂ．Ｌｉｓｋｏｖ ａｎｄ Ｒ．Ｒｏｄｒｉｇｕｅｓ， “Ｏｎｅ Ｈｏｐ Ｌｏｏｋｕｐｓ ｆｏｒ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｏｖｅｒｌａｙｓ，” ９ｔｈ Ｗｏｒｋｓｈｏｐ ｏｎ Ｈｏｔ Ｔｏｐｉｃｓ ｉｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ(ＨｏｔＯＳ−ＩＸ)， ２００３に記載されている。

図１において、ストレージサーバー装置１は、外部インタフェース部２、ファイル登録部３、ファイル入出力部４、パス検索部５、ファイル生成削除部６、サーバー選択部７、ＩＤ（識別子）生成部８、所在検索部９、ホストテーブル蓄積部３１、ファイル蓄積部３２、所在管理テーブル蓄積部３３、及び、記憶部３４を含んで構成される。

ホストテーブル蓄積部３１、ファイル蓄積部３２、所在管理テーブル蓄積部３３及び記憶部３４は、ハードディスク装置や半導体メモリなどで実現される。
ホストテーブル蓄積部３１は、ストレージサーバー装置１を特定するノードＩＤと、当該ストレージサーバー装置１のアドレスとの対応付けを示すホストテーブルを記憶する。

ファイル蓄積部３２は、ユーザがユーザ端末装置５０により生成し、読み書きするファイル（以下、「ユーザ利用ファイル」と記載）のデータ本体をデータファイルとして記憶する。さらに、ファイル蓄積部３２は、ユーザがユーザ端末装置５０により生成し、利用するディレクトリについての管理データをディレクトリファイルとして記憶する。これらのデータファイルおよびディレクトリファイルそれぞれに対して、ｉノードファイルが１つ生成され、ファイル蓄積部３２は、このｉノードファイルも記憶している。ｉノードファイル、ディレクトリファイル、データファイルのファイル名は、ＩＤ生成部８により生成されたＩＤに基づくファイル名であり、オーバーレイネットワーク内で使用するファイル名である。ユーザ端末装置５０により生成されたユーザ利用ファイルやディレクトリの名前は、当該ユーザ利用ファイルやディレクトリを配下に含むディレクトリのディレクトリファイル内に記述される。以下では、ファイル蓄積部３２に記憶されているｉノードファイル、データファイル、ディレクトリファイルのファイル名、つまり、オーバーレイネットワーク内で使用するファイル名を単に「ファイル名」と記載する。

所在管理テーブル蓄積部３３は、key（キー）とvalue（値）との対応付けを示すキーテーブルを記憶する。keyは、ファイル名のハッシュ値であり、ファイルを一意に特定するファイルＩＤを示す。valueはサーバーアドレスであり、keyの生成元となったファイル名のファイルを記憶しているストレージサーバー装置１のアドレスを示す。
記憶部３４は、作成あるいは修正途中のファイルなどを一時的に記憶する。

外部インタフェース部２は、ネットワーク装置１００を介して、他のストレージサーバー装置１およびユーザ端末装置５０と情報を送受信する。外部インタフェース部２は、登録インタフェース部２１、検索インタフェース部２２、低レベルインタフェース部２３、及び、高レベルインタフェース部２４を備える。

登録インタフェース部２１は、オーバーレイネットワークに、つまり、keyを管理すべきストレージサーバー装置１が保持するキーテーブルに、keyとvalueの対応付けを登録する。検索インタフェース部２２は、keyを管理しているストレージサーバー装置１の所在検索部９に、当該keyに対応したvalueの取得を指示する。

低レベルインタフェース部２３は、指定されたファイル名のファイルに対する操作、すなわち、ファイルの読み出し、書き込み及び削除を行なうための他のストレージサーバー装置１へのインタフェースを実現する。ここで指定されるファイル名は、オーバーレイネットワーク内で使用するファイル名である。また、低レベルインタフェース部２３は、ネットワーク内で一意のＩＤを生成すためのインタフェースを実現する。

高レベルインタフェース部２４は、ルートディレクトリからパスにより指定された名前のユーザ利用ファイルやディレクトリに対する操作、すなわち、ユーザ利用ファイルの読み出し、書き込みまたは削除、あるいは、ディレクトリの作成または削除を行なうためのユーザ端末装置５０及び他のストレージサーバー装置１へのインタフェースを実現する。ここで指定されるユーザ利用ファイル名やディレクトリ名は、ユーザが付与した名前である。なお、ディレクトリ名とは、階層構造の中のある階層におけるディレクトリに対して与えられる名前である。以下、ルートディレクトリからのパスにより指定されたユーザ利用ファイルのファイル名を「パス付きユーザ利用ファイル名」、ルートディレクトリからのパスにより指定されたディレクトリ名を「パス付きディレクトリ名」と記載する。

ファイル登録部３は、自ストレージサーバー装置１が備えるファイル蓄積部３２に記憶されているファイルのファイル名を取得し、当該ファイル名のハッシュ値であるkeyと、サーバーアドレスとして自ストレージサーバー装置１のアドレスを設定したvalueとの対応付けをオーバーレイネットワークへ登録するよう、登録インタフェース部２１に指示する。所在検索部９は、検索インタフェース部２２からkeyを受信し、自ストレージサーバー装置１が備える所在管理テーブル蓄積部３３に記憶されているキーテーブルから当該keyに対応するvalueを取得する。

ファイル入出力部４は、ファイル蓄積部３２に記憶されているファイルに対する書き込み、読み出し、あるいは、削除を行なう。パス検索部５は、パス付きユーザ利用ファイル名に対応したデータファイルのファイル名を検索したり、パス付きディレクトリ名に対応したディレクトリファイルを取得したりする。ファイル生成削除部６は、ｉノードファイル、ディレクトリファイル、データファイル等の各ファイルを生成または修正して自ストレージサーバー装置１または他のストレージサーバー装置１のファイル蓄積部３２への書き込みを指示したり、自ストレージサーバー装置１または他のストレージサーバー装置１のファイル蓄積部３２に記憶されているファイルの削除を指示したりする。サーバー選択部７は、ファイルを記憶させるべきストレージサーバー装置１を選択する。ＩＤ生成部８は、オーバーレイネットワーク内で一意のＩＤを生成する。

［１．２ データ構成］
次に、ストレージサーバー装置１に記憶されている各データについて説明する。
図２は、ストレージサーバー装置１のホストテーブル蓄積部３１に記憶されているホストテーブルの例を示す図である。ホストテーブルには、ストレージサーバー装置１のノードＩＤと、当該ストレージサーバー装置１のアドレスであるサーバーアドレスとを対応付けたレコードが、ノードＩＤの小さい順に並んだリストとして保管されている。このノードＩＤは、ネットワーク装置１００に接続されているストレージサーバー装置１のＩＰ（Internet Protocol）アドレス及びポート番号を元にハッシュ関数を用いて生成したハッシュ値である。同図においては、４台のストレージサーバー装置１であるサーバーＡ、Ｂ、Ｃ，Ｄがネットワーク装置１００を介して接続されており、そのノードＩＤをnodeID:A, nodeID:B, nodeID:C, nodeID:Dとした場合の例を示しており、ノードＩＤの値はnodeID:A＜nodeID:C＜nodeID:D＜nodeID:Bである。同図に示すホストテーブルは、図３５に示す円形のオーバーレイネットワークに対応している。以下、ストレージサーバー装置１を単に「サーバー」と記述する場合がある。

OneHop方式では、オーバーレイネットワークに参加している各サーバーは、当該オーバーレイネットワークに参加している全てのサーバーのホストリストを共通に持っている。従って、第１の実施形態の各ストレージサーバー装置１が記憶しているホストテーブルには、ネットワーク装置１００を介して接続される全てのストレージサーバー装置１のレコードが登録される。なお、ホストテーブルの作成方法、サーバーの参加や離脱によるホストテーブルの変更は、既存の技術と同様であるため、ここでは説明を省略する。
以下、参加しているすべてのストレージサーバー装置１のホストテーブル蓄積部３１には、正しく同じホストテーブルが記憶されているものとして説明を続ける。

図３は、ストレージサーバー装置１の所在管理テーブル蓄積部３３に記憶されているキーテーブルの例を示す図である。同図に示すように、キーテーブルには、ファイル名のハッシュ値を示すkeyと、当該ファイル名のファイルを記憶しているストレージサーバー装置１のアドレスを示すvalueと、keyとvalueの組の登録日時とを対応づけた複数のレコードからなる。

図４は、ストレージサーバー装置１のファイル蓄積部３２に記憶されているｉノードファイル、ディレクトリファイル、データファイルの関係を示す図である。第１の実施形態では個々のｉノードファイル、ディレクトリファイル、データファイルには、複数のストレージサーバー装置１で構成される分散ファイル管理システム内で唯一のファイル名が付与され、いずれかのストレージサーバー装置１のファイル蓄積装置３２内に記憶されている。

同図において、ファイル名が「00000.ino」、「B.ino」、「C.ino」、「F.ino」、「G.ino」のファイルはｉノードファイルであり、ファイル名が「00000.dir」、「C.dir」のファイルはディレクトリファイルであり、ファイル名が「B.dat」、「F.dat」、「G.dat」のファイルはデータファイルである。なお、ルートディレクトリのｉノードファイルをルートｉノードファイルと呼び、このファイル名は固定であらかじめ付与される。ここでは、ルートｉノードファイルのファイル名を「00000.ino」としている。ｉノードファイルおよびディレクトリファイル内のデータはＸＭＬ（extensible markup language）により記述される。以下、ファイル名「Ｘ」のファイルをファイル「Ｘ」と記載する。

図５は、ｉノードファイルのＸＭＬのタグの一覧を示す図である。
同図に示すように、ｉノードファイルの<inode>タグは、ｉノードファイルのＸＭＬの開始を表している。
<type>タグは、要素内容に、ｉノードファイルが示すファイルのタイプ、すなわち、ディレクトリファイルか、データファイルかが記述されることを表す。ディレクトリファイルの場合は「directory」が、データファイルの場合は「normal」が<type>タグの要素内容として記述される。
<body>タグは、要素内容に、ｉノードファイルが紐付けするディレクトリファイルまたはデータファイルのファイル名が記述されることを表す。ここでのファイル名はファイル蓄積部３２で記憶されているファイル名である。

図６は、ディレクトリファイルのＸＭＬのタグの一覧を示す図である。
同図に示すように、ディレクトリファイルの<dir_entry>タグは、ディレクトリファイルのＸＭＬの開始を表している。
<entry>タグは、属性値noにより特定される番号のディレクトリエントリの開始を表す。
<body>タグは、要素内容に、当該<body>タグが含まれるディレクトリエントリに対応したファイル名が記述されることを表す。ここでのファイル名は、当該ディレクトリファイルが対応するディレクトリを親ディレクトリとする配下のファイルまたはディレクトリのｉノードファイルのファイル名である。
<name>タグは、要素内容に、当該<name>タグが含まれるディレクトリエントリに対応した、配下のファイルのユーザ利用ファイル名、または、配下のディレクトリのディレクトリ名が記述されることを示す。

上記のように、ディレクトリファイルは、配下のディレクトリのディレクトリ名とディレクトリファイルのファイル名との対応関係、及び、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係を管理情報として含むものである。つまり、配下のディレクトリのディレクトリ名とディレクトリファイルのファイル名との対応関係とは、配下のディレクトリのディレクトリ名とディレクトリファイルのファイル名が記述されたｉノードファイルのファイル名との対応付けであり、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係とは、配下のユーザ利用ファイル名とデータファイルのファイル名が記述されたｉノードファイルのファイル名との対応付けである。

図４において、ルートｉノードファイル「00000.ino」のＸＭＬデータにおける<body>タグの要素内容から、ルートディレクトリのディレクトリファイルのファイル名は「00000.dir」であることがわかる。このディレクトリファイル「00000.dir」のＸＭＬデータに記述されている<dir_entry>タグの要素内容から、このディレクトリには４つのディレクトリエントリがあり、各ディレクトリエントリの<name>タグの要素内容から、１番目（no=”0”）のディレクトリエントリの名前は「.」、２番目のディレクトリエントリ（no=”1”）の名前は「..」、３番目のディレクトリエントリ（no=”2”）の名前は「test.mxf」、４番目のディレクトリエントリ（no=”3”）の名前は「work」であることがわかる。ここで、名前「．」はカレントディレクトリ（現在のディレクトリ）、「..」は親のディレクトリを示す。

そして、３番目のディレクトリエントリ（no=”2”）の<body>タグの要素内容から、ユーザ付与した名前「test.mxf」のｉノードファイル名は「B.ino」であり、ｉノードファイル「B.ino」の<type>タグの要素内容が「normal」であることから、<body>タグにはデータ本体を記述したデータファイルのファイル名が記述されており、その要素内容からファイル名は「B.dat」であることがわかる。
また、４番目のディレクトリエントリ（no=”3”）の<body>タグの要素内容から、ユーザが付与した名前「work」のｉノードファイル名は「C.ino」であり、そのｉノードファイル「C.ino」の<type>タグの要素内容が「directory」であることから、<body>タグにはディレクトリファイル名が記述されており、その要素内容からファイル名は「C.dir」であることがわかる。

また、ディレクトリファイル「C.dir」のＸＭＬデータに記述されている<dir_entry>タグの要素内容から、このディレクトリには４つのディレクトリエントリがあり、各ディレクトリエントリの<name>タグの要素内容から、１番目（no=”0”）のディレクトリエントリの名前は「.」、２番目のディレクトリエントリ（no=”1”）の名前は「..」、３番目のディレクトリエントリ（no=”2”）の名前は「fish.mxf」、４番目のディレクトリエントリ（no=”3”）の名前は「cat.mxf」であることがわかる。

そして、３番目のディレクトリエントリ（no=”2”）の<body>タグの要素内容から、ユーザが付与した名前「fish.mxf」のｉノードファイル名は「F.ino」であり、そのｉノードファイル「F.ino」の<type>タグの要素内容が「normal」であることから、<body>タグにはデータ本体を記述したデータファイルのファイル名が記述されており、その要素内容からファイル名は「F.dat」であることがわかる。
同様に、４番目のディレクトリエントリ（no=”3”）の<body>タグの要素内容から、ユーザが付与した名前「cat.mxf」のｉノードファイル名は「G.ino」であり、そのｉノードファイル「G.ino」の<type>タグの要素内容が「normal」であることから、<body>タグにはデータ本体を記述したデータファイルのファイル名が記述されており、その要素内容からファイル名は「G.dat」であることがわかる。

以上説明したように、本実施形態では、ルートｉノードファイル「00000.ino」から、所望のディレクトリファイルおよびデータファイルを見つけ出すことができる。

［１．３ ストレージサーバー装置１の動作］
次に、ストレージサーバー装置１の処理について説明する。

［１．３．１ keyの登録］
まず、登録インタフェース部２１において実行される登録（put）インタフェースについて説明する。登録インタフェースは、オーバーレイネットワークに、指定されたファイルの所在を登録するためのインタフェースである。
つまり、登録インタフェース部２１は、自ストレージサーバー装置１の他の処理部から、または、他のストレージサーバー装置１から実行要求を受け、put(key, value)関数を実行する。関数とは、他のプログラムモジュールから呼び出され、当該他のプログラムモジュールから引数と呼ばれるデータを受信して一連の命令群からなる処理を実行し、その実行結果のデータを引数として当該関数の呼び出し元へ返すプログラムモジュールである。なお、関数には、呼び出し元が設定する引数や、呼び出し元へ返す引数がないものもある。
登録インタフェース部２１がput(key, value)関数を実行することにより、パラメータとして指定されたkeyとvalueの組（以下、keyとvalueの組を(key, value)とも記載）をオーバーレイネットワークに登録することができる。オーバーレイネットワークに(key, value)を登録するとは、keyを管理すべき適切なストレージサーバー装置１のキーテーブルに、(key, value)を登録するということである。

図７は、登録インタフェース部２１によるput(key, value)関数実行処理の流れ図を示す。同図において、登録インタフェース部２１は、put(key, value)関数の実行要求を受信すると、ホストテーブル蓄積部３１のホストテーブルを参照して、時計周りの方向でkeyの値に近いノードＩＤのうち、当該keyの値に最も近いノードＩＤを特定し、この特定したノードＩＤに対応したサーバーアドレスを読み出す（ステップＳ７−１）。

登録インタフェース部２１は、ステップＳ７−１における検索の結果得られたサーバーアドレスが、自ストレージサーバー装置１のアドレスであるか否かを判断する（ステップＳ７−２）。読み出したサーバーアドレスが、自ストレージサーバー装置１のアドレスである場合（ステップＳ７−２：ＹＥＳ）、登録インタフェース部２１は、所在管理テーブル蓄積部３３に記憶されているキーテーブルに新規レコードを追加し、この追加したレコードに受信したパラメータで示される(key, value)値を書き込む（ステップＳ７−３）。さらに、登録インタフェース部２１は、この追加したレコードに、現在の日時を示す登録日時を書き込む。

一方、ステップＳ７−２において、読み出したサーバーアドレスが、自ストレージサーバー装置１のアドレスではない場合、すなわち、keyを管理すべきサーバーが自ストレージサーバー装置１ではない場合（ステップＳ７−２：ＮＯ）、登録インタフェース部２１は、読み出したサーバーアドレスを宛先として用いて、他のトレージサーバー装置１へput(key, value)関数の実行要求を出力する（ステップＳ７−４）。

これにより、put(key, value)関数の実行要求を受信した他のストレージサーバー装置１の登録インタフェース部２１において、put(key, value)関数が実行され、上述したステップＳ７−１からの処理が行なわれる。ただし、この場合、ステップＳ７−１において、当該他のストレージサーバー装置１のアドレスが読み出されることになるため、当該他のストレージサーバー装置１の所在管理テーブル蓄積部３３が記憶しているキーテーブルに、(key, value)値、及び、登録日時を設定したレコードが追加される。

以上の動作により、オーバーレイネットワーク上に(key, value)値が登録される。
なお、キーテーブルに登録されている(key, value)値が一定時間後になっても再登録されない場合、キーテーブルから削除する。つまり、登録インタフェース部２１は、一定時間毎に、所定の時間を経過した登録日時が設定されているキーテーブルのレコードを検出し、検出したレコードを削除する。

［１．３．２ 蓄積ファイルの所在登録］
次に、ファイル登録部３において実行されるファイル登録手順の動作について説明する。
ファイル登録部３は、自ストレージサーバー装置１のファイル蓄積部３２に記憶されているファイルに使用されているファイル名のハッシュ値をkeyとし、自ストレージサーバー装置１のアドレスをvalueとして、登録インタフェース部２１に登録インタフェースを実行させ、オーバーレイネットワークへ自ストレージサーバー装置１が保持するファイルの所在を登録する。

図８は、ファイル登録部３におけるファイル登録処理の流れ図を示す。
まず、ファイル登録部３はファイル蓄積部３２に記憶されているファイル数Ｎを取得する（ステップＳ８−１）。次に、ファイル登録部３は、カウンタ値ｎを０にセットし（ステップＳ８−２）、以下のステップＳ８−４〜Ｓ８−６の操作をｎがＮに達するまで、Ｎ回繰り返す（ステップＳ８−３：ＹＥＳ）。

すなわち、ファイル登録部３は、ｎ番目のファイルのファイル名のハッシュ値をkeyに、自ストレージサーバー装置１のアドレスをvalueにセットし（ステップＳ８−４）、登録インタフェース部２１にput(key, value)関数の実行要求を出力する（ステップＳ８−５）。これにより、登録インタフェース部２１は、図７に示すput(key, value)関数の処理を実行し、オーバーレイネットワークへ(key, value）値を登録する。ファイル登録部３は、ｎの値を１加算した値に更新する（ステップＳ８−６）。

ｎがファイル数Ｎに達し、ファイル蓄積部３２内のＮ個の全ファイルについて、ステップＳ８−３〜Ｓ８−６を行い、(key, value)の登録を終了すると（ステップＳ８−３：ＮＯ）、ファイル登録部３は、あらかじめ決めた時間Ｔだけ待った後（ステップＳ８−７）、再びステップＳ８−１からの処理を行い、登録動作を繰り返す。

以上により、ストレージサーバー装置１は、自身が備えるファイル蓄積部３２に記憶されているｉノードファイル、ディレクトリファイル、データファイル等の全てのファイルの所在を定期的にオーバーレイネットワークに登録する。

［１．３．３ ファイルの所在検索］
次に、オーバーレイネットワークに登録されている(key, value)を取得する検索(get）インタフェースについて説明する。検索インタフェース部２２は、自ストレージサーバー装置１の他の処理部から、または、他のストレージサーバー装置１からの実行要求を受け、get(key)関数を実行する。get(key)関数は、指定されたkeyに対応するvalue値を検索するインタフェースである。

図９は、検索インタフェース部２２におけるget(key)関数実行処理の流れ図を示す。
検索インタフェース部２２は、get(key)関数の実行要求を受け付けると、ホストテーブル蓄積部３１に記憶されているホストテーブルを参照して、受信したkeyの値に時計周りで近いノードＩＤのうち、当該keyの値に最も近いノードＩＤを特定し、この特定したノードＩＤに対応したサーバーアドレスを読み出す（ステップＳ９−１）。

検索インタフェース部２２は、ステップＳ９−１における検索の結果得られたサーバーアドレスが、自ストレージサーバー装置１のアドレスであるか否かを判断する（ステップＳ９−２）。読み出したサーバーアドレスが、自ストレージサーバー装置１のアドレスであると判断した場合（ステップＳ９−２：ＹＥＳ）、検索インタフェース部２２は、自ストレージサーバー装置１の所在検索部９へステップＳ９−１において受信したkeyを出力し、valueの読み出しを指示する。所在検索部９は、所在管理テーブル蓄積部３３に記憶されているキーテーブルから、受信したkeyに対応するvalue値を読み出す。検索インタフェース部２２は、所在検索部９により読み出されたvalue値をget(key)関数の実行要求元へ出力する（ステップＳ９−３）。

一方、ステップＳ９−２において、読み出したサーバーアドレスが、自ストレージサーバー装置１のアドレスではないと判断した場合、すなわち、keyを管理すべきサーバーが他のストレージサーバー装置１であると判断した場合（ステップＳ９−２：ＮＯ）、検索インタフェース部２２は、読み出したサーバーアドレスを宛先として用い、他のストレージサーバー装置１へget(key)関数の実行要求を出力する（ステップＳ９−４）。

これにより、get(key)関数の実行要求を受信した他のストレージサーバー装置１の検索インタフェース部２２において、get(key)関数が実行され、上述したステップＳ９−１からの処理が行なわれる。ただし、この場合、ステップＳ９−１において、当該他のストレージサーバー装置１のアドレスが読み出されることになる。よって、他のストレージサーバー装置１の所在検索部９により、当該他のストレージサーバー装置１の所在管理テーブル蓄積部３３が記憶しているキーテーブルからkeyに対応したvalue値が読み出され、当該他のストレージサーバー装置１の検索インタフェース部２２により、get(key)関数の実行要求を出力したストレージサーバー装置１へ出力されることになる。他のストレージサーバー装置１からvalue値を受信したストレージサーバー装置１は、get(key)関数の実行要求元へ当該value値を出力する。

以上により、オーバーレイネットワークで管理されている(key, value)を取得する、すなわち、ファイル名からそのファイルを記憶しているストレージサーバー装置１のアドレスを検索することができる。

［１．３．４ オーバーレイネットワークで使用されるファイル名によるファイル操作］
オーバーレイネットワークで使用されるファイル名、つまり、ファイル蓄積部３２に記憶されているファイルのファイル名によるファイル操作は、低レベルインタフェース部２３により実行される。

図１０は、低レベルインタフェース部２３において実行されるインタフェース関数を示す。低レベルインタフェース部２３で実行されるインタフェース関数は、ファイル蓄積部３２に記憶されているｉノードファイル、ディレクトリファイル、データファイルに対する操作を行なうものである。

同図に示すように、低レベルインタフェース部２３において実行される関数には、ファイルに対して、読み出し、書き込み、削除をそれぞれ行なうlow_read関数、low_write関数、low_delete関数がある。さらに、低レベルインタフェース部２３は、オーバーレイネットワークで一意のＩＤを生成するlow_create_id関数を実行する。それぞれの関数の引数の欄で示されるinは関数の呼び出し側が値を設定する引数、outは関数が呼び出された側が値を設定して呼び出し側に値を戻す引数である。引数fnameは、ファイル蓄積部３２において記憶されているファイルのファイル名である。
以下に、低レベルインタフェース２３における各関数の動作について順に説明する。

［１．３．４．１ low_read関数］
low_read関数は、ファイル蓄積部３２に記憶されているファイルからデータを読み出す関数である。引数fnameは、データ読み出し対象ファイルのファイル名を示す。引数offsetは、データの読み出しを行なう先頭位置を示し、ファイルの先頭からのバイト数が設定される。引数sizeは、読み出すデータのバイトサイズを示す。また、引数dataは、読み出されたデータを示す。

低レベルインタフェース部２３は、自ストレージサーバー装置１の各部または他のストレージサーバー装置１からlow_read関数の実行要求を受信すると、ファイル入出力部４へ受信した引数を出力し、ファイルからのデータ読み出しを指示する。ファイル入出力部４は、引数fnameで示されるファイル蓄積部３２内のファイルを特定すると、特定したファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を読み出し開始位置とし、この読み出し開始位置から引数offsetで示されるバイト数のデータを読み出す。低レベルインタフェース部２３は、ファイル入出力部４が読み出したデータを引数dataに設定して、low_read関数の実行要求元へ返送する。

［１．３．４．２ low_write関数］
low_write関数は、ファイル蓄積部３２に記憶されているファイルにデータを書き込む関数である。引数fnameは、データ書き込み対象ファイルのファイル名を示す。引数offsetは、データの書き込みを行なう先頭位置を示し、ファイルの先頭からのバイト数が設定される。引数sizeは、書き込むデータのバイトサイズを示す。また、引数dataは、ファイルに書き込むデータを示す。

低レベルインタフェース部２３は、自ストレージサーバー装置１の各部または他のストレージサーバー装置１からlow_write関数の実行要求を受信すると、ファイル入出力部４へ受信した引数を出力し、ファイルへのデータ書き込みを指示する。ファイル入出力部４は、引数fnameで示されるファイル蓄積部３２内のファイルを特定すると、特定したファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、引数dataで示されるデータを書き込む。

なお、引数fnameで指定されたファイルがファイル蓄積装置３２に存在しない場合、ファイル入出力部４は、引数fnameで指定された名前のファイルを新たにファイル蓄積装置３２に作成する。そして、作成したファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、引数dataで示されるデータを書き込む。

［１．３．４．３ low_delete関数］
low_delete関数は、ファイル蓄積装置３２に記憶されているファイルを削除する関数であり、引数fnameは、削除対象のファイル名を示す。低レベルインタフェース部２３は、自ストレージサーバー装置１の各部または他のストレージサーバー装置１からlow_delete関数の実行要求を受信すると、ファイル入出力部４へ受信した引数を出力し、ファイルの削除を指示する。ファイル入出力部４は、引数fnameで示されるファイル蓄積部３２内のファイルを特定すると、当該ファイルをファイル蓄積部３２から削除する。

［１．３．４．４ low_create_id関数］
low_create_id関数は、第１の実施形態における分散ファイル管理システム、つまり、オーバーレイネットワークにおいて、唯一であることを保証したＩＤを生成する関数である。
低レベルインタフェース部２３は、自ストレージサーバー装置１の各部または他のストレージサーバー装置１からlow_create_id関数の実行要求を受信すると、ＩＤ生成部８の生成を指示する。低レベルインタフェース部２３は、ＩＤ生成部８が生成したＩＤを引数idに設定してlow_create_id関数の実行要求元へ返送する。
なお、本実施形態におけるＩＤの生成方法は特に制限されるものではないが、例えば、ＳＭＰＴＥ（Society of Motion Picture and Television Engineers）-３３０ＭのＵＭＩＤ（Unique Material Identifier）や、ＲＦＣ（Request for Comments）４１２２のＵＵＩＤ(Universally Unique Identifier)などの既存の技術による生成方法を用いることができる。

［１．３．５ ユーザ利用ファイル名及びディレクトリ名による操作］
ユーザ利用ファイル名、ディレクトリ名による操作は、高レベルインタフェース部２４により実行される。
図１１は、高レベルインタフェース部２４において実行されるインタフェース関数を示す。高レベルインタフェース部２４で実行されるインタフェース関数は、ユーザ利用ファイル、あるいは、オーバーレイネットワークで管理されるディレクトリに対する操作を行なうものである。これらのインタフェース関数の実行要求は、ユーザ端末装置５０、あるいは、ストレージサーバー装置１から出力される。

同図に示すように、高レベルインタフェース部２４において実行される関数には、ルートディレクトリからのパスで記述されたパス付きユーザ利用ファイル名により示されるユーザ利用ファイルに対して、読み出し、書き込み、削除をそれぞれ行なうhi_read関数、hi_write関数、hi_delete関数がある。さらに、高レベルインタフェース部２４において実行される関数には、ルートディレクトリからのパスで記述されたパス付きディレクトリの作成、削除をそれぞれ行なうhi_make_dir関数、hi_delete_dir関数がある。それぞれの関数の引数の欄で示されるinは関数の呼び出し側が値を設定する引数、outは関数が呼び出された側が値を設定して呼び出し側に値を戻す引数である。なお、ディレクトリファイルの<name>タグの要素内容が、パス付きユーザ利用ファイル名、パス付きディレクトリ名に使用される。

hi_read関数の引数pathは、データ読み出し対象ファイルのパス付きユーザ利用ファイル名を示す。引数offsetは、データを読み出す先頭位置を示し、ファイルの先頭からのバイト数が設定される。引数sizeは、読み出すデータのバイトサイズを示す。また、引数dataは、読み出されたデータを示す。
hi_write関数の引数pathは、データ書き込み対象ファイルのパス付きユーザ利用ファイル名を示す。引数offsetは、書き込みを行なうデータの位置を示し、ファイルの先頭からのバイト数が設定される。引数sizeは、データの書き込み位置から書き込みを行なうデータのバイトサイズを示す。引数dataは、書き込むデータを示す。
hi_delete関数の引数pathは、削除対象ファイルのパス付きユーザ利用ファイル名を示す。
hi_make_dir関数の引数pathは、ルートディレクトリからのパスで示された、作成対象ディレクトリのパス付きディレクトリ名を示す。
hi_delete_dir関数の引数pathは、ルートディレクトリからのパスで示された、削除対象ディレクトリのパス付きディレクトリ名を示す。

引数pathは、例えば、「/usr」ディレクトリ内の「local」ディレクトリ内にある「sample.txt」というファイルであれば、「/usr/local/sample.txt」のようにパス付きユーザ利用ファイル名を指定することができる。「/usr」ディレクトリ内の「local」ディレクトリであれば、「/usr/local」のようにパス付きディレクトリ名を指定することができる。
以下に、高レベルインタフェース部２４における各関数の動作について順に説明する。

［１．３．５．１ hi_read関数］
［１．３．５．１．１ hi_read関数の動作］
図１２は、高レベルインタフェース部２４によるhi_read関数実行処理の流れ図を示す。
同図において、まず、高レベルインタフェース部２４は、引数pathにより指定された読み出し対象ユーザ利用ファイルがどのようなファイル名のデータファイルによってファイル蓄積部３２に記憶されているかを取得するため、パス検索の実行をパス検索部５に指示する（ステップＳ１２−１）。

例えば、図４に示すｉノードファイル、ディレクトリファイル、データファイルがオーバーレイネットワークに記憶されており、引数pathに「/work/fish.mxf」が設定さているものとする。この場合、高レベルインタフェース部２４は、ステップＳ１２−１におけるパス検索の結果、パス検索部５からデータファイル名「H.dat」を取得する。なお、パス検索の詳細は後述する。

次に、高レベルインタフェース部２４は、ステップＳ１２−１において取得したファイル名のファイルを記憶しているストレージサーバー装置１を検索するため、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１２−２）。keyには、ステップＳ１２−１において取得したファイル名のハッシュ値を設定する。検索インタフェース部２２は、図９に示す処理を行い、その実行結果として、ステップＳ１２−１で取得したファイル名のデータファイルが記憶されているストレージサーバー装置１のアドレスをvalue値として得、高レベルインタフェース部２２へ出力する。

次に、高レベルインタフェース部２４は、get(key)関数の実行結果として得られたvalue値で示されるサーバーアドレスを宛先としてlow_read関数の実行要求を出力する（ステップＳ１２−３）。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_read関数の実行要求を出力する。

このとき、low_read関数の引数fnameにはステップＳ１２−１において取得したファイル名が設定され、引数offset、sizeのそれぞれには、hi_read関数の引数offset、sizeが設定される。low_read関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、引数に基づいてlow_read関数を実行し、ファイル入出力部４からファイル蓄積部３２に記憶されているファイルから読み出されたデータを取得すると、取得したデータを引数dataに設定して、実行要求元のストレージサーバー装置１の高レベルインタフェース部２４へ出力する。高レベルインタフェース部２４は、受信した引数dataを、hi_write関数の実行要求元へ出力する。

以上の動作により、パス名から分散ファイル管理システムで管理されている実際のファイルのデータを読み出すことができる。

［１．３．５．１．２ パス検索の動作］
ここでは、パス検索部５におけるパス検索の動作について説明する。パス検索は、図４において説明した、第１の実施形態によるｉノードファイル、ディレクトリファイル、データファイルの関係に基づいて、パス付きユーザ利用ファイル名により指定されたユーザ利用ファイルのデータ本体が設定されているデータファイルのファイル名、つまり、ファイル蓄積部３２内のデータファイルに使用されている、オーバーレイネットワーク内でのファイル名を取得するものである。また、パス検索部５は、パス付きディレクトリ名により指定されたディレクトリのディレクトリファイルを取得する。

図１３は、パス検索部５によるパス検索処理の流れ図を示す。まず、パス検索部５は、パス解析をルートｉノードファイルから開始するため、ダウンロード対象ｉノードファイルのファイル名ＦＮに、ルートｉノードファイルのファイル名「00000.ino」を設定する（ステップＳ１３−１）。パス検索部５は、ファイル名ＦＮのｉノードファイルをダウンロードする（ステップＳ１３−２）。このファイルダウンロード処理の詳細は後述する。

パス検索部５は、ダウンロードしたｉノードファイルのＸＭＬデータを解析し、<body>タグの要素内容で示されるファイル名、および、<type>タグの要素内容で示されるファイルタイプを取得する（ステップＳ１３−３）。タイプが「normal」、すなわち、ディレクトリでない場合には（ステップＳ１３−４：ＮＯ）、<body>タグの要素内容から取得したファイル名が、パス付きユーザ利用ファイル名により特定されるデータファイルのファイル名であるので処理を終了する。

一方、タイプが「directory」の場合には（ステップＳ１３−４：ＹＥＳ）、<body>タグの要素内容から得られたファイル名はディレクトリファイルのファイル名であるため、パス検索部５は、後述するファイルダウンロード処理によって、当該ファイル名のディレクトリファイルをダウンロードする（ステップＳ１３−５）。

次に、パス検索部５は、ダウンロードしたディレクトリファイルのＸＭＬデータを解析し、<entry>タグで示されるディレクトリエントリの中から、<name>タグの要素内容に示されるファイル名が、パス付きユーザ利用ファイル名で示されるディレクトリ名またはファイル名に一致するものを検索する。一致するものがある場合（ステップＳ１３−６：ＹＥＳ）、そのディレクトリエントリの<body>タグの要素内容からｉノードファイル名を取得すると、ファイル名ＦＮに設定し（ステップＳ１３−７）、ステップＳ１３−２からの処理を繰り返し行う。このように、ルートディレクトリから順にパス付きユーザ利用ファイル名で指定されたパスを解析し、目的のファイルのファイル名を取得する。
なお、<name>タグの記述内容に示されるファイル名に、パス付きユーザ利用ファイル名で示されるディレクトリ名またはファイル名に一致するものがない場合（ステップＳ１３−６：ＮＯ）、処理を終了する。

［１．３．５．１．３ ファイルダウンロードの動作］
図１４は、パス検索部５によるファイルのダウンロード処理の流れ図である。同図において、まず、パス検索部５は、ダウンロード対象ファイルのファイル名のハッシュ値をkeyとし、検索インタフェース部２２へget(key)関数の実行要求を出力する。get(key)関数の実行要求を受信した検索インタフェース部２２は、図９に示す処理を行い、その実行結果として、value値として得、パス検索部５へ出力する。これにより、パス検索部５は、ダウンロード対象ファイルを記憶しているストレージサーバー装置１のアドレスを取得する（ステップＳ１４−１）。

次に、パス検索部５は、get(key)関数の実行結果として得られたvalue値で示されるサーバーアドレスを宛先としてlow_read関数の実行要求を出力する（ステップＳ１４−２）。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_read関数の実行要求を出力する。low_read関数の引数fnameにはダウンロード対象ファイルのファイル名が、引数offset、sizeには、ファイルの先頭から終了までの全体を読み出し対象とするための値が設定される。

low_read関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、引数に基づいてlow_read関数を実行し、ファイル入出力部４からファイル蓄積部３２に記憶されているファイルから読み出されたデータを取得すると、取得したデータを引数dataに設定して、実行要求元のストレージサーバー装置１のパス検索部５へ出力する。これにより、パス検索部５は、ダウンロード対象ファイルの全データを取得し、ダウンロード要求元へ出力する。

［１．３．５．１．４ hi_read関数の動作例］
分散ファイル管理システムに図４のファイルが分散して記憶されている場合の、hi_read関数実行処理の動作例を説明する。例えば、図１２において、高レベルインタフェース部２４が、引数pathにパス付きユーザ利用ファイル名「/work/fish.mxf」が設定されたhi_read関数の実行指示を受信したとする。高レベルインタフェース部２４は、パス検索部５へ引数pathとパス検索の実行指示とを出力する（ステップＳ１２−１）。

図１３において、パス付きユーザ利用ファイル名「/work/fish.mxf」のパス検索処理を行う場合、まず、パス検索部５は、ダウンロード対象としてルートｉノードファイル「00000.ino」を選択し（ステップＳ１３−１）、当該ルートｉノードファイルを記憶しているストレージサーバー装置１からダウンロードする（ステップＳ１３−２）。つまり、図１４において、パス検索部５は、keyにルートｉノードファイル名「00000.ino」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する。これにより、検索インタフェース部２２は、ルートｉノードファイルを記憶しているストレージサーバー装置１のサーバーアドレスを示すvalue値を取得し（ステップＳ１４−１）、当該value値が示すサーバーアドレスを宛先として、引数fnameにルートｉノードファイル名「00000.ino」を設定したlow_read関数の実行要求を出力する（ステップＳ１４−２）。

ダウンロードしたｉノードファイル「00000.ino」の<type>タグの要素内容には「directory」が設定されているため（ステップＳ１３−３、Ｓ１３−４：ＹＥＳ）、パス検索部５は、<body>タグの要素内容から取得したファイル名「00000.dir」のディレクトリファイルを、当該ディレクトリファイルを記憶しているストレージサーバー装置１からダウンロードする（ステップＳ１３−５）。つまり、図１４において、パス検索部５は、keyにディレクトリファイル名「00000.dir」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する。これにより、検索インタフェース部２２は、ディレクトリファイル「00000.dir」を記憶しているストレージサーバー装置１のサーバーアドレスを示すvalue値を取得し（ステップＳ１４−１）、当該value値が示すサーバーアドレスを宛先として、引数fnameにディレクトリファイル名「00000.dir」を設定したlow_read関数の実行要求を出力する（ステップＳ１４−２）。

パス検索部５は、ディレクトリファイル「00000.dir」から、パス付きユーザ利用ファイル名「/work/fish.mxf」におけるルート配下のディレクトリ名「work」が<name>タグの要素内容として記述されている「no="3"」のエントリを検出すると（ステップＳ１３−６：ＹＥＳ）、このディレクトリエントリの<body>タグの要素内容からｉノードファイル名「C.ino」を取得する（ステップＳ１３−７）。

パス検索部５は、ｉノードファイル「C.ino」を、当該ｉノードファイルを記憶しているストレージサーバー装置１からダウンロードする（ステップＳ１３−２）。ｉノードファイル「C.ino」の<type>タグの要素内容には「directory」が設定されているため（ステップＳ１３−３、Ｓ１３−４：ＹＥＳ）、パス検索部５は、<body>タグの要素内容から取得したファイル名「C.dir」のディレクトリファイルをダウンロードする（ステップＳ１３−５）。パス検索部５は、ディレクトリファイル「C.dir」から、パス付きユーザ利用ファイル名「/work/fish.mxf」で示される「work」配下のファイル名「fish.mxf」が<name>タグの要素内容に記述されている「no="2"」のエントリを検出すると（ステップＳ１３−６：ＹＥＳ）、このディレクトリエントリの<body>タグの要素内容からｉノードファイル名「F.ino」を取得する（ステップＳ１３−７）。

パス検索部５は、ｉノードファイル「F.ino」をダウンロードする（ステップＳ１３−２）。ｉノードファイル「F.ino」の<type>タグの要素内容には「normal」が設定されているため、パス検索部５は、<body>タグの要素内容から取得したファイル名「H.dat」を、パス付きユーザ利用ファイル名「/work/fish.mxf」のデータファイル名と判断し、処理を終了する（ステップＳ１３−３、Ｓ１３−４：ＮＯ）。

図１２において、高レベルインタフェース部２４は、keyにデータファイル名「H.dat」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する。これにより、検索インタフェース部２２は、データファイル「H.dat」を記憶しているストレージサーバー装置１のサーバーアドレスを示すvalue値を取得する（ステップＳ１２−２）。高レベルインタフェース部２４は、検索インタフェース部２２が取得したvalue値が示すサーバーアドレスを宛先として、引数fnameにデータファイル名「H.dat」を設定したlow_read関数の実行要求を出力し、データファイル「H.dat」から読み出されたデータを取得すると、hi_read関数の実行要求元へ出力する（ステップＳ１２−３）。

［１．３．５．２ hi_write関数］
［１．３．５．２．１ hi_write関数の動作］
hi_write関数はパス付きユーザ利用ファイル名で示されたユーザ利用ファイルへデータを書き込むインタフェースである。書き込み対象ユーザ利用ファイルがどのようなファイル名のデータファイルによってファイル蓄積部３２に記憶されているかを取得する手順はhi_read関数と基本的に同じであるが、ファイルが存在しない場合には、新規にファイルを作成する点が異なる。

図１５は、高レベルインタフェース部２４によるhi_write関数実行処理の流れ図である。
同図において、まず、高レベルインタフェース部２４は、引数pathにより指定された書き込み対象ユーザ利用ファイルがどのようなファイル名のデータファイルによってファイル蓄積部３２に記憶されているかを取得するため、パス検索部５へ引数pathとパス検索の実行指示とを出力する（ステップＳ１５−１）。これにより、パス検索部５は、図１３に示すパス検索処理を行う。パス検索の結果、データファイルのファイル名が取得できた場合、つまり、パス付きユーザ利用ファイル名で指定されたデータファイルが存在する場合（ステップＳ１５−２：ＮＯ）、高レベルインタフェース部２４は、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１５−３）。keyには、ステップＳ１５−１において取得したデータファイルのファイル名のハッシュ値を指定する。検索インタフェース部２２は、図９に示す処理を行い、その実行結果として、ステップＳ１５−１で取得したファイル名のデータファイルが記憶されているストレージサーバー装置１のアドレスをvalue値として得、高レベルインタフェース部２２へ出力する。

続いて、高レベルインタフェース部２４は、get(key)関数の実行結果として得られたvalue値で示されるサーバーアドレスを宛先としてlow_write関数の実行要求を出力する（ステップＳ１５−５）。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_write関数の実行要求を出力する。low_write関数の引数fnameにはステップＳ１５−１で取得したファイル名が、引数offset、size、dataのそれぞれには、hi_write関数の引数offset、size、dataが設定される。

一方、パス検索の結果、データファイルのファイル名が取得できなかった場合、つまり、パス付きユーザ利用ファイル名で指定されたファイルが存在しない場合（ステップＳ１５−２：ＹＥＳ）、後述するファイル作成処理をファイル生成削除部６に指示する（ステップＳ１５−４）。ファイル作成処理では、ユーザ利用ファイルのデータ本体を記述したデータファイル、当該データファイルに対応したｉノードファイルを適切なストレージサーバー装置１のファイル蓄積部３２に新規に登録するとともに、ユーザ利用ファイルが属するディレクトリのディレクトリファイルの更新を行なう。

ファイル作成処理を行なった後、高レベルインタフェース部２４は、ステップＳ１５−３において新たにデータファイルを生成したサーバーアドレスを宛先としてlow_write関数の実行要求を出力する（ステップＳ１５−５）。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_write関数の実行要求を出力する。low_write関数の引数fnameにはステップＳ１５−４で生成したデータファイルのファイル名が、引数offset、size、dataのそれぞれには、hi_write関数の引数offset、size、dataが設定される。

［１．３．５．２．２ ファイル新規作成の動作］
ここでは、図１５のステップＳ１５−４において実行されるファイル新規作成処理の動作を説明する。ファイルの新規作成処理は、ファイル作成削除部３が実行する。
図１６は、ファイル作成削除部３によるファイル作成の処理フローを示す。

同図において、始めに、ファイル生成削除部６は、新規に作成するユーザ利用ファイルが記憶されているディレクトリと、パス検索の実行指示とをパス検索部５に出力する（ステップＳ１６−１）。パス検索部５は、図１３に示すパス検索処理を行い、新規に作成するユーザ利用ファイルが登録されるディレクトリのディレクトリファイルをダウンロードし、ファイル生成削除部６へ返送する（ステップＳ１６−２）。

次に、ファイル生成削除部６は、新規に作成するｉノードファイルおよびデータファイルの２つのファイルを記憶させるサーバーの決定をサーバー選択部７に指示する（ステップＳ１６−３）。ｉノードファイルおよびデータファイルはそれぞれ、同じストレージサーバー装置１に記憶しても、異なるストレージサーバー装置１に記憶しても、どちらでもかまわない。本実施形態では、同じストレージサーバー装置１のファイル蓄積部３２に記憶するものとして説明する。

具体的には、サーバー選択部７は、ホストテーブル蓄積部３１に記憶されているホストテーブルから適当なストレージサーバー装置１を選択することで、ファイルの記憶先を決定する。ストレージサーバー装置１の選択方法には、ホストテーブル内のストレージサーバー装置１を順番に選択する方法（ラウンドロビン方式）や、定期的またはファイルの記憶先を選択する度に各ストレージサーバー装置１から空きディスク容量を受信し、空きディスク容量の多いストレージサーバー装置１を選択する方法（容量選択方式）、ネットワーク的に近くのストレージサーバー装置１を選択する方法など、色々な方法が考えられるが、本実施形態はその方法に依存するものではないため、任意の方法を適用するものとし、詳細は省略する。本実施形態ではラウンドロビン方式を用いるものとする。

続いて、サーバー選択部７によってファイルを記憶すべきストレージサーバー装置１が選択された後、ファイル生成削除部６は、選択されたストレージサーバー装置１のアドレスをホストテーブル蓄積部３１から読み出し、読み出したアドレスを宛先としてlow_create_id関数の実行要求を出力する。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_create_id関数の実行要求を出力する。low_create_id関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、low_create_id関数を実行した結果、ＩＤ生成部８により生成されたＩＤを、実行要求元のストレージサーバー装置１のファイル生成削除部６へ返送する（ステップＳ１６−４）。

第１の実施形態では、ファイル生成削除部６は、ステップＳ１６−４において取得したＩＤを使って新規に作成するファイルのファイル名を作成する（ステップＳ１６−５）。例えば、ステップＳ１６−４において、low_create_id関数を２回実行させてＩＤを２つ取得し、それぞれのＩＤを新規に作成するｉノードファイル名、データファイル名に用いても良いし、ステップＳ１６−４において、low_create_id関数を１回だけ実行してＩＤを１つ取得し、そのＩＤの拡張子を「.ino」,「.dat」などとしてそれぞれｉノードファイル名、データファイル名としても良い。

なお、新規に生成したファイルのファイル名が分散ファイル管理システム内で一意に特定できるファイル名であれば、ファイルの生成方法に特に制限されるものではない。例えば、第１の実施形態では新たなｉノードファイル、データファイルを記憶させるストレージサーバー装置１において実行されるlow_create_id関数によりＩＤを生成しているが、ファイル生成削除部６が動作しているストレージサーバー装置１の低レベルインタフェース部２３においてlow_create_id関数を実行してＩＤを生成し、そのＩＤからファイル名を生成してもよい。

次に、ファイル生成削除部６は、作成したｉノードファイル、データファイルのファイル名それぞれを引数fnameに設定したlow_write関数の実行要求を、当該ファイルの記憶先ストレージサーバー装置１へ出力し、実行要求先のストレージサーバー装置１の低レベルインタフェース部２３へlow_write関数を実行させる。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_write関数の実行要求を出力する。low_write関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、引数のfnameにより指定されるファイル名のｉノードファイル、データファイルをファイル蓄積部３２に作成する（ステップＳ１６−６）。なお、この時点では、ｉノードファイル、データファイルともにファイルの中身は未確定である。

次に、ファイル生成削除部６は、新規に作成するｉノードファイル及びデータファイルを記憶部３４に作成する（ステップＳ１６−７)。これらのファイルは、現在実行しているファイル生成削除部６のストレージサーバー装置１内に一時的に作成するファイルである。ファイル生成削除部６は、ｉノードファイルには<type>タグの要素内容に「normal」を、<body>タグの要素内容にステップＳ１６−５で生成したデータファイルのファイル名を設定する。また、ファイル生成削除部６は、ファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、引数dataで示されるデータを書き込んだデータファイルを生成して記憶部３４に書き込む。

次に、ファイル生成削除部６は、Ｓ１６−２でダウンロードしたディレクトリファイルに、新規に作成したファイルのディレクトリエントリを追加し、記憶部３４に書き込む（ステップＳ１６−８）。新規に追加するディレクトリエントリの<body>タグの要素内容には、ステップＳ１６−５で生成したｉノードファイルのファイル名を、<name>タグの要素内容には引数pathからパス名、つまり、ディレクトリ名を除いたユーザ利用ファイル名を設定する。

ファイル生成削除部６は、ステップＳ１６−７で新規に作成したｉノードファイル及びデータファイルと、ステップＳ１６−８で修正したディレクトリファイルの３つのファイルを記憶部３４から読み出し、それぞれ後述するアップロード手順によりアップロードする（ステップＳ１６−９〜１１）。

［１．３．５．２．３ ファイルアップロードの動作］
図１７は、ファイルのアップロードの処理手順を示す。ファイル生成削除部６は、アップロード対象ファイルのファイル名のハッシュ値をkeyとし、検索インタフェース部２２へget(key)関数の実行要求を出力する。get(key)関数の実行要求を受信した検索インタフェース部２２は、図９に示す処理を行い、その実行結果として、アップロード対象ファイルが記憶されているストレージサーバー装置１のアドレスを示すvalue値を得、パス検索部５へ出力する。これにより、パス検索部５は、アップロード対象ファイルを記憶しているストレージサーバー装置１のアドレスを取得する（ステップＳ１７−１）。

なお、アップロード対象ファイルのアップロード先となるストレージサーバー装置１がすでにわかっている場合、本ステップを省略することができる。例えば、図１６のステップＳ１６−９、Ｓ１６−１０から本処理が呼ばれた場合、ステップＳ１６−３において選択されたストレージサーバー装置１がアップロード先となる。また、ステップＳ１６−１１から本処理が呼ばれた場合、ステップＳ１６−２においてディレクトリファイルのダウンロードを要求した先のストレージサーバー装置１がアップロード先となる。

次に、ファイル生成削除部６は、get(key)関数の実行結果として得られたvalue値で示されるサーバーアドレスを宛先としてlow_write関数の実行要求を出力する（ステップＳ１７−２）。なお、サーバーアドレスが自ストレージサーバー装置１のアドレスであれば、自ストレージサーバー装置１の低レベルインタフェース部２３へlow_write関数の実行要求を出力する。low_write関数の引数fnameにはアップロード対象ファイルのファイル名が、引数dataには新たなファイルの内容全てが設定され、引数offset、sizeには、ファイルの先頭から最後までを新たなファイルの内容全体を書き込むみ対象とするための値が設定される。

low_write関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、引数に基づいてlow_write関数を実行し、ファイル蓄積部３２に記憶されている、引数fnameがファイル名であるファイルを、引数dataの内容により上書する。

［１．３．５．２．４ hi_write関数の動作例］
分散ファイル管理システムに図４のファイルが分散して記憶されている場合の、hi_write関数実行処理の動作例を説明する。例えば、図１５において、高レベルインタフェース部２４が、引数pathにパス付きユーザ利用ファイル名「/work/dog.mxf」が設定されたhi_write関数の実行指示を受信したとする。高レベルインタフェース部２４は、パス検索部５へ引数pathとパス検索の実行指示とを出力する（ステップＳ１５−１）。

図１３において、パス検索部５は、高レベルインタフェース部２４が引数pathにパス付きユーザ利用ファイル名「/work/fish.mxf」が設定されたhi_read関数を受信したときと同様の処理を行い、親のディレクトリのディレクトリファイル「C.dir」をダウンロードする。つまり、パス検索部５は、ルートｉノードファイル「00000.ino」をダウンロードし、<body>タグの要素内容に基づいてディレクトリファイル名「00000.dir」をダウンロードする。さらに、パス検索部５は、ディレクトリファイル「00000.dir」から、ディレクトリ名「work」が<name>タグの要素内容として記述されているディレクトリエントリを特定し、その<body>タグの要素内容に基づいてｉノードファイル「C.ino」をダウンロードする。パス検索部５は、ｉノードファイル「C.ino」の<body>タグの要素内容に基づいてディレクトリファイル「C.dir」をダウンロードする。ここでは、ディレクトリファイル「C.dir」のダウンロードを要求した先のストレージサーバー装置１をストレージサーバー装置１ａとする。

パス検索部５は、ディレクトリファイル「C.dir」に、パス付きユーザ利用ファイル名「/work/dog.mxf」で示される「work」配下のファイル名「dog.mxf」がいずれのディレクトリエントリの<name>タグの要素内容にも記述されていないため（ステップＳ１３−６：ＮＯ）、処理を終了する。
ここで、図１５において、ファイル生成削除部６は、ファイルが存在しないと判断し（ステップＳ１５−２）、ファイル作成を行なう（ステップＳ１５−３）。

図１６において、ファイル生成削除部６は、新規に作成するユーザ利用ファイルが記憶されているディレクトリ「/work」のディレクトリファイル「C.dir」がすでに読み出されているため、ステップＳ１６−１及びＳ１６−２の処理を省略し、新規に作成するｉノードファイルおよびデータファイルの２つのファイルを記憶させるストレージサーバー装置１の決定をサーバー選択部７に指示する（ステップＳ１６−３）。ここでは、ファイルを記憶させるストレージサーバー装置１をストレージサーバー装置１ｂとする。

続いて、ファイル生成削除部６は、ホストテーブル蓄積部３１から読み出したストレージサーバー装置１ｂのアドレスを宛先としてlow_create_id関数の実行要求を出力する。ストレージサーバー装置１ｂの低レベルインタフェース部２３は、生成したＩＤ「H」を返送する（ステップＳ１６−４）。ファイル生成削除部６は、ｉノードファイル名を「H.ino」、データファイル名を「H.dat」とする（ステップＳ１６−５）。

ファイル生成削除部６は、ストレージサーバー装置１ｂへ引数fnameに「H.ino」を設定したlow_write関数の実行要求と、引数fnameに「H.dat」を設定したlow_write関数の実行要求を出力する。ストレージサーバー装置１ｂの低レベルインタフェース部２３は、ファイル蓄積部３２にファイル「H.ino」及び「H.dat」を新規に生成する（ステップＳ１６−６）。

次に、ファイル生成削除部６は、<type>タグの要素内容に「normal」を、<body>にデータファイル名である「H.dat」を設定したｉノードファイル「H.ino」を生成し、ファイル生成削除部６の備える記憶部に書き込む。さらに、ファイル生成削除部６は、ファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、引数dataで示されるデータを書き込んだデータファイル「H.dat」を生成し、ファイル生成削除部６の備える記憶部３４に書き込む（ステップＳ１６−７）。

次に、ファイル生成削除部６は、ディレクトリファイル「C.dir」に、新たな属性値no="4"を割当てた<entry no="4">タグを追加し、このディレクトリエントリ内の<body>タグの要素内容に、生成したｉノードファイルのファイル名「H.ino」を書き込むとともに、<name>タグの要素内容に、引数path「/work/fish.mxf」からパスを除いたユーザ利用ファイル名「fish.mxf」を設定し、記憶部３４に書き込む（ステップＳ１６−８）。

ファイル生成削除部６は、記憶部３４から読み出したｉノードファイル「H.ino」及びデータファイル「H.dat」をストレージサーバー装置１ｂにアップロードし（ステップＳ１６−９、Ｓ１６−１０）、更新したディレクトリファイル「C.dir」をストレージサーバー装置１ａにアップロードする（ステップＳ１６−１１）。

具体的には、図１７のステップＳ１７−２において、ファイル生成削除部６は、引数fnameに「H.ino」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶しているｉノードファイル「H.ino」のデータ全体を書き込み対象とする値を設定したlow_write関数の実行要求と、引数fnameに「H.dat」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶しているデータファイル「H.dat」のデータ全体を書き込み対象とする値を設定したlow_write関数の実行要求をストレージサーバー装置１ｂへ出力する。さらに、ファイル生成削除部６は、引数fnameに「C.dir」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶している更新後のディレクトリファイル「C.dir」のデータ全体、あるいは、ステップＳ１６−８において変更された箇所のみを書き込み対象とする値を設定したlow_write関数の実行要求をストレージサーバー装置１ａへ出力する。

［１．３．５．３ hi_delete関数］
［１．３．５．３．１ hi_delete関数の動作］
次に高レベルインタフェース部２４におけるhi_delete関数の動作を説明する。hi_delete関数は、パス付きユーザ利用ファイル名で示されたユーザ利用ファイルを削除するインタフェースである。高レベルインタフェース部２４は、hi_delete関数の実行要求を受信すると、ファイル生成削除部６へファイル削除を指示する。

図１８は、ファイル生成削除部６によるファイル削除処理の流れ図である。
同図において、始めに、ファイル生成削除部６は、引数pathにより指定されたパス付きユーザ利用ファイル名から、削除対象ユーザ利用ファイルが属する親ディレクトリのパスを取得し、この取得したパスのパス検索をパス検索部５に指示する（ステップＳ１８−１）。これにより、パス検索部５は、図１３に示すパス検索処理を行う。このパス検索において、パス検索部５は、ユーザ利用ファイルが属するディレクトリのディレクトリファイルをダウンロードする（ステップＳ１８−２）。

次に、ファイル生成削除部６は、ダウンロードしたディレクトリファイルのＸＭＬデータを解析し、パス付きユーザ利用ファイル名におけるユーザ利用ファイルのファイル名が<name>タグの要素内容として記述されているディレクトリエントリを検索し、その<body>タグの要素内容からｉノードファイルのファイル名を取得する（ステップＳ１８−３）。
ファイル生成削除部６は、ステップＳ１８−３において読み出したｉノードファイルの削除を実行する（ステップＳ１８−４）。このときのｉノードファイルの削除は、後述するように、ｉノードファイルの削除だけでなく、当該ｉノードファイルに紐付けされるデータファイルの削除も行う。

続いて、ファイル生成削除部６は、ステップＳ１８−２においてダウンロードしたディレクトリファイルのＸＭＬデータから、削除対象ファイルのディレクトリエントリを削除し（ステップＳ１８−５）、修正したディレクトリファイルを、当該ディレクトリファイルをダウンロードした元のストレージサーバー装置１へアップロードする（ステップＳ１８−６）。
以上の動作により、指定されたパスのファイルが削除される。

［１．３．５．３．２ ｉノードファイルの削除の動作］
次に、図１８のステップＳ１８−４において実行されるｉノードファイルの削除動作を説明する。図１９は、ファイル生成削除部６によるｉノードファイル削除処理の流れ図である。

同図において、まず、ファイル生成削除部６は、削除対象のｉノードファイルを記憶しているストレージサーバー装置１を検索するため、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１９−１)。keyには、削除対象のｉノードファイルのファイル名のハッシュ値を設定する。

次に、ファイル生成削除部６は、get(key)関数の実行結果として得られたvalue値で示されるサーバーアドレスを宛先として、図１４の処理を行い、削除対象のｉノードファイルをダウンロードする（ステップＳ１９−２）。

ファイル生成削除部６は、取得したｉノードファイルのＸＭＬデータを解析し、<body>タグで示されるファイル名、および、<type>タグの要素内容で示されるファイルタイプを取得する（ステップＳ１９−３）。ファイルタイプが「normal」、すなわち、データファイルである場合（ステップＳ１９−４：normal）、ファイル生成削除部６は、ステップＳ１９−３において読み出したデータファイルのファイル名のハッシュ値をkeyに設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１９−７）。これにより、ファイル生成削除部６は、当該データファイルを記憶しているストレージサーバー装置１のアドレスを示すvalue値を取得する。

ファイル生成削除部６は、ステップＳ１９−７において取得したvalue値で示されるサーバーアドレスを宛先として、ステップＳ１９−７で取得したデータファイル名を引数fnameに設定したlow_delete関数の実行指示を出力する。low_delete関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、ファイル入出力部４に指示し、引数fnameのデータファイルをファイル蓄積部３２から削除する（ステップＳ１９−８）。

さらに、ファイル生成削除部６は、削除対象のｉノードファイルのファイル名を引数fnameに設定したlow_delete関数の実行指示を、当該ｉノードファイルのダウンロードを要求した先のストレージサーバー装置１へ出力する。low_delete関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、ファイル入出力部４に指示し、引数fnameで示されるｉノードファイルをファイル蓄積部３２から削除する（ステップＳ１９−９）。上記処理により、最終的に、Ｓ１９−１においてｉノードファイルのダウンロードを要求した先のストレージサーバー装置１でlow_delete関数が実行され、ｉノードファイルが削除される。

一方、ステップＳ１９−４において、ファイルタイプがディレクトリ「directory」である場合（ステップＳ１９−４：directory）、ファイル生成削除部６は、図１４に示す処理を行い、ステップＳ１９−３において読み出したファイル名のディレクトリファイルをダウンロードする（ステップＳ１９−５）。ファイル生成削除部６は、ダウンロードしたディレクトリファイルのエントリから、カレントディレクトリ「.」、親のディレクトリ「..」が設定されているディレクトリエントリ以外の各ディレクトリエントリ内の<body>タグの要素内容からｉノードファイルのファイル名を読み出す。そして、読み出したそれぞれのｉノードファイルについて、再帰的にステップＳ１９−１からのｉノードファイルの削除の処理を再帰的な実行を起動する（ステップＳ１９−６）。その後、ファイル生成削除部６は、ステップＳ１９−７から処理を行なう。つまり、ファイル生成削除部６は、ステップＳ１９−５においてダウンロードしたディレクトリァイルのファイル名のハッシュ値をkeyに設定し、検索インタフェース部２２にget(key)関数の実行要求を出力してvalue値を取得し（ステップＳ１９−７）、取得したvalue値で示されるサーバーアドレスを宛先として、ステップＳ１９−７で取得したディレクトリファイル名を引数fnameに設定したlow_delete関数の実行指示を出力する。さらに、ファイル生成削除部６は、削除対象のｉノードファイルのファイル名を引数fnameに設定したlow_delete関数の実行指示を、当該ｉノードファイルのダウンロードを要求した先のストレージサーバー装置１へ出力する（ステップＳ１９−９）。なお、ステップＳ１９−５において、ディレクトリファイルのダウンロードを要求した先のストレージサーバー装置１がわかっている場合、ステップＳ１９−７の処理は省略することができる。

［１．３．５．３．３ hi_delete関数の動作例］
分散ファイル管理システムに図４のファイルが分散して記憶されている場合の、hi_delete関数実行処理の動作例を説明する。例えば、図１８において、高レベルインタフェース部２４が、引数pathにパス付きディレクトリ名「/work/cat.mxf」が設定されたhi_delete関数の実行指示を受信したとする。ファイル生成削除部６は、パス検索部５へ、ユーザ利用ファイル「cat.mxf」が属する親ディレクトリ「/work」のパス検索の実行指示を出力する（ステップＳ１８−１）。

パス検索部５は、図１３に示す処理により、hi_write関数を受信したときと動作例と同様の処理を行い、親のディレクトリ「/work」のディレクトリファイル「C.dir」をダウンロードする（ステップＳ１８−２）。
パス検索部５は、ディレクトリファイル「C.dir」から、パス付きユーザ利用ファイル名「/work/cat.mxf」で示される「work」配下のファイル名「cat.mxf」が<name>タグの要素内容に記述されている「no="3"」のディレクトリエントリを検出すると、このディレクトリエントリの<body>タグの要素内容からｉノードファイル名「G.ino」を取得する（図１８：ステップＳ１８−３）。

次に、ファイル生成削除部６は、ステップＳ１８−３において読み出したｉノードファイル「G.ino」の削除を実行する（ステップＳ１８−４）。
具体的には、図１９に示すように、ファイル生成削除部６は、keyにｉノードファイルのファイル名「G.ino」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１９−１)。これにより、ｉノードファイル「G.ino」を記憶するストレージサーバー装置１のサーバーアドレスを示すvalue値が得られる。ファイル生成削除部６は、value値が示すサーバーアドレスを宛先としてストレージサーバー装置１へアクセスし、図１４の処理によりｉノードファイル「G.ino」をダウンロードする（ステップＳ１９−２）。ファイル生成削除部６は、取得したｉノードファイル「G.ino」からファイル名「G.dat」、および、ファイルタイプ「normal」を取得する（ステップＳ１９−３）。ファイルタイプが「normal」であるため（ステップＳ１９−４：normal）、ファイル生成削除部６は、データファイル名「G.dat」のハッシュ値をkeyに設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１９−７）。これにより、ファイル生成削除部６は、データファイル「G.dat」を記憶しているストレージサーバー装置１のアドレスを示すvalue値を取得する。

ファイル生成削除部６は、取得したvalue値で示されるサーバーアドレスを宛先としてデータファイル名「G.dat」を引数fnameに設定したlow_delete関数の実行指示を出力する。low_delete関数の実行要求を受信した自ストレージサーバー装置１または他のストレージサーバー装置１の低レベルインタフェース部２３は、ファイル入出力部４に指示し、引数fnameのデータファイルをファイル蓄積部３２から削除する（ステップＳ１９−８）。

さらに、ファイル生成削除部６は、削除対象のｉノードファイルのファイル名「G.ino」を引数fnameに設定したlow_delete関数の実行指示を、ステップＳ１８−３においてダウンロードを要求した先のストレージサーバー装置１へ出力する。low_delete関数の実行要求を受信したストレージサーバー装置１の低レベルインタフェース部２３は、ファイル入出力部４に指示し、引数fnameのｉノードファイル「G.ino」をファイル蓄積部３２から削除する（ステップＳ１９−９）。

図１８において、ファイル生成削除部６は、ステップＳ１８−２においてダウンロードしたディレクトリファイル「C.dir」から、削除対象ファイル「G.ino」が含まれている<entry no="3">のディレクトリエントリを削除し（ステップＳ１８−５）、エントリ削除後のディレクトリファイル「C.dir」を、当該ディレクトリファイルのダウンロードを要求した先のストレージサーバー装置１へアップロードする（ステップＳ１８−６）。

［１．３．５．４ hi_make_dir関数］
［１．３．５．４．１ hi_make_dir関数の動作］
次に高レベルインタフェース部２４におけるhi_make_dir関数の動作を説明する。hi_make_dir関数は、パス付きディレクトリ名で示されたディレクトリを新規に作成するインタフェースである。高レベルインタフェース部２４は、hi_make_dir関数の実行要求を受信すると、ファイル生成削除部６へディレクトリ作成を指示する。

図２０は、ファイル生成削除部６によるディレクトリファイル作成処理の流れ図である。
同図において、始めに、ファイル生成削除部６は、新規ディレクトリが配下に作成されるディレクトリ、つまり、新規ディレクトリの親となるディレクトリのパス検索の実行指示をパス検索部５に出力する（ステップＳ２０−１）。パス検索部５は、図１３に示すパス検索処理を行い、新規に作成するディレクトリの親となるディレクトリのディレクトリファイルをダウンロードし、ファイル生成削除部６へ返送する（ステップＳ２０−２）。

次に、ファイル生成削除部６は、図１６におけるステップＳ１６−３〜Ｓ１６−６と同様の処理を行う。ただし、図１６におけるデータファイルは、ここでは、ディレクトリファイルとする。つまり、新規に作成するｉノードファイルおよびディレクトリファイルの２つのファイルを保管するストレージサーバー装置１の決定をサーバー選択部７により指示し（ステップＳ２０−３）、選択されたストレージサーバー装置１の低レベルインタフェース部２３のlow_create_id関数を実行し（ステップＳ２０−４）、新規のディレクトリファイルとｉノードファイルのファイル名を決定する（ステップＳ２０−５)。ここでは、ステップＳ２０−４において、low_create_id関数を１回だけ実行してＩＤを１つ取得し、そのＩＤの拡張子を「.ino」,「.dir」としてそれぞれｉノードファイル名、ディレクトリファイル名とする。そして、決定したファイル名でｉノードファイルとディレクトリファイルを作成するために、Ｓ２０−３で選択したサーバーのlow_write関数を実行する（ステップＳ２０−６）。

次に、ファイル生成削除部６は、新規のｉノードファイルとディレクトリファイルを一時的なファイルとして作成し、記憶部３４に記憶する（ステップＳ２０−７)。
新規のｉノードファイルの<type>タグの要素内容には「directory」を、<body>タグの要素内容にはＳ２０−５で作成したディレクトリファイルのファイル名を設定する。新規のディレクトリファイルには、<name>タグの要素内容にカレントディレクトリ「.」を、<body>タグの要素内容にＳ２０−５で作成したｉノードファイルのファイル名を設定したディレクトリエントリ、及び、<name>タグの要素内容に親ディレクトリ「..」、<body>タグの要素内容にＳ２０−２でダウンロードした親ディレクトリのｉノードファイル名を設定したディレクトリエントリを記述する。

次に、Ｓ２０−２でダウンロードしたディレクトリファイルに、新規に作成するディレクトリのディレクトリエントリを追加し、記憶部３４に書き込む（ステップＳ２０−８）。新規に追加するディレクトリエントリの<body>タグの要素内容には、ステップＳ２０−５で生成したｉノードファイルのファイル名を、<name>タグの要素内容には引数pathから親のディレクトリを除いた新規に追加するディレクトリ名を設定する。

以上の動作の後、ステップＳ２０−７で新規に作成したｉノードファイル及びディレクトリファイルと、ステップＳ２０−８で修正した親のディレクトリのディレクトリファイルを記憶部３４から読み出し、それぞれを図１７の手順によりアップロードする（ステップＳ２０−９〜１１）。ｉノードファイル及びディレクトリファイルのアップロード先は、ステップＳ２０−６において、ｉノードファイル及びディレクトリファイルを新規に生成したストレージサーバー装置１であり、ディレクトリファイルのアップロード先は、ステップＳ２０−２において当該ディレクトリファイルのダウンロードを要求した先のストレージサーバー装置１である。

［１．３．５．４．２ hi_make_dir関数の動作例］
分散ファイル管理システムに図４ファイルが分散して記憶されている場合の、hi_read関数実行処理の動作例を説明する。例えば、図２０において、高レベルインタフェース部２４が、引数pathにパス付きディレクトリ名「/work/tmp」が設定されたhi_make_dir関数の実行指示を受信したとする。ファイル生成削除部６は、新たなディレクトリの親ディレクトリのパスと、パス検索の実行指示とをパス検索部５へ出力する（ステップＳ２０−１）。

パス検索部５は、図１３に示す処理により、hi_write関数を受信したときの動作例と同様の処理を行い、親のディレクトリ「/work」のディレクトリファイル「C.dir」をダウンロードする（ステップＳ２０−２、ステップＳ１３−５）。ここでは、ディレクトリファイル「C.dir」を要求した先のストレージサーバー装置１をストレージサーバー装置１ａとする。
パス検索部５は、ディレクトリファイル「C.dir」に、パス付きユーザ利用ファイル名「/work/tmp」で示される「/work」配下のディレクトリ名「tmp」がいずれの<name>タグの要素内容にも記述されていないため（ステップＳ１３−６：ＮＯ）、処理を終了する（ステップＳ１３−８）。

ファイル生成削除部６は、新規に作成するｉノードファイルおよびデータファイルの２つのファイルを記憶させるストレージサーバー装置１の決定をサーバー選択部７に指示する（ステップＳ２０−３）。ここでは、ファイルを記憶させるストレージサーバー装置１をストレージサーバー装置１ｂとする。ファイル生成削除部６は、ホストテーブル蓄積部３１から読み出したストレージサーバー装置１ｂのアドレスを宛先としてlow_create_id関数の実行要求を出力する。ストレージサーバー装置１ｂの低レベルインタフェース部２３は、生成したＩＤ「J」を返送する（ステップＳ２０−４）。ファイル生成削除部６は、ｉノードファイル名を「J.ino」、ディレクトリファイル名を「J.dir」とする（ステップＳ２０−５）。

ファイル生成削除部６は、ストレージサーバー装置１ｂへ引数fnameに「J.ino」を設定したlow_write関数の実行要求と、引数fnameに「J.dir」を設定したlow_write関数の実行要求を出力する。ストレージサーバー装置１ｂの低レベルインタフェース部２３は、ファイル蓄積部３２にファイル「J.ino」及び「J.dir」を新規に生成する（ステップＳ２０−６）。

ファイル生成削除部６は、<type>タグの要素内容に「directory」を、<body>の要素内容にディレクトリファイル名である「J.dir」を設定したｉノードファイル「J.ino」を生成し、ファイル生成削除部６の備える記憶部３４に書き込む。さらに、ファイル生成削除部６は、<name>タグの要素内容にカレントディレクトリ「.」を、<body>タグの要素内容にＳ２０−５で作成したｉノードファイルのファイル名「J.ino」を設定した<entry "no=0">のディレクトリエントリ、及び、<name>タグの要素内容に親ディレクトリ「..」、<body>タグの要素内容にＳ２０−２でダウンロードした親ディレクトリのｉノードファイル名「C.ino」を設定した<entry "no=1">のディレクトリエントリを記述したディレクトリファイル「J.dir」を作成し、記憶部３４に書き込む（ステップＳ２０−７）。

ファイル生成削除部６は、親ディレクトリのディレクトリファイル「C.dir」に、新たな属性値no="4"を割当てた<entry no="4">タグを追加し、このディレクトリエントリ内の<body>タグの要素内容に、生成したｉノードファイルのファイル名「J.ino」を書き込むとともに、<name>タグの要素内容に、引数path「/work/tmp」から親のパスを除いたディレクトリ名「tmp」を設定し、記憶部３４に書き込む（ステップＳ２０−８）。

ファイル生成削除部６は、記憶部３４から読み出したｉノードファイル「J.ino」及びデータファイル「J.dir」をストレージサーバー装置１ｂにアップロードし（ステップＳ２０−９、Ｓ２０−１０）、更新したディレクトリファイル「C.dir」をストレージサーバー装置１ａにアップロードする（ステップＳ２０−１１）。

具体的には、図１７のステップＳ１７−２において、ファイル生成削除部６は、引数fnameに「J.ino」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶しているｉノードファイル「J.ino」のデータ全体を書き込み対象とする値を設定したlow_write関数の実行要求と、引数fnameに「J.dir」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶しているディレクトリファイル「J.dir」のデータ全体を書き込み対象とする値を設定したlow_write関数の実行要求をストレージサーバー装置１ｂへ出力する。さらに、ファイル生成削除部６は、引数fnameに「C.dir」を設定し、引数offset、size、dataに、ファイル生成削除部６の備える記憶部３４に記憶している更新後のディレクトリファイル「C.dir」のデータ全体、あるいは、ステップＳ２０−８において変更された箇所のみを書き込み対象とする値を設定したlow_write関数の実行要求をストレージサーバー装置１ａに出力する。

［１．３．５．５ hi_delete_dir関数］
［１．３．５．５．１ hi_delete_dir関数処理の動作］
次に高レベルインタフェース部２４のhi_delete_dir関数の動作の説明をする。hi_delete_dir関数は、指定されたパスのディレクトリを削除するインタフェースである。高レベルインタフェース部２４は、hi_delete_dir関数の実行要求を受信すると、ファイル生成削除部６へディレクトリ削除を指示する。ここでは、ディレクトリの削除が実行されると、そのディレクトリに含まれるファイルおよびディレクトリもすべて削除されるものとして説明する。

図２１は、ファイル生成削除部６によるディレクトリ削除処理の流れ図である。
同図において、始めに、ファイル生成削除部６は、引数pathにより指定される削除対象ディレクトリの親のディレクトリのパス検索をパス検索部５に指示する（ステップＳ２１−１）。パス検索部５は、図１３に示すパス検索処理を行い、削除対象ディレクトリの親ディレクトリのディレクトリファイルをダウンロードし、ファイル生成削除部６へ返送する（ステップＳ２１−２）。

次に、ファイル生成削除部６は、ダウンロードしたディレクトリファイルのＸＭＬデータを解析し、削除対象のディレクトリのディレクトリ名が<name>タグの要素内容として記述されているディレクトリエントリを検索し、その<body>タグの要素内容から削除対象ディレクトリのｉノードファイル名を取得する（ステップＳ２１−３）。

次に、ファイル生成削除部６は、ステップＳ２１−３において取得したｉノードファイルについて、図１９に示す削除の処理を実行する（ステップＳ２１−４）。図１９に示す処理で説明したように、ｉノードファイル削除を実行することで、指定されたディレクトリに関するファイルが分散ファイル管理システムから削除される。

最後に、ファイル生成削除部６は、ステップＳ２１−１においてダウンロードした親ディレクトリファイルから、削除対象のディレクトリのディレクトリエントリを削除し（ステップＳ２１−５）、この削除を行なったディレクトリファイルをアップロードする（ステップＳ２１−６）。

［１．３．５．５．２ hi_delete_dir関数の動作例］
分散ファイル管理システムに図４のファイルが分散して記憶されている場合の、hi_read関数実行処理の動作例を説明する。例えば、図２１において、高レベルインタフェース部２４が、引数pathにパス付きディレクトリ名「/work」が設定されたhi_delete_dir関数の実行指示を受信したとする。ファイル生成削除部６は、「/work」が属する親ディレクトリ「/」（ルートディレクトリ）のパス検索の実行をパス検索部５へ指示する（ステップＳ２１−１）。

パス検索部５は、図１３に示す処理により、ルートｉノードファイル「00000.ino」をストレージサーバー装置１からダウンロードし、<body>タグの要素内容に基づいてディレクトリファイル名「00000.dir」をストレージサーバー装置１からダウンロードする（ステップＳ２１−２）。さらに、パス検索部５は、ディレクトリファイル「00000.dir」から、パス付きディレクトリ名で示されるディレクトリ名「work」が<name>タグの要素内容として記述されているディレクトリエントリを特定すると、その<body>タグの要素内容からｉノードファイル名「C.ino」の取得する（ステップＳ２１−３）。

続いて、ファイル生成削除部６は、ｉノードファイル名「C.ino」の削除を行なう。
具体的には、ファイル生成削除部６は、図１９に示す処理により、keyにｉノードファイルのファイル名「C.ino」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力する（ステップＳ１９−１)。ファイル生成削除部６は、図１４の処理により、value値が示すサーバーアドレスを宛先としてストレージサーバー装置１へlow_write関数の実行要求を出力し、ｉノードファイル「C.ino」をダウンロードする（ステップＳ１９−２）。

ファイル生成削除部６は、取得したｉノードファイル「C.ino」からファイル名「C.dir」、および、ファイルタイプ「directory」を取得する（ステップＳ１９−３）。ファイルタイプが「directory」であるため（ステップＳ１９−４：directory）、ファイル名「C.dir」のディレクトリファイルをダウンロードする。つまり、図１４の処理によりファイル生成削除部６は、keyにｉノードファイルのファイル名「C.dir」のハッシュ値を設定し、検索インタフェース部２２にget(key)関数の実行要求を出力し、返送されたvalue値が示すサーバーアドレスを宛先としてストレージサーバー装置１へlow_write関数の実行要求を出力して、ディレクトリファイル「C.dir」をダウンロードする（ステップＳ１９−５）。

ファイル生成削除部６は、カレントディレクトリ「.」、親のディレクトリ「..」が設定されているディレクトリエントリ以外の各ディレクトリエントリ<entry no="2">、<entry no="3">内の<body>タグの要素内容からｉノードファイルのファイル名「F.ino」、「G.ino」を読み出す。そして、読み出したそれぞれのｉノードファイルについて、再帰的にステップＳ１９−１からのｉノードファイルの削除処理の再帰的な実行を起動する（ステップＳ１９−６）。

ｉノードファイル「F.ino」について、ステップＳ１９−１からの処理が起動された場合、ファイル生成削除部６は、keyにファイル名「F.ino」のハッシュ値を設定して検索インタフェース部２２にget(key)関数の実行要求を出力し、返送されたvalue値により示されるサーバーアドレスを宛先として引数fnameに「F.ino」を設定したlow_readの実行要求を出力して、ｉノードファイル「F.ino」をダウンロードする（ステップＳ１９−２）。ファイル生成削除部６は、取得したｉノードファイル「F.ino」からファイル名「F.dat」、および、ファイルタイプ「normal」を取得する（ステップＳ１９−３）。ファイルタイプが「normal」であるため（ステップＳ１９−４：normal）、ファイル生成削除部６は、データファイル名「F.dat」のハッシュ値をkeyに設定して検索インタフェース部２２にget(key)関数の実行要求を出力し（ステップＳ１９−７）、返送されたvalue値により示されるサーバーアドレスを宛先として、引数fnameにデータファイル名「F.dat」を設定したlow_delete関数の実行要求を出力し、データファイル「F.dat」を削除する（ステップＳ１９−８）。続いて、引数fnameにｉノードファイル名「F.ino」を設定したlow_delete関数の実行指示を、ｉノードファイル「F.ino」のダウンロードを要求した先のストレージサーバー装置１へ出力し、ｉノードファイル「F.ino」を削除する（ステップＳ１９−９）。
ｉノードファイル「G.ino」についてもｉノードファイル「F.ino」と同様の処理を行い、ｉノードファイル「G.ino」とデータファイル「G.dat」を削除する。

ファイル生成削除部６は、ｉノードファイル「F.ino」、「G.ino」について削除処理の再帰的な実行を起動した後、データファイル「C.dir」のダウンロードを要求した先のストレージサーバー装置１へ引数fnameにディレクトリファイル名「C.dir」を設定したlow_delete関数の実行要求を出力し、ディレクトリファイル「C.dir」を削除する（ステップＳ１９−８）。続いて、ファイル生成削除部６は、ｉノードファイル「C.ino」のダウンロードを要求した先のストレージサーバー装置１へ、引数fnameにｉノードファイル名「C.ino」を設定したlow_delete関数の実行指示を出力し、ｉノードファイル「C.ino」を削除する（ステップＳ１９−９）。

上記のように、ｉノードファイルの削除を実行した後、ファイル生成削除部６は、親ディレクトリファイル「00000.dir」から、削除対象のディレクトリの名前「work」が記述されているディレクトリエントリ<entry no="3">〜</entry>までの行を削除し（ステップＳ２１−５）、この削除を行なったディレクトリファイル「00000.dir」を、当該ディレクトリファイルのダウンロードを要求した先のストレージサーバー装置１へアップロードする（ステップＳ２１−６）。

［１．４ 効果］
以上、説明した第１の実施形態による分散ファイル管理システムにより、当該分散ファイル管理システムを構成する複数のストレージサーバー装置１によって、ファイルおよびディレクトリの分散管理が可能となり、多数のファイルおよびディレクトリを一元的に管理するサーバーが不要である。従って、多数のユーザから同時にファイルへのアクセスがあった場合でも特定のサーバーに負荷が集中することがなく、また、多くのファイルやディレクトリが作成された場合でも、各ストレージサーバー装置１が管理するファイルは少なくてよいため、ファイルの検索に要する時間が長くならないようにすることができる。また、分散ファイル管理システムで保持するファイルは、各ストレージサーバー装置１の外部インタフェース部２を介して操作することが可能となり、ユーザ利用ファイル名によって指定されたファイルや、ディレクトリ名によって指定されたディレクトリに対する操作を行なうことができる。

［２． 第２の実施形態］
上述した第１の実施形態の図１３に示すパス検索では、ｉノードファイルやディレクトリファイル等のファイルが必要となる度に、当該ファイルを記憶しているストレージサーバー装置１からダウンロードを行なっていた。一方、第２の実施形態は、ストレージサーバー装置１は、パス検索において、ダウンロードしたｉノードファイルやディレクトリファイルを記憶しておき、更新を検出するまで、記憶しているダウンロードファイルを用いて処理を実行するキャッシュを行い、パス検索動作を高速化するものである。以下、第１の実施形態との差分を説明する。

［２．１ 構成］
図２２は、第２の実施形態による分散ファイル管理システムのブロック図であり、図１に示す第１の実施形態による分散ファイル管理システムと同一の部分には同一の符号を付し、その説明を省略する。この図に示す分散ファイル管理システムが第１の実施形態と異なる点は、ストレージサーバー装置１がキャッシュ蓄積部３５を備える点である。キャッシュ蓄積部３５は、ハードディスク装置や半導体メモリなどで実現され、ダウンロードしたｉノードファイル及びディレクトリファイルを記憶する。

［２．２ データ構成］
図２３は、第２の実施形態によるキーテーブルの構成を示す図である。同図に示すように、キーテーブルには、ファイル名のハッシュ値を示すkeyと、当該ファイル名のファイルを蓄積しているストレージサーバー装置１のアドレス及び当該ファイルのバージョン番号とを示すvalueと、登録日時とを対応づけた複数のレコードからなる。

図２４は、第２の実施形態によるput（key, value）関数のパラメータ構造を示す図である。同図において、keyは第１の実施形態と同様にファイル名のキャッシュ値が設定される。一方、valueは、サーバーアドレスと、ファイルのバージョン番号とからなる。

［２．３ ストレージサーバー装置１の動作］
［２．３．１ low_write関数の動作］
キャッシュされたファイルを使うためには、すでにダウンロードしたファイルが最新のファイルと同じものかどうかを判断する必要がある。そのため、第２の実施形態では、ファイルの登録におけるvalue値にファイルのバージョン番号を追加する。第２の実施形態では、低レベルインタフェース部２３のlow_write関数が実行されるたびに、ファイルのバージョン番号に１を加算する。

第１の実施形態において、低レベルインタフェース部２３におけるlow_write関数の処理は、ファイル蓄積部３２に記憶されたファイルにデータを書き込む動作のみであった。第２の実施形態においては、low_write関数の実行要求があると、ファイル蓄積部３２内の指定したファイルのデータを書き換え、次に、バージョン番号に１を加算して、登録インタフェース部２１のput(key, value)を実行しファイルの再登録を行う。詳細な処理を以下に示す。

図２５は、低レベルインタフェース部２３によるlow_write関数実行処理の流れ図を示す。同図において、低レベルインタフェース部２３が、自ストレージサーバー装置１の各部または他のストレージサーバー装置１から、low_write関数の実行要求を受信すると、ファイル入出力部４は、引数fnameで示されるファイル蓄積部３２内のファイルを特定する。

引数fnameで示されるファイルがファイル蓄積部３２に存在しない場合（ステップＳ２５−１：ＹＥＳ）、ファイル入出力部４は、新たにfnameで指定された名前のファイルをファイル蓄積装置３２に作成する。そして、ファイル入出力部４は、作成したファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、dataで示されるデータを書き込む（ステップＳ２５−２）。さらに、低レベルインタフェース部２３は、新たに作成したファイルに対応づけて、初期値のバージョン番号をファイル蓄積部３２に書き込むようファイル入出力部４へ指示する（ステップＳ２５−３）。低レベルインタフェース部２３は、引数fnameのハッシュ値をkeyに、自ストレージサーバー装置１のアドレス及びステップＳ２５−３で書き込んだバージョン番号をvalueに設定し、put(key, value）の実行要求を登録インタフェース部２１へ出力する（ステップＳ２５−４）。登録インタフェース部２１が、第１の実施形態の図７と同様の登録処理を行うことによって、所在管理テーブル蓄積部３３内のキーテーブルに、(key, value）が登録される。

一方、引数fnameで示されるファイルがファイル蓄積部３２に存在する場合（ステップＳ２５−１：ＮＯ）、ファイル入出力部４は、引数fnameをファイル名とするファイルの先頭から、引数offsetで示されるバイト数だけ進んだ位置を書き込み開始位置とし、この書き込み開始位置から引数offsetで示されるバイト数分、dataで示されるデータを書き込む（ステップＳ２５−５）。続いて、低レベルインタフェース部２３は、書き込みを行なったファイルに対応付けてファイル蓄積部３２に記憶されているバージョン番号を、１加算した値の番号に更新するようファイル入出力部４へ指示する（ステップＳ２５−６）。低レベルインタフェース部２３は、引数fnameのハッシュ値をkeyに、自ストレージサーバー装置１のアドレス及びステップＳ２５−６で書き込んだバージョン番号をvalueに設定し、put(key, value）の実行要求を登録インタフェース部２１へ出力する（ステップＳ２５−４）。これにより、所在管理テーブル蓄積部３３内のキーテーブルに、(key, value）が登録される。

［２．３．２ パス検索の動作］
第２の実施形態では、パス検索部５におけるパス検索動作は、図１３で説明した第１の実施形態の動作と全く同じである。但し、パス検索で実行されるダウンロードの動作において、キャッシュ蓄積部３５内のファイルを使うかどうかのチェックが必要であるため、第１の実施形態の図１４に示すダウンロードの動作を、図２６で示す動作に変更する。

図２６は、第２の実施形態によるファイルダウンロード処理の流れ図を示す。
始めに、パス検索部５は、ダウンロード対象ファイルのファイル名のハッシュ値をkeyとし、検索インタフェース部２２へget(key) 関数の実行要求を出力する。get(key)関数の実行要求を受信した検索インタフェース部２２は、図９に示す処理を行い、その実行結果として取得したvalue、つまり、ダウンロード対象のファイルを記憶しているストレージサーバー装置１のサーバーアドレス、および、ファイルのバージョン番号を取得する（ステップＳ２６−１）。

次に、パス検索部５は、キャッシュ蓄積部３５にダウンロード対象ファイルのファイル名と同じファイル名のファイルが記憶されているかにより、ダウンロード済みかどうかをチェックする（ステップＳ２６−２）。すでにダウンロード済み（ステップＳ２６−２：ＹＥＳ）の場合には、キャッシュ蓄積部３５に記憶されているダウンロード済みファイルのバージョン番号と、ステップＳ２６−１において取得したバージョン番号とが同じであるかを判断する（ステップＳ２６−３）。バージョン番号が同じ場合には（ステップＳ２６−３：ＹＥＳ）、キャッシュ蓄積部３５に記憶されているダウンロードファイルを読み出して用いる。

一方、キャッシュ蓄積部３５にダウンロードファイルが存在しないか（ステップＳ２６−２：No）、または、ダウンロード済みファイルのバージョン番号がステップＳ２６−１において取得したバージョン番号より古い場合（ステップＳ２６−３：ＮＯ）には、第１の実施形態と同様に、ダウンロード対象ファイルを記憶しているストレージサーバー装置１にlow_read関数の実行要求を出力し、ダウンロード対象ファイルの全データを、バージョン番号と併せて取得する。パス検索部５は、取得したダウンロード対象ファイルの全データを、バージョン番号と対応づけてファイル蓄積部３２に書き込む（ステップＳ２６−５）。

［２．４ 効果］
以上説明したように、第２の実施形態では、キャッシュ蓄積部３５に記憶したダウンロード済みファイルを利用することによって、パス検索部５のパス検索処理を高速にした分散ファイル管理システムを実現することができる。

［３． 第３の実施形態］
第１の実施形態では、ユーザ利用ファイルは、１ファイル１レコードとしていた。第３の実施形態では、分散ファイル管理システムにおいて、ユーザ利用ファイルをマルチレコードとして複数のストレージサーバー装置１に分散して記憶し、アクセスを可能としたものである。以下、第１の実施形態との差分について説明する。

［３．１ データ構成］
図２７は、第３の実施形態によるｉノードファイルのＸＭＬデータ記述例を示す図である。同図に示すように、第３の実施形態では、マルチレコードに対応するため、データファイルに紐付けされるｉノードファイルのＸＭＬデータのタグに、<record>タグを追加する。そして、ユーザ利用ファイルを分割した各レコード１ずつを１つのデータファイルとし、１つのｉノードファイルにこれら分割した各レコードのデータファイルを記述することによって、レコードに分割されたユーザ利用ファイルのデータ本体を管理する。
図２７においては、no＝0〜2の<record>タグが記述されており、３つのレコードに分割されたユーザ利用ファイルの例を図示している。ｉノードファイル内の<body>タグは、各レコードを記憶したデータファイルのファイル名、つまり、ファイル管理部３２で記憶されているファイル名を示している。

［３．２ ストレージサーバー装置１の動作］
図２８は、第３の実施形態による高レベルインタフェース部２４が実行するhi_read関数及びhi_write関数を示す図である。
同図に示すように、本実施形態では、マルチレコードでのファイル操作を行うため、高レベルインタフェース部２４のhi_read関数およびhi_write関数の引数として、レコード番号recnoを追加する。これにより、hi_read関数およびhi_write関数のデータの操作は、pathで示されるファイルの中のrecno番目のレコードを操作の対象とする。
また、hi_read関数およびhi_write関数の内部的な動作は、図１３に示す第１の実施形態におけるパス検索部５のパス検索動作のステップＳ１３−３において、ｉノードファイルのＸＭＬデータの解析を行ない、<body>タグを取得するときに、引数recnoで示されるレコード番号xの<record no="x">タグを検索する動作を追加するだけでよい。これにより、<body>タグ内における<record no="x">タグの要素内容で示されるファイル名を取得する。

［３．３ 効果］
以上説明したように、第３の実施形態によれば、マルチレコードに対応した分散ファイル管理システムを実現することができる。マルチレコード構造のファイルを利用する利用方法は、本発明を制限するものではないが、例えば、主データ（１つのレコードのデータ）に対して、データの変更を判断するための、チェックサムデータを他のレコードに記録する、主データのメタデータ（例えば、Ｍａｃｉｎｔｏｓｈ（登録商標）系のＯＳにおけるリソースフォークのようなアイコンやウインドウの形状などのデータ）を記録する、ＢＴＲＯＮ系ＯＳで用いられているように、機能によってレコード番号を決めて利用するなどがある。また、ＧＦＳやＧｆｒａｍのようにファイルのデータを複数のチャンクに分割して記憶することと同様な動作もマルチレコードのファイル構造により実現できる。

［４． 第４の実施形態］
第４の実施形態は、分散ファイル管理システムにおいて、ファイルに対して任意のメタデータを付加できるようにしたものである。そこで本実施形態では、ファイルおよびディレクトリに任意のメタデータを付加するため、ｉノードファイルのＸＭＬデータに任意のタグを追加する機能を分散ファイル管理システムに備える。以下、第１の実施形態との差分について説明する。

［４．１ データ構成］
図２９に、メタデータを追加したｉノードファイルの例を示す。同図に示すように、ｉノードファイルに、作成者を記述する<access>タグが追加され、要素内容にメタデータ「userA」が記述されている。ここでは、タグを<access>としているが、下記の手順により、予め決められた予約されているタグ（inode、type、body等）以外の任意のタグを追加することができる。

［４．２ 高レベルインタフェースの追加関数］
第４の実施形態では、高レベルインタフェース部２４の関数として、図３０に示すhi_read_param関数及びhi_write_param関数を追加する。

hi_read_parm関数は、指定したディレクトリまたはユーザ利用ファイルのｉノードファイルから、指定したメタデータを読み出すインタフェースである。hi_read_param関数の引数pathは、メタデータ読み出し対象のパス付きユーザ利用ファイル名、または、パス付きディレクトリ名を示す。引数meta_keyは、読み出し対象のメタデータのタグを示す。引数meta_valueは、読み出されたメタデータを示す。

hi_write_param関数は、指定したディレクトリまたはパス指定ファイルのｉノードファイルへ、指定したタグの指定したメタデータを書き込むインタフェースである。hi_write_param関数の引数pathは、メタデータ書き込み対象のパス付きユーザ利用ファイル名、または、パス付きディレクトリ名を示す。引数meta_keyは、メタデータ書き込む対象のタグを示す。引数meta_valueは、メタデータへ書き込む内容を示す。

［４．２．１ 引数meta_keyの説明］
hi_read_param関数およびhi_write_param関数の引数であるmeta_keyは、ｉノードファイルのＸＭＬデータに対応するものである。第４の実施形態におけるmeta_keyのフォーマットについて説明する。例えば、図２７で示したｉノードファイル「R.ino」の場合、レコード番号１の<body>タグのデータを取得したい場合には、ＸＭＬデータを「/」で階層的に表現した、「/inode/record[1]/body」を引数meta_keyに設定し、hi_read_param関数を実行することで、引数meta_valueとして「B.dat」を得ることができる。
なお、ＸＭＬデータへのアクセスは他にもＷ３Ｃ（World Wide Web Consortium）で定められているＸＰａｔｈ（XML Path Language）などを使うことも可能であるが、本発明は特定のＸＭＬデータのハンドリング方法に依存するものではないので、これ以上の説明は行わない。

［４．３ ストレージサーバー装置１の動作］
［４．３．１ hi_read_param関数の動作］
次に、hi_read_paramの動作について説明する。図３１は、hi_read_param関数実行処理の流れ図である。
まず、高レベルインタフェース部２４は、引数pathにより指定された対象ユーザ利用ファイル名またはパス付きディレクトリ名と、パス検索の実行指示とをパス検索部５に出力する（ステップＳ３１−１）。これにより、指定した対象ユーザ利用ファイル名またはパス付きディレクトリ名のｉノードファイルがダウンロードされる。高レベルインタフェース部２４は、ダウンロードしたｉノードファイルから、引数meta_keyで指定されたタグのメタデータを検索し、その値を引数meta_valueに設定し、read_param関数の実行要求元へ返送する（ステップＳ３１−２）。

分散ファイル管理システムに図４のファイルが分散して記憶されている場合の、ファイル「F.ino」のみが図３０のものであったとする。そして、高レベルインタフェース部２４が、引数pathに「/work/fish.mxf」が、引数meta_keyに「/inode/access」が設定されたhi_read_param関数の実行要求を受信したとする。この場合、高レベルインタフェース部２４が、パス検索部５へパス検索をさせることにより、第１の実施形態で説明した動作例と同様の処理により、iノードファイル「F.ino」を取得する（ステップＳ３１−１）。高レベルインタフェース部２４は、引数meta_key「/inode/access」が設定されているタグ<inode>内のタグ<access>を特定すると、当該タグの設定内容「userA」を取得して引数meta_valueに設定し、read_param関数の実行要求元へ返送する（ステップＳ３１−２）。

［４．３．２ hi_write_param関数の動作］
次に、hi_write_param関数の動作について説明する。図３２は、hi_read_param関数の処理フローを示す。
まず、高レベルインタフェース部２４は、引数pathにより指定された対象ユーザ利用ファイル名またはパス付きディレクトリ名と、パス検索の実行指示とをパス検索部５に指示し、ｉノードファイルを取得し、記憶部３４に書き込む（ステップＳ３０−１）。高レベルインタフェース部２４は、取得したｉノードファイルのＸＭＬデータを解析して引数met_keyで指定されたタグを検索し、当該タグの要素内容を引数meta_valueに設定されている値に変更する（ステップＳ３０−２）。引数meta_keyで指定されたタグのメタデータが存在しない場合、高レベルインタフェース部２４は、ｉノードファイルに引数meta_keyにより指定されたメタデータを追加し、引数meta_valueに設定されている値を要素内容として書き込む。最後に、高レベルインタフェース部２４は、修正したｉノードファイルを、当該ｉノードファイルを記憶しているストレージサーバー装置１へアップロードする（ステップＳ３０−３）。

分散ファイル管理システムに図４のファイルが分散して記憶されているとする。そして、高レベルインタフェース部２４が、引数pathに「/work/fish.mxf」が、引数meta_keyに「/inode/access」が、引数meta_valueに「userA」が設定されたhi_write_param関数の実行要求を受信したものとする。この場合、高レベルインタフェース部２４が、パス検索部５へパス検索をさせることにより、第１の実施形態で説明した動作例と同様の処理により、iノードファイル「F.ino」を取得する（ステップＳ３２−１）。高レベルインタフェース部２４は、引数meta_key「access」が設定されているタグがないため、タグ<access>〜</access>を追加し、その要素内容に、引数meta_value「userA」を設定する（ステップＳ３２−２）。

［４．４ 効果］
以上説明したように、第４の実施形態により、ディレクトリ及びユーザ利用ファイルに任意のメタデータを追加し、利用することができる。このメタデータの利用方法は、自由であり、その内容で本発明が制限されるものではないが、利用方法の例として、ディレクトリやファイルのアクセス制御を行うためのメタデータを書き込むなどの利用方法が考えられる。
また、従来のローカルファイルシステムでは、ｉノード情報はディスクのフォーマット時に決められた固定したディスク領域に保存されるため、書き込めるデータ量に制限があり、任意のメタデータを追加することが困難であったが、第４の実施形態ではｉノードファイルを、データ書き込み可能なストレージサーバー装置１を選択して記憶させることができ、保存するデータ量に制限がないため、任意のメタデータの追加が可能となる。

［５． その他］
以上説明した本発明の実施形態によれば、Ｐ２Ｐ型の分散ストレージ装置において以下の特徴をもつ分散ファイル管理システムおよび分散ファイルシステムを提供できる。
すなわち、一元的に集中管理するサーバーを必要としないＰ２Ｐ型の分散ファイルシステムにおいて、ファイルの管理およびディレクトリの管理を提供することができる。
また、マルチレコード構造のファイルに対応した分散ファイル管理システムを提供することができる。
加えて、ノードデータには、ＸＭＬなどの拡張可能なマーク付け言語を利用して記述することにより、ファイルおよびディレクトリに関係する情報（メタデータ）を任意に拡張可能な分散ファイル管理システムを提供することができる。

なお、上述のストレージサーバー装置１は、内部にコンピュータシステムを有している。そして、ストレージサーバー装置１のファイル登録部３、ファイル入出力部４、パス検索部５、ファイル生成削除部６、サーバー選択部７、ＩＤ生成部８、所在検索部９、登録インタフェース部２１、検索インタフェース部２２、低レベルインタフェース部２３、及び、高レベルインタフェース部２４の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

１…ストレージサーバー装置
２…外部インタフェース部
３…ファイル登録部
４…ファイル入出力部
５…パス検索部
６…ファイル生成削除部
７…サーバー選択部
８…ＩＤ生成部
９…所在検索部
２１…登録インタフェース部
２２…検索インタフェース部
２３…低レベルインタフェース部
２４…高レベルインタフェース部
３１…ホストテーブル蓄積部
３２…ファイル蓄積部
３３…所在管理テーブル蓄積部
３４…記憶部
３５…キャッシュ蓄積部
５０…ユーザ端末装置
１００…ネットワーク装置

Claims (6)

1. 他のストレージサーバー装置と協同して、データファイルおよびディレクトリファイルを含むファイルを分散管理するストレージサーバー装置であって、
   配下のディレクトリ名とディレクトリファイルのファイル名との対応関係、および、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係に関する管理情報を含む前記ディレクトリファイルと、前記データファイルと、を記憶するファイル蓄積部と、
   ファイル名とファイルを記憶するストレージサーバー装置とを対応付けるテーブルを記憶する所在管理テーブル蓄積部と、
   当該ストレージサーバー装置が所在を管理する前記ファイルについて、指定されるファイル名に基づいて前記テーブルを参照することにより、前記ファイルを記憶するストレージサーバー装置を特定する所在検索部と、
   指定されたファイル名に基づいて前記ファイルの所在を管理するストレージサーバー装置を選択し、選択されたストレージサーバー装置の前記所在検索部に対して前記ファイルを記憶するストレージサーバー装置の特定を指示する検索インタフェース部と、
   ファイル名の指定に基づき前記ファイル蓄積部が記憶する前記ファイルに対する操作を行なう低レベルインタフェース部と、
   ファイル名を指定して前記ファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示し、特定されたストレージサーバー装置の前記低レベルインタフェース部に対してファイル名を指定した読出指示を行うことによって前記ディレクトリファイルを読み出し、読み出した前記ディレクトリファイル内の前記管理情報に基づいて、指定されたディレクトリ名またはユーザ利用ファイル名に対応するファイル名を取得するとともに、取得したファイル名が配下のディレクトリファイルのファイル名である場合には取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置から再帰的にディレクトリファイルの読み出しを行い、取得したファイル名が配下のデータファイルのファイル名である場合には取得した前記ファイル名を出力するパス検索部と、
   指定されたディレクトリ名およびユーザ利用ファイル名を用いて前記パス検索部から前記データファイルのファイル名を取得し、取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置の前記低レベルインタフェース部に操作指示を行う高レベルインタフェース部と、
   を備えることを特徴とするストレージサーバー装置。
2. 前記ファイル蓄積部は、ディレクトリファイルまたはデータファイルのファイル名を含むｉノードファイルを更に記憶し、
   前記ディレクトリファイル内の前記管理情報は、配下のディレクトリの前記ディレクトリ名または配下のデータファイルの前記ユーザ利用ファイル名と、対応する前記ｉノードファイルのファイル名との対応関係を含むものであり、
   前記パス検索部は、読み出した前記ディレクトリファイルから、指定された前記ディレクトリ名または前記ユーザ利用ファイル名に基づいて前記ｉノードファイルのファイル名を取得し、取得した前記ファイル名を指定して前記ｉノードファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示するとともに、特定されたストレージサーバー装置の前記低レベルインタフェース部に対して前記ファイル名を指定した読出指示を行うことにより前記ｉノードファイルを読み出し、読み出した前記ｉノードファイルから前記ディレクトリファイルまたは前記データファイルの前記ファイル名を取得する、
   ことを特徴とする請求項１に記載のストレージサーバー装置。
3. 読み出したファイルを記憶するキャッシュ蓄積部をさらに有し、
   前記パス検索部は、読み出した前記ｉノードファイルまたは前記ディレクトリファイルを前記キャッシュ蓄積部に書き込み、取得した前記ファイル名のｉノードファイルまたはディレクトリファイルが前記キャッシュ蓄積部に記憶されている場合は、当該ｉノードファイルまたはディレクトリファイルを当該キャッシュ蓄積部から読み出す、
   ことを特徴とする請求項２に記載のストレージサーバー装置。
4. 前記ｉノードファイルは、複数に分割されたデータファイルのファイル名と、当該分割されたデータファイルの番号とを含み、
   前記ユーザ利用ファイル名には、前記分割されたデータファイルの番号が付加され、
   前記パス検索部は、指定された前記ユーザ利用ファイル名に基づいて読み出した前記ファイル名の前記ｉノードファイルから、前記データファイルの番号に対応したデータファイルのファイル名を出力する、
   ことを特徴とする請求項２または請求項３に記載のストレージサーバー装置。
5. 前記ｉノードファイルは、メタデータを含み、
   前記ファイル入出力部は、前記操作がメタデータの読み出しである場合、読み出した前記ｉノードファイルから前記メタデータを読み出し、前記操作がメタデータの書き込みである場合、読み出した前記ｉノードファイルへメタデータの書き込みを行なう、
   ことを特徴とする請求項２から請求項４のいずれかの項に記載のストレージサーバー装置。
6. 他のストレージサーバー装置と協同して、データファイルおよびディレクトリファイルを含むファイルを分散管理するストレージサーバー装置として用いられるコンピュータを、
   配下のディレクトリ名とディレクトリファイルのファイル名との対応関係、および、配下のユーザ利用ファイル名とデータファイルのファイル名との対応関係に関する管理情報を含む前記ディレクトリファイルと、前記データファイルと、を記憶するファイル蓄積部、
   ファイル名とファイルを記憶するストレージサーバー装置とを対応付けるテーブルを記憶する所在管理テーブル蓄積部、
   当該ストレージサーバー装置が所在を管理する前記ファイルについて、指定されるファイル名に基づいて前記テーブルを参照することにより、前記ファイルを記憶するストレージサーバー装置を特定する所在検索部、
   指定されたファイル名に基づいて前記ファイルの所在を管理するストレージサーバー装置を選択し、選択されたストレージサーバー装置の前記所在検索部に対して前記ファイルを記憶するストレージサーバー装置の特定を指示する検索インタフェース部、
   ファイル名の指定に基づき前記ファイル蓄積部が記憶する前記ファイルに対する操作を行なう低レベルインタフェース部、
   ファイル名を指定して前記ファイルを記憶するストレージサーバー装置を特定するよう前記検索インタフェース部に指示し、特定されたストレージサーバー装置の前記低レベルインタフェース部に対してファイル名を指定した読出指示を行うことによって前記ディレクトリファイルを読み出し、読み出した前記ディレクトリファイル内の前記管理情報に基づいて、指定されたディレクトリ名またはユーザ利用ファイル名に対応するファイル名を取得するとともに、取得したファイル名が配下のディレクトリファイルのファイル名である場合には取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置から再帰的にディレクトリファイルの読み出しを行い、取得したファイル名が配下のデータファイルのファイル名である場合には取得した前記ファイル名を出力するパス検索部、
   指定されたディレクトリ名およびユーザ利用ファイル名を用いて前記パス検索部から前記データファイルのファイル名を取得し、取得した前記ファイル名を指定して他のストレージサーバー装置または当該ストレージサーバー装置の前記低レベルインタフェース部に操作指示を行う高レベルインタフェース部、
   として機能させることを特徴とするコンピュータプログラム。

Images