分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法
【課題】クライアント側の変更を行うことなく、ＮＦＳやＣＩＦＳ等の従来プロトコルを用いて分散ファイルシステム（ＤＦＳ）にアクセスを行うこと。
【解決手段】ＤＦＳサーバに従来プロトコルを受け付け、それに対応する処理をＤＦＳに対して行うゲートウェイ部２５を設ける。ゲートウェイ部２５は、ＮＦＳやＣＩＦＳ等のファイルシステムに存在するディレクトリ構造をエミュレートする。また、ＤＦＳが追記型ファイルシステムである場合に、更新処理を新しい世代の作成処理に変換し、参照処理を世代管理されているファイル群の最新世代へのアクセスに変換する。そして、ゲートウェイ部２５は、ＤＦＳ処理部２６を介してファイルにアクセスする。
【解決手段】ＤＦＳサーバに従来プロトコルを受け付け、それに対応する処理をＤＦＳに対して行うゲートウェイ部２５を設ける。ゲートウェイ部２５は、ＮＦＳやＣＩＦＳ等のファイルシステムに存在するディレクトリ構造をエミュレートする。また、ＤＦＳが追記型ファイルシステムである場合に、更新処理を新しい世代の作成処理に変換し、参照処理を世代管理されているファイル群の最新世代へのアクセスに変換する。そして、ゲートウェイ部２５は、ＤＦＳ処理部２６を介してファイルにアクセスする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ファイルシステム（ＤＦＳ：ディストリビューティッドファイルシステム）、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法に係り、特に、ネットワーク上の複数のサーバにファイルを分散して格納することにより、１つのファイルシステムを構成する分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法に関する。
【背景技術】
【０００２】
ネットワークファイルシステムとして、ＮＦＳやＣＩＦＳ（コモンインターネットファイルシステム）と呼ばれるＵＮＩＸ（登録商標）等のＯＳ上に構築されたファイルシステムが知られている。これらのファイルシステムは、１つのサーバによって１つのファイルシステムを構成する集中型のファイルシステムであり、ファイルの実体がある特定のサーバ上に存在する。クライアントからファイルに対してアクセスを行う場合、各クライアントは、それぞれのプロトコルを用いてまずこのファイルの存在するサーバにアクセスを行う。そして、クライアントは、サーバ上でファイルを特定するために、ディレクトリ構造を用いる。
【０００３】
これに対して、ＯｃｅａｎＳｔｏｒｅ等のＤＦＳは、クライアントがファイルにアクセスを行う場合、サーバやパス名を特定する代わりに、ＧＵＩＤというシステムで一意に付けられた識別子を用いている。ＤＦＳの場合、ファイルは、ネットワーク上に存在する複数のＤＦＳサーバ上のいずれかにその実体が存在する。ファイルの実体は、１つのサーバだけが持っている必要はなく、複製として他のサーバ上に存在してもよい。また、ファイルの実体は、そのファイル全体を１つのＤＦＳサーバで保持する必要はなく、ファイルが幾つかの部分に分割され、１つのＤＦＳサーバにはその分割された１つの部分（フラグメントと呼ぶ）のみを存在させ、他のフラグメントを他のＤＦＳサーバ上に存在させてもよい。
【０００４】
ＤＦＳにおけるファイルにアクセスするクライアントは、ファイルに対する参照、書き込みを行う場合、ネットワーク上のいずれか１つのサーバに対し、ＧＵＩＤを指定してファイルを特定してアクセスする。
【０００５】
なお、本発明に近い従来技術として、ストレージサーバがあらゆる種類のユーザデータへの接続を担う通信インタフェースを備えたシステムが、例えば、特許文献１等に記載されて知られている。
【特許文献１】特開２０００−３３９０９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＤＦＳは、ＮＦＳやＣＩＦＳといったネットワークファイルシステムと異なる特性を持つため、ＤＦＳのファイルにアクセスを行うためには、専用のＤＦＳプロトコルを用いてアクセスを行わなければならない。このため、ＮＦＳやＣＩＦＳといったプロトコルのみを使用する従来のクライアントは、ＤＦＳのファイルに対してアクセスを行うことが不可能であり、従来から用いていたプログラムを改良する等、クライアント側をＤＦＳに対応させる変更を行う必要があった。
【０００７】
本発明の目的は、前述した点に鑑み、クライアント側の変更を行うことなく、従来プロトコルを用いてＤＦＳのファイルにアクセスを行うことを可能とした分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明によれば前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムにおいて、分散してファイルを格納している複数のＤＦＳサーバをネットワーク上に備え、前記複数のＤＦＳサーバの少なくとも１つが、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。
【０００９】
また、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムの分散してファイルを格納している分散ファイルシステムサーバにおいて、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。
【００１０】
さらに、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセス方法において、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスすることにより達成される。
【発明の効果】
【００１１】
以上説明したように本発明によれば、クライアント側の変更を行うことなく、ＮＦＳやＣＩＦＳ等の従来プロトコルを用いてＤＦＳ上のファイルにアクセスを行うことができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明による分散ファイルシステム（ＤＦＳ）及びＤＦＳサーバの実施形態を図面により詳細に説明する。
【００１３】
図１は本発明の一実施形態による分散ファイルシステムの構成例を示すブロック図である。図１において、１はネットワーク、２はＤＦＳサーバ、３はＤＦＳクライアント、４はＮＦＳクライアント、５はＣＩＦＳクライアントである。
【００１４】
図１に示す本発明の一実施形態による分散ファイルシステム（ＤＦＳ）は、ネットワーク１と、ネットワーク１に接続された複数のＤＦＳサーバ２と、ＤＦＳ用のプロトコルを用いてネットワーク１上のファイルシステムにアクセスを行うＤＦＳクライアント３と、ＮＦＳやＣＩＦＳといったネットワーク１上の１つのファイルサーバにより実現されたファイルシステムにアクセスを行うための従来プロトコルでアクセスを行う従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５とにより構成される。
【００１５】
図１に示すＤＦＳにおいて、ネットワーク１上のＤＦＳクライアント３は、専用のＤＦＳプロトコルを用いて１つのＤＦＳサーバ２に対してアクセスを行って、ファイルに対する参照や書き込みを行う。ＤＦＳ上のファイルには、システム内で一意に識別できる番号であるＧＵＩＤという識別子が付けられており、参照時にＤＦＳクライアント３からファイルを特定するために用いられる。ファイルに対するＧＵＩＤは、ファイルの書き込み時に、ＤＦＳサーバ２によって一意に割り当てられ、ＤＦＳクライアント３に書き込みの応答として知らされる。
【００１６】
詳述すれば、ＤＦＳクライアントは、ファイルに対する参照を行う場合、ネットワーク上のいずれか１つのＤＦＳサーバ２に対し、ＧＵＩＤを指定してファイルを特定してアクセスする。アクセスされたＤＦＳサーバ２は、自サーバ上にファイルの実体が存在しない場合、ファイルの実体が存在する他のＤＦＳサーバ２に対して問い合わせを行い、データを集めてファイルの実体を自ＤＦＳサーバ上に構築することにより、クライアントに対してアクセスを可能とさせる。
【００１７】
また、ＤＦＳクライアントは、ファイルの書き込みを行う場合、１つのＤＦＳサーバに対して書き込みのデータを送信する。書き込みの応答として、クライアントは、サーバからＧＵＩＤを受け取る。書き込んだファイルに対するアクセスは、このサーバから受け取ったＧＵＩＤを用いて行う。
【００１８】
ＤＦＳの場合、同一のファイルの実体が複数のＤＦＳサーバ上に存在することがある。このような状況で、クライアントが一度書き込まれたデータの内容を変更する更新書き込みを行った場合、各ＤＦＳサーバでファイルのデータの一貫性を保証するのが難しい。このため、ＤＦＳの中には、ＧＵＩＤで指定されるファイルへの書き込みを一度だけ行い、更新書き込みを存在させず、一度書き込んだ後は参照のみを可能とするようにしたものがある。このような特性のファイルシステムを追記型ファイルシステムと呼ぶ。
【００１９】
追記型ファイルシステムの場合、更新書き込みに当たるファイルの内容の変更は、新たなファイルの世代への書き込みに当たり、その書き込み、すなわち、新たな世代に対して、新たなＧＵＩＤが割り振られて行われることとなる。そして、これらの一連の世代はファイル群として管理される。
【００２０】
図１に示す本発明の実施形態によるＤＦＳは、前述したような追記型のファイルシステムであり、一度書き込みを行い、ＧＵＩＤを割り当てられたファイルに対して内容の更新を行うことができないものとする。その代わりに、図１に示すＤＦＳは、ファイルには世代が存在し、ファイルに対する更新書き込みに当たる処理が、新しい世代のファイルを作成することに相当する。各世代には、別のＧＵＩＤが割り当てられるが、世代の異なるファイルの集まりはファイル群として管理される。このファイル群に対しても一意に識別可能なファイル群識別子が割り当てられる。そして、ファイル群識別子と世代とを示す世代番号を指定することによりファイルを識別するＧＵＩＤを得ることができる。
【００２１】
図２はファイル群識別子と世代番号とからＧＵＩＤを求める方法の一例を説明する図である。図２に示すように、ＧＵＩＤとして、ＧＵＩＤの内上位のビットをファイル群識別子６１とし、残りの下位のビットを世代番号６２としたものを用いる。図２に示す例は、１つの例であり、ＧＵＩＤを別の方法で求めるようにしてもよい。
【００２２】
従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５は、ＤＦＳのプロトコルではない従来のネットワークファイルシステムのプロトコルを用いてファイルにアクセスを行う。通常、これらの従来プロトコルクライアントは、ファイルにアクセスを行う場合、すでに説明したように、ファイルを特定するためにディレクトリ構造を用いる。
【００２３】
図３は従来プロトコルクライアントが用いるディレクトリ構造について説明する図であり、図３を参照して、ディレクトリの構造について説明する。図３の中では、ディレクトリを実線で囲んだ四角で表し、ファイルを破線で囲んだ四角で表している。
【００２４】
全てのディレクトリは、ルートディレクトリ４１（“／”で示される）の配下に属す木構造で定義される。そして、全てのファイルは、この木構造のディレクトリのいずれかのディレクトリ（複数であってもよい）に属することになる。このような木構造のディレクトリは、１つのディレクトリ内のファイルに対して、一意に名前（ファイル名）を付けることができる形となっている。このため、ファイルを特定する場合には、ファイルの属するディレクトリを示すパス名とそのファイルのファイル名とを指定すればよいことになる。例えば、図３に示すファイル４５は、／ｄｉｒａ／ｄｉｒａ２／ｄｉｒａ２２／ｆｉｌｅ０００１ という形で特定することができる。従って、クライアントは、ファイルへの参照や更新といったアクセスを行う場合、そのファイルの存在するサーバに対してパス名とファイル名とを指定してファイルを特定し、その後にそのファイルの参照や更新の要求を行うことになる。
【００２５】
本発明の実施形態は、クライアント側に新たなソフトウェアを組み込む等の変更を不要とし、ＮＦＳやＣＩＦＳといった従来プロトコルクライアントがＤＦＳのファイルにアクセスを行うことを可能としており、次に、そのためのＤＦＳサーバの構成を説明する。
【００２６】
図４はＤＦＳサーバの構成を示すブロック図、図５はゲートウェイ部の構成を示すブロック図である。図４、図５において、２１はＤＦＳ制御部、２２はディスクドライブ、２３は主メモリ、２４はＯＳ、２５はゲートウェイ部、２６はＤＦＳ処理部、２７はディスクドライブ処理部、２８はＣＰＵ、２９はＨＤＤ、３１は従来プロトコル処理部、３２はＤＦＳアクセス部、３３はディレクトリ管理部である。
【００２７】
ＤＦＳサーバ２は、図４に示すように、サーバ全体の処理を実行するＣＰＵ２８と、主メモリ２３と、ファイルを格納するディスクを備えるディスクドライブ２２と、主メモリ２３に展開して使用されるＯＳ、アプリケーション等を格納するＨＤＤ２９とを備えて構成される。主メモリ２３内には、ＯＳ２４とＤＦＳ制御部２１とが構成され、また、ＤＦＳ制御部２１は、ゲートウェイ部２５と、ＤＦＳ処理部２６と、ディスクドライブ処理部２７とにより構成される。
【００２８】
ＤＦＳ制御部２１は、ＣＰＵ２８上でＤＦＳ機能を提供するプログラムが動作することによりＤＦＳのサーバとしての機能を果たす。そして、ＤＦＳ制御部２１は、ゲートウェイ部２５、ＤＦＳ処理部２６、ディスクドライブ処理部２７の処理により、ネットワーク１を介してクライアント（ＮＳＦクライアント４、ＣＩＳＦクライアント５等の従来プロトコルクライアント及びＤＦＳクライアント３）や、他のＤＦＳサーバ２からの要求に対して処理を行う。
【００２９】
ＤＦＳ処理部２６は、ＤＦＳプロトコルによる要求を受け付け、その要求に従ってディスクドライブ処理部２７や他のＤＦＳサーバ２に対して処理要求を行い、その結果から応答を作成して要求元に返す。
【００３０】
ゲートウェイ部２５は、ＮＦＳやＣＩＦＳといった従来プロトコルのネットワークファイルシステムに対するのと同一の要求をＮＦＳクライアントやＣＩＦＳクライアントから受け付け、その要求に従った処理を必要に応じて他の処理部に要求を行って処理した後、要求に対する処理の結果をＮＦＳクライアントやＣＩＦＳクライアントクライアントに応答として返す。
【００３１】
前述により、ＤＦＳサーバ２は、従来プロトコルクライアントからの要求に対して、従来プロトコルのファイルサーバと同様にアクセスを受け、同様に、応答することが可能となる。
【００３２】
ゲートウェイ部２５は、全てのＤＦＳサーバ２上に存在する必要はなく、従来プロトコルのクライアントからのアクセスポイントとなりうるＤＦＳサーバ２上にのみ存在すればよい。すなわち、ゲートウェイ部２５は、従来プロトコルのクライアントからアクセスが行われるＤＦＳサーバにのみ必要となる。このため、通常のＤＦＳクライアント３からアクセスを行う場合、ゲートウェイ部２５は必要ではない。
【００３３】
ゲートウェイ部２５は、図５に示すように、従来プロトコル処理部３１と、ＤＦＳアクセス部３２と、ディレクトリ管理部３３とにより構成される。
【００３４】
従来プロトコル処理部３１は、ＮＦＳクライアント、ＣＩＦＳクライアントからの従来プロトコルを受け付け、従来プロトコルに合った応答を返す処理を行う処理部である。この従来プロトコル処理部３１は、受け付けるプロトコル毎に存在し、対応するプロトコルの内容を判断し、要求に応じて他の処理部に処理の要求を行う。
【００３５】
ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求を受け付け、ＤＦＳ制御部２１内のＤＦＳ処理部２６との橋渡しを行う処理部である。すなわち、ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求に応じて、ＤＦＳに対する要求を作成し、ＤＦＳ処理部２６を介してＤＦＳのファイルにアクセスを行うための処理部である。
【００３６】
ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ構造上のファイルとＤＦＳでのファイル識別子であるＧＵＩＤとの対応を管理するための処理部である。従来プロトコルによるファイルの指定は、そのファイルが存在するディレクトリを示すパス名とディレクトリ内で一意のファイル名とにより行われる。これに対し、ＤＦＳによるファイルの指定は、ＧＵＩＤというシステム内で一意である識別子によって行われる。ＤＦＳは、従来プロトコルでのディレクトリに当たる構造を持っている場合、その構造を使用することにより、従来ファイルシステムのファイルとＧＵＩＤとの対応を取ることが可能である。しかし、ＤＦＳの中には、ディレクトリに当たる構造を有しないシステムも存在する。すなわち、このディレクトリに当たる構造を有しないＤＦＳは、ＧＵＩＤのみで全システム内でのファイルを一意に認識することができるため、ファイルのパスに当たる構造を必要としない。
【００３７】
このようなディレクトリ構造を持たないＤＦＳは、従来プロトコルでアクセスを行うことを可能とするために、ディレクトリ構造のパスで指定されるファイルとＧＵＩＤとの対応を取るための仕組みが必要である。これを行うディレクトリ管理部３３は、ディレクトリ構造のパスで指定されるファイルとＧＵＩＤとの対応を取るための仕組みを提供するものである。
【００３８】
ディレクトリ管理部３３は、従来プロトコルからのディレクトリ操作やディレクトリ情報の読み出し要求に対する処理を行う。このため、ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ管理情報と同等のディレクトリ管理情報を持つ。
【００３９】
図６はディレクトリ管理情報５０の構造を説明する図である。ディレクトリ管理情報５０は、複数のエントリ５１により構成されている。そして、エントリ５１は、図３により説明したディレクトリまたはファイル毎に存在する。
【００４０】
各エントリ５１は、そのディレクトリまたはファイルが属するディレクトリである親ディレクトリのエントリへのポインタであるｐ＿ｐａｒｅｎｔ５２と、そのエントリ５１がディレクトリの場合、そのディレクトリに属するディレクトリまたはファイルの１つへのポインタであるｐ＿ｓｕｂｄｉｒ５３と、同一のディレクトリのエントリ同士を指すポインタである ｐ＿ｃｈｉｌｄ５４と、ディレクトリまたはファイルの名前を格納するｆ＿ｎａｍｅ５５とを有する。また、エントリ５１がファイルの場合、ＤＦＳ上でそのファイルを識別するファイル群識別子がｆ＿ｉｄ５６に格納される。このディレクトリ管理情報５０の各エントリ５１は、ｐ＿ｐａｒｅｎｔ５２、ｐ＿ｓｕｂｄｉｒ５３、 ｐ＿ｃｈｉｌｄ５４の３種類のポインタによりディレクトリ構造に対応した構造に作成されている。そのため、パスに指定されたディレクトリのエントリについてポインタを順にたどっていくことにより目的のファイルのエントリ５１にたどり着くことが可能である。そして、そのエントリ５１には、ファイル群識別子が格納されているため、従来プロトコルのファイルシステムで指定するパス名とファイルから、ＤＦＳのファイル群識別子を求めることが可能である。
【００４１】
すなわち、いま、図６の最上段に示すエントリが、図３に示すルートエントリであるとすると、図６の中段に示すエントリは、図３に示すディレクトリｄｉｒａ、ｄｉｒｂ、ｆｉｌｅ１ 等に相当し、最上段に示すエントリのｐ＿ｓｕｂｄｉｒ５３がディレクトリｄｉｒａに相当する中段右側のエントリを指し示し、この中段右側のエントリの ｐ＿ｃｈｉｌｄ５４がディレクトリｄｉｒｂに相当する中段右側のエントリを指し示す。同様に、ディレクトリｄｉｒａに相当する中段右側のエントリのｐ＿ｓｕｂｄｉｒ５３がディレクトリｄｉｒａ１ に相当する下段のエントリを指すことになる。
【００４２】
従って、従来クライアントからのパス名とそのファイルのファイル名とが、図３で説明したように、例えば、／ｄｉｒａ／ｄｉｒａ２／ｄｉｒａ２２／ｆｉｌｅ０００１ と指定されたとき、ディレクトリに従って、順にエントリ５１を辿っていくことにより、ディレクトリまたはファイルの名前を格納するｆ＿ｎａｍｅ５５に指定されたファイル名を持つエントリを探すことができ、これにより、ファイル群識別子ｆ＿ｉｄ５６を得ることができる。
【００４３】
前述したようなディレクトリ管理情報５０へのファイルの登録は、次のような場合に行われる。１つ目は、従来プロトコルでファイルを作成する場合である。この場合、パス名とファイル名とが指定されてファイルが作成されるので、従来プロトコル処理部３１は、それに合わせてエントリを作成し、ディレクトリ管理情報５０のパス名に当たる位置にエントリを追加すればよい。２つ目は、ＤＦＳプロトコルでファイルを作成する場合である。この場合、そのままではディレクトリ管理情報５０が作成されないため、従来プロトコルからアクセスを行うことができない。そのため、ＤＦＳで作成したファイルに従来プロトコルからアクセスを行いたい場合、ＤＦＳ処理部２６は、ゲートウェイ部２５に対してディレクトリへの登録要求を行う必要がある。この登録要求は、ＤＦＳ処理部２６からパス名、ファイル名及び登録するファイルのファイル群識別子を指定してゲートウェイ部２５に行われる。
【００４４】
また、前述のディレクトリ管理情報５０は、システム内の各ＤＦＳサーバ２に存在するゲートウェイ部同士で通信する等により共有することができる。これにより、各アクセスポイントから同一のファイルシステムとしてアクセスを行うことが可能となる。または、各ＤＦＳサーバ２のそれぞれのゲートウェイ部２５が別個のディレクトリ管理情報５０を持つようにすることができ、これにより、それぞれのアクセスポイントで異なるファイルシステムとして見せることも可能である。
【００４５】
図７は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートであり、次に、これについて説明する。
【００４６】
（１）従来プロトコルで、あるディレクトリ内のファイルの参照を行う場合、従来プロトコルクライアント４または５は、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する参照を行うためのアクセスを行う。
【００４７】
（２）従来プロトコル処理部３１は、前述のようなファイルを特定した参照要求を受けた場合、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。ディレクトリ管理部３３は、従来のファイルシステムでディレクトリを１階層ずつたどるのと同様に、ディレクトリ管理部３３の持つディレクトリ管理情報５０のエントリについて順にポインタをたどって指定のファイルのエントリにたどり着く。そして、そのエントリから指定されたファイル名のファイル群識別子を得て、従来プロトコル処理部３１に返す（ステップ８１）。
【００４８】
（３）従来プロトコル処理部３１は、ＧＵＩＤを得るためにファイル群識別子の最新世代番号をＤＦＳアクセス部３２に対して問い合わせる。ＤＦＳアクセス部３２は、ＤＦＳのプロトコルを使用することにより、ファイル群識別子を管理する他のＤＦＳサーバ２に問い合わせる等の方法により最新の世代番号を求め、従来プロトコル処理部３１に返す（ステップ８２）。
【００４９】
（４）従来プロトコル処理部３１は、ステップ８１、８２で得たファイル群識別子と世代番号とからＧＵＩＤを求める（ステップ８３）。
【００５０】
（５）従来プロトコル処理部３１は、ステップ８３で求めたＧＵＩＤを使用してＤＦＳアクセス部３２に対してＧＵＩＤの読み出し要求を発行する。この要求を受けたＤＦＳアクセス部３２は、ＤＦＳプロトコルを使用してＤＦＳに対して要求を発行し読み出し要求に対するデータを得る（ステップ８４）。
【００５１】
（６）従来プロトコル処理部３１は、ステップ８４で、ＤＦＳアクセス部３２が読み出したデータを応答として、参照要求を行ったクライアントに返す（ステップ８５）。
【００５２】
図８は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートであり、次に、これについて説明する。
【００５３】
（１）従来プロトコルで、あるディレクトリ内のファイルの更新を行う場合、従来プロトコルクライアント４または５は、ファイル参照時と同様に、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する更新を行うためのアクセスを行う。
【００５４】
（２）従来プロトコル処理部３１は、前述のようなファイルを特定して更新要求を受けた場合、受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否か（これについての詳細は後述する）、すなわち、すでに更新中のデータに対する更新か否かを判定する（ステップ９１）。
【００５５】
（３）ステップ９１の判定で、すでに更新中のデータに対する更新ではなかった場合、従来プロトコル処理部３１は、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。そのため、従来プロトコル処理部３１は、参照処理の場合と同様に、ディレクトリ管理部３３にファイル群識別子を問い合わせる。更新書込みの場合、既に存在するファイルに対する書込みであるため、ディレクトリ管理テーブルにエントリが存在する。参照のときと同様に、このエントリを求めることで、ファイル群識別子を得ることができる。また、ファイルの新規作成の場合、新規に作成されるファイルに対するエントリは存在しない。この場合、ファイルの作成要求時に、ディレクトリ管理情報５０にエントリを作成して登録すると共に、ＤＦＳ処理部２６に対してもファイル作成要求を発行し、ＤＦＳ処理部２６からファイル群識別子を得る処理を行う必要がある。その後は、新しく作成したファイルに対して、更新時と同様に後述するステップ９５からの処理を行い、データの書込みを行えばよい（ステップ９２）。
【００５６】
（４）ファイル群識別子を得た後、ファイルの更新内容を書き込むために、ファイル識別子の指すファイル群に新しい世代を作成する必要がある。このために、従来プロトコル処理部３１は、ステップ９３で、ＤＦＳアクセス部３２に対して新世代作成の要求発行を依頼する（ステップ９３）。
【００５７】
（５）ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して新世代を登録し、得た世代番号を応答として従来プロトコル処理部３１に返す。従来プロトコル処理部３１は、この応答の世代番号とファイル群識別子からＧＵＩＤを得ることができる（ステップ９４）。
【００５８】
（６）従来プロトコルは、ファイルへの一連の更新でも、１度の処理要求で行われることは限らない。例えば、ＮＦＳでは設定によりサイズの変更が可能ではあるが、通常、更新要求は、８ＫＢ単位という決まった大きさ毎のファイルの更新処理として行われ、８ＫＢを越える更新を行う場合、複数の更新要求に分割されて行われる。例えば、２４ＫＢの更新を行いたいような場合、３つの８ＫＢの更新に分割されて行われることとなる。このような分割されて行われる更新要求毎に新たな世代番号が作成されるのを防ぐため、一旦ファイルの更新を開始すると、その更新が終了するまでファイルが更新中であることを記憶しておく必要がある。このため、従来プロトコル処理部３１は、更新を開始したファイルを後述するファイル監視テーブルに登録する（ステップ９５）。
【００５９】
（７）ステップ９１の判定で、すでに更新中のデータに対する更新であった場合、従来プロトコル処理部３１は、後述するファイル監視テーブルからＧＵＩＤを得る（ステップ９６）。
【００６０】
（８）従来プロトコル処理部３１は、ステップ９５の処理で、ファイル監視テーブルへの登録の後、または、ステップ９６の処理処理で、ファイル監視テーブルからＧＵＩＤを得た後、ステップ９７で、ＧＵＩＤを指定して更新要求のデータの書き込みをＤＦＳアクセス部３２に依頼する。ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して書き込みの要求を行う（ステップ９７）。
【００６１】
（９）書き込み終了後、従来プロトコル処理部３１は、ＤＦＳ処理部２６からの応答をＤＦＳアクセス部３２を介して受け取り、従来プロトコルクライアントに対して更新要求の完了の応答を返す（ステップ９８）。
【００６２】
図９はファイル監視テーブルの構造を説明する図である。このテーブル７０の各エントリは、更新中のファイルに対応する。エントリの内容は、ファイルを識別するための情報７２と、書き込み中のファイルの世代を表す世代番号７３からなる。ファイルを識別するための情報７２として、この図９ではディレクトリ情報のエントリへのポインタとしてｐ＿ｄｅｎｔｒｙを用いている。
【００６３】
受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否かは、ファイル監視テーブル７０に登録されている情報を調べることにより知ることができ、従来プロトコル処理部３１は、２つ目以降の要求である場合、新たに世代を作成しないようにする。このために、図８により説明した処理において、従来プロトコル処理部３１は、更新要求を受け取った場合、ステップ９１の処理で、ファイル監視テーブル７０を調べ、既に更新中のファイルに対する更新要求であるか否かをチェックしている。そして、更新中でない場合、前述したように、ステップ９２に進み、新世代を作成してデータの書き込みを行うことになる。また、既に更新中であった場合、ステップ９６で、ファイル監視テーブル７０からＧＵＩＤを得て、そのＧＵＩＤに対してステップ９７で、データの書き込み要求を行う。
【００６４】
ゲートウェイ部２５は、前述したようにしてファイルの更新要求を処理することが可能であるが、作成した新しい世代の登録を完了させるために、この世代への更新の終了をＤＦＳ処理部２６に通知する必要がある。このために、ゲートウェイ部２５は、従来プロトコルクライアントから従来プロトコルで送られてくる一連の更新要求の終了を監視する必要がある。
【００６５】
この一連の更新要求の終了を示すトリガは、それぞれのプロトコルにより異なる。例えば、ＣＩＦＳのように、ファイルに対して操作を行うときにオープンし、終了するときにクローズを行うような、ファイル操作中の状態を持つプロトコルである場合、操作終了のクローズ要求がこの更新要求の終了を示すトリガに当たる。これに対し、ＮＦＳは、ファイルのオープンやクローズに当たる操作がなく、ファイルが操作中であるか否かを示す状態を持たない。このようなプロトコルの場合、別のトリガで操作の終了を判断する必要がる。
【００６６】
この場合のトリガとしては複数の場合が考えられる。１つは、更新要求が到着する時間間隔である。従来プロトコルクライアントは、ゲートウェイ部２５に対して一連の更新を分割して発行するが、通常、分割された１つの更新要求が終了するとすぐに次の更新要求を発行する。このため、ゲートウェイ部２５は、更新要求が到着する時間間隔を監視し、ある一定時間以上次の更新要求が到着しない場合に、一連の更新要求が終了したとみなすことができる。また、別のトリガとしてコミットの要求が考えられる。例えば、ＮＦＳのバージョン３以降のものは、更新を行ったファイルの内容をディスクに反映させる方法としてコミットというコマンドが用意されている。コミットの発行契機は、特に規定されているわけではないが、通常、あるまとまった意味のある更新が終了した場合に発行される。このため、ゲートウェイ部２５は、このコミットの要求が到着した場合に一連の更新要求が終了したとみなすことができる。但し、コミットは、更新の終了時に必ず発行されるとは限らないので、このコミットのみをトリガとすると更新の終了を認識することができない場合があるので、先に説明した時間監視と組み合わせて用いる必要がある。
【００６７】
前述のようなトリガを監視して新しい世代作成の終了を判断する方法は、本来の一連の更新の終了以前にトリガだと認識し世代作成を終了してしまう可能性がある。例えば、一定時間をトリガとしている方法は、ネットワーク１の状態等の理由により次の更新要求の到着が遅れることにより、本来引き続いて行われている更新を終了と判断してしまう場合がある。しかし、このような場合でも、余計に世代が追加されてしまうだけで、ファイルの更新内容が失われなければ特に問題はない。一度途切れたと判断して世代作成を終了してしまった後、更新要求を受け取った場合、また新たに世代を作成してその世代に書き込みを行えばよい。
【００６８】
図１０は世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートであり、次に、これについて説明する。
【００６９】
ゲートウェイ部２５は、ステップ１０１で、前述したような更新終了のトリガ発生を待ち、トリガ発生時に処理を開始する。更新終了のトリガ発生があると、ステップ１０２で、従来プロトコル処理部３１は、ファイル監視テーブル７０を参照し、作成中の世代のＧＵＩＤを得る。ステップ１０３で、このＧＵＩＤに対して、ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に更新終了の要求を発行する。ＤＦＳ処理部２６での更新終了の処理が完了後、ステップ１０４で、従来プロトコル処理部３１は、ファイル監視テーブル７０から当該エントリを削除し、ファイルに対する更新中の状態を解除する。
【００７０】
前述のようにして、ゲートウェイ部２５は、従来プロトコルを用いるクライアント４、５からのＤＦＳのファイルに対するアクセスが可能である。
【００７１】
前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００７２】
前述で説明した実施形態は、ＤＦＳとして追記型のファイルシステムを前提として説明したが、本発明は、追記型でないＤＦＳに対しても適用することが可能である。この場合、ファイルの世代という考えはなく、ファイルが更新されてもＧＵＩＤの値は変化しない。そのため、ディレクトリ管理情報５０のｆ＿ｉｄ５６にファイル群識別子の代わりに直接ファイルのＧＵＩＤを持つようにすればよい。そして、図７におけるファイルの参照時のフローでは、ステップ８１でＧＵＩＤを得ることができ、ステップ８２とステップ８３とは不要となる。同様に、図８に示すファイルの更新時のフローでは、ステップ９２でＧＵＩＤを得ることになり、世代作成のステップ９３とＧＵＩＤを得るステップ９４とは不要となる。
【００７３】
また、前述した本発明の実施形態は、ゲートウェイ部２５をＤＦＳサーバ２内に内蔵させるとして説明したが、本発明は、ゲートウェイ部２５をＤＦＳサーバ２内に実装しなくてもよい。例えば、他の実装位置として、ネットワーク１上にゲートウェイ部２５の処理を行うゲートウェイサーバを持つ場合や、従来プロトコルクライアント４や５内に組み込むことが考えられる。
【００７４】
図１１は本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。図１１において、１１０はゲートウェイサーバであり、他の符号は図１の場合と同一である。
【００７５】
図１１に示す例は、前述で説明したゲートウェイ部２５をネットワーク１上に設けたゲートウェイサーバ１１０として備えた例である。この場合、従来プロトコルクライアント４や５は、ゲートウェイサーバ１１０に対してアクセスを行うことになる。そして、ゲートウェイサーバ１１０は、ＤＦＳサーバ２に対して、ＤＦＳプロトコルを用いてアクセスを行う。ゲートウェイサーバ１１０は、ゲートウェイ部２５と同等の処理を行う。
【００７６】
前述したゲートウェイ部２５のＤＦＳアクセス部３２は、ＤＦＳ処理部２６と連携して処理を行っていたが、図１１に示す例の場合、ＤＦＳサーバ２と別のサーバ上にゲートウェイ部の機能が実装されるため、前述した連携した処理をおこなうことが不可能となる。その代わりに、図１１に示す例のシステムは、ゲートウェイサーバ１１０内に設けられるＤＦＳアクセス部３２がＤＦＳクライアントとなり、ＤＦＳプロトコルを使用してＤＦＳサーバ２に要求を行うことにより同等の処理を行うことが可能である。
【００７７】
また、従来プロトコルクライアントに組み込む方法としては、例えば、ＮＦＳのプロトコル処理部にこのゲートウェイ部２５の機能を組み込むことが考えられる。この場合、上位のＮＦＳを使用するプログラムは、ＮＦＳのプロトコルを用いて処理を行って、ゲートウェイ部２５の機能がＮＦＳのプロトコルをＤＦＳプロトコルに変換し、ネットワーク１上ではＤＦＳのプロトコルを用いてＤＦＳサーバ２にアクセスを行うこととなる。
【００７８】
前述した本発明の実施形態によれば、ＮＦＳやＣＩＦＳ等の従来プロトコルのファイルシステムに存在するディレクトリ構造をエミュレートし、ディレクトリ構造上でファイルの存在する位置を示すパス名とファイルの名前であるファイル名とによりアクセスを行う方式を、ＤＦＳでのファイル識別子であるＧＵＩＤによるアクセスに変換することにより、従来プロトコルを使用してＤＦＳ上のファイルに対するアクセスを行うことができる。
【００７９】
また、本発明の実施形態によれば、ＤＦＳが追記型のファイルシステムである場合、従来プロトコルの更新処理を新しい世代の作成処理に変換することにより、参照時には、世代管理されているファイル群から最新の世代のファイルを求め、そのファイルのデータにアクセスを行うことが可能となる。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施形態による分散ファイルシステムの構成例を示すブロック図である。
【図２】ファイル群識別子と世代番号とからＧＵＩＤを求める方法の一例を説明する図である。
【図３】従来プロトコルクライアントが用いるディレクトリ構造について説明する図である。
【図４】ＤＦＳサーバの構成を示すブロック図である。
【図５】ゲートウェイ部の構成を示すブロック図である。
【図６】ディレクトリ管理情報５０の構造を説明する図である。
【図７】従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートである。
【図８】従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートである。
【図９】ファイル監視テーブルの構造を説明する図である。
【図１０】世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートである。
【図１１】本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。
【符号の説明】
【００８１】
１ ネットワーク
２ ＤＦＳサーバ
３ ＤＦＳクライアント
４ ＮＦＳクライアント
５ ＣＩＦＳクライアント
２１ ＤＦＳ制御部
２２ ディスクドライブ
２３ 主メモリ
２４ ＯＳ
２５ ゲートウェイ部
２６ ＤＦＳ処理部
２７ ディスクドライブ処理部
２８ ＣＰＵ
２９ ＨＤＤ
３１ 従来プロトコル処理部
３２ ＤＦＳアクセス部
３３ ディレクトリ管理部
１１０ ゲートウェイサーバ
【技術分野】
【０００１】
本発明は、分散ファイルシステム（ＤＦＳ：ディストリビューティッドファイルシステム）、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法に係り、特に、ネットワーク上の複数のサーバにファイルを分散して格納することにより、１つのファイルシステムを構成する分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法に関する。
【背景技術】
【０００２】
ネットワークファイルシステムとして、ＮＦＳやＣＩＦＳ（コモンインターネットファイルシステム）と呼ばれるＵＮＩＸ（登録商標）等のＯＳ上に構築されたファイルシステムが知られている。これらのファイルシステムは、１つのサーバによって１つのファイルシステムを構成する集中型のファイルシステムであり、ファイルの実体がある特定のサーバ上に存在する。クライアントからファイルに対してアクセスを行う場合、各クライアントは、それぞれのプロトコルを用いてまずこのファイルの存在するサーバにアクセスを行う。そして、クライアントは、サーバ上でファイルを特定するために、ディレクトリ構造を用いる。
【０００３】
これに対して、ＯｃｅａｎＳｔｏｒｅ等のＤＦＳは、クライアントがファイルにアクセスを行う場合、サーバやパス名を特定する代わりに、ＧＵＩＤというシステムで一意に付けられた識別子を用いている。ＤＦＳの場合、ファイルは、ネットワーク上に存在する複数のＤＦＳサーバ上のいずれかにその実体が存在する。ファイルの実体は、１つのサーバだけが持っている必要はなく、複製として他のサーバ上に存在してもよい。また、ファイルの実体は、そのファイル全体を１つのＤＦＳサーバで保持する必要はなく、ファイルが幾つかの部分に分割され、１つのＤＦＳサーバにはその分割された１つの部分（フラグメントと呼ぶ）のみを存在させ、他のフラグメントを他のＤＦＳサーバ上に存在させてもよい。
【０００４】
ＤＦＳにおけるファイルにアクセスするクライアントは、ファイルに対する参照、書き込みを行う場合、ネットワーク上のいずれか１つのサーバに対し、ＧＵＩＤを指定してファイルを特定してアクセスする。
【０００５】
なお、本発明に近い従来技術として、ストレージサーバがあらゆる種類のユーザデータへの接続を担う通信インタフェースを備えたシステムが、例えば、特許文献１等に記載されて知られている。
【特許文献１】特開２０００−３３９０９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＤＦＳは、ＮＦＳやＣＩＦＳといったネットワークファイルシステムと異なる特性を持つため、ＤＦＳのファイルにアクセスを行うためには、専用のＤＦＳプロトコルを用いてアクセスを行わなければならない。このため、ＮＦＳやＣＩＦＳといったプロトコルのみを使用する従来のクライアントは、ＤＦＳのファイルに対してアクセスを行うことが不可能であり、従来から用いていたプログラムを改良する等、クライアント側をＤＦＳに対応させる変更を行う必要があった。
【０００７】
本発明の目的は、前述した点に鑑み、クライアント側の変更を行うことなく、従来プロトコルを用いてＤＦＳのファイルにアクセスを行うことを可能とした分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明によれば前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムにおいて、分散してファイルを格納している複数のＤＦＳサーバをネットワーク上に備え、前記複数のＤＦＳサーバの少なくとも１つが、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。
【０００９】
また、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムの分散してファイルを格納している分散ファイルシステムサーバにおいて、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。
【００１０】
さらに、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセス方法において、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスすることにより達成される。
【発明の効果】
【００１１】
以上説明したように本発明によれば、クライアント側の変更を行うことなく、ＮＦＳやＣＩＦＳ等の従来プロトコルを用いてＤＦＳ上のファイルにアクセスを行うことができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明による分散ファイルシステム（ＤＦＳ）及びＤＦＳサーバの実施形態を図面により詳細に説明する。
【００１３】
図１は本発明の一実施形態による分散ファイルシステムの構成例を示すブロック図である。図１において、１はネットワーク、２はＤＦＳサーバ、３はＤＦＳクライアント、４はＮＦＳクライアント、５はＣＩＦＳクライアントである。
【００１４】
図１に示す本発明の一実施形態による分散ファイルシステム（ＤＦＳ）は、ネットワーク１と、ネットワーク１に接続された複数のＤＦＳサーバ２と、ＤＦＳ用のプロトコルを用いてネットワーク１上のファイルシステムにアクセスを行うＤＦＳクライアント３と、ＮＦＳやＣＩＦＳといったネットワーク１上の１つのファイルサーバにより実現されたファイルシステムにアクセスを行うための従来プロトコルでアクセスを行う従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５とにより構成される。
【００１５】
図１に示すＤＦＳにおいて、ネットワーク１上のＤＦＳクライアント３は、専用のＤＦＳプロトコルを用いて１つのＤＦＳサーバ２に対してアクセスを行って、ファイルに対する参照や書き込みを行う。ＤＦＳ上のファイルには、システム内で一意に識別できる番号であるＧＵＩＤという識別子が付けられており、参照時にＤＦＳクライアント３からファイルを特定するために用いられる。ファイルに対するＧＵＩＤは、ファイルの書き込み時に、ＤＦＳサーバ２によって一意に割り当てられ、ＤＦＳクライアント３に書き込みの応答として知らされる。
【００１６】
詳述すれば、ＤＦＳクライアントは、ファイルに対する参照を行う場合、ネットワーク上のいずれか１つのＤＦＳサーバ２に対し、ＧＵＩＤを指定してファイルを特定してアクセスする。アクセスされたＤＦＳサーバ２は、自サーバ上にファイルの実体が存在しない場合、ファイルの実体が存在する他のＤＦＳサーバ２に対して問い合わせを行い、データを集めてファイルの実体を自ＤＦＳサーバ上に構築することにより、クライアントに対してアクセスを可能とさせる。
【００１７】
また、ＤＦＳクライアントは、ファイルの書き込みを行う場合、１つのＤＦＳサーバに対して書き込みのデータを送信する。書き込みの応答として、クライアントは、サーバからＧＵＩＤを受け取る。書き込んだファイルに対するアクセスは、このサーバから受け取ったＧＵＩＤを用いて行う。
【００１８】
ＤＦＳの場合、同一のファイルの実体が複数のＤＦＳサーバ上に存在することがある。このような状況で、クライアントが一度書き込まれたデータの内容を変更する更新書き込みを行った場合、各ＤＦＳサーバでファイルのデータの一貫性を保証するのが難しい。このため、ＤＦＳの中には、ＧＵＩＤで指定されるファイルへの書き込みを一度だけ行い、更新書き込みを存在させず、一度書き込んだ後は参照のみを可能とするようにしたものがある。このような特性のファイルシステムを追記型ファイルシステムと呼ぶ。
【００１９】
追記型ファイルシステムの場合、更新書き込みに当たるファイルの内容の変更は、新たなファイルの世代への書き込みに当たり、その書き込み、すなわち、新たな世代に対して、新たなＧＵＩＤが割り振られて行われることとなる。そして、これらの一連の世代はファイル群として管理される。
【００２０】
図１に示す本発明の実施形態によるＤＦＳは、前述したような追記型のファイルシステムであり、一度書き込みを行い、ＧＵＩＤを割り当てられたファイルに対して内容の更新を行うことができないものとする。その代わりに、図１に示すＤＦＳは、ファイルには世代が存在し、ファイルに対する更新書き込みに当たる処理が、新しい世代のファイルを作成することに相当する。各世代には、別のＧＵＩＤが割り当てられるが、世代の異なるファイルの集まりはファイル群として管理される。このファイル群に対しても一意に識別可能なファイル群識別子が割り当てられる。そして、ファイル群識別子と世代とを示す世代番号を指定することによりファイルを識別するＧＵＩＤを得ることができる。
【００２１】
図２はファイル群識別子と世代番号とからＧＵＩＤを求める方法の一例を説明する図である。図２に示すように、ＧＵＩＤとして、ＧＵＩＤの内上位のビットをファイル群識別子６１とし、残りの下位のビットを世代番号６２としたものを用いる。図２に示す例は、１つの例であり、ＧＵＩＤを別の方法で求めるようにしてもよい。
【００２２】
従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５は、ＤＦＳのプロトコルではない従来のネットワークファイルシステムのプロトコルを用いてファイルにアクセスを行う。通常、これらの従来プロトコルクライアントは、ファイルにアクセスを行う場合、すでに説明したように、ファイルを特定するためにディレクトリ構造を用いる。
【００２３】
図３は従来プロトコルクライアントが用いるディレクトリ構造について説明する図であり、図３を参照して、ディレクトリの構造について説明する。図３の中では、ディレクトリを実線で囲んだ四角で表し、ファイルを破線で囲んだ四角で表している。
【００２４】
全てのディレクトリは、ルートディレクトリ４１（“／”で示される）の配下に属す木構造で定義される。そして、全てのファイルは、この木構造のディレクトリのいずれかのディレクトリ（複数であってもよい）に属することになる。このような木構造のディレクトリは、１つのディレクトリ内のファイルに対して、一意に名前（ファイル名）を付けることができる形となっている。このため、ファイルを特定する場合には、ファイルの属するディレクトリを示すパス名とそのファイルのファイル名とを指定すればよいことになる。例えば、図３に示すファイル４５は、／ｄｉｒａ／ｄｉｒａ２／ｄｉｒａ２２／ｆｉｌｅ０００１ という形で特定することができる。従って、クライアントは、ファイルへの参照や更新といったアクセスを行う場合、そのファイルの存在するサーバに対してパス名とファイル名とを指定してファイルを特定し、その後にそのファイルの参照や更新の要求を行うことになる。
【００２５】
本発明の実施形態は、クライアント側に新たなソフトウェアを組み込む等の変更を不要とし、ＮＦＳやＣＩＦＳといった従来プロトコルクライアントがＤＦＳのファイルにアクセスを行うことを可能としており、次に、そのためのＤＦＳサーバの構成を説明する。
【００２６】
図４はＤＦＳサーバの構成を示すブロック図、図５はゲートウェイ部の構成を示すブロック図である。図４、図５において、２１はＤＦＳ制御部、２２はディスクドライブ、２３は主メモリ、２４はＯＳ、２５はゲートウェイ部、２６はＤＦＳ処理部、２７はディスクドライブ処理部、２８はＣＰＵ、２９はＨＤＤ、３１は従来プロトコル処理部、３２はＤＦＳアクセス部、３３はディレクトリ管理部である。
【００２７】
ＤＦＳサーバ２は、図４に示すように、サーバ全体の処理を実行するＣＰＵ２８と、主メモリ２３と、ファイルを格納するディスクを備えるディスクドライブ２２と、主メモリ２３に展開して使用されるＯＳ、アプリケーション等を格納するＨＤＤ２９とを備えて構成される。主メモリ２３内には、ＯＳ２４とＤＦＳ制御部２１とが構成され、また、ＤＦＳ制御部２１は、ゲートウェイ部２５と、ＤＦＳ処理部２６と、ディスクドライブ処理部２７とにより構成される。
【００２８】
ＤＦＳ制御部２１は、ＣＰＵ２８上でＤＦＳ機能を提供するプログラムが動作することによりＤＦＳのサーバとしての機能を果たす。そして、ＤＦＳ制御部２１は、ゲートウェイ部２５、ＤＦＳ処理部２６、ディスクドライブ処理部２７の処理により、ネットワーク１を介してクライアント（ＮＳＦクライアント４、ＣＩＳＦクライアント５等の従来プロトコルクライアント及びＤＦＳクライアント３）や、他のＤＦＳサーバ２からの要求に対して処理を行う。
【００２９】
ＤＦＳ処理部２６は、ＤＦＳプロトコルによる要求を受け付け、その要求に従ってディスクドライブ処理部２７や他のＤＦＳサーバ２に対して処理要求を行い、その結果から応答を作成して要求元に返す。
【００３０】
ゲートウェイ部２５は、ＮＦＳやＣＩＦＳといった従来プロトコルのネットワークファイルシステムに対するのと同一の要求をＮＦＳクライアントやＣＩＦＳクライアントから受け付け、その要求に従った処理を必要に応じて他の処理部に要求を行って処理した後、要求に対する処理の結果をＮＦＳクライアントやＣＩＦＳクライアントクライアントに応答として返す。
【００３１】
前述により、ＤＦＳサーバ２は、従来プロトコルクライアントからの要求に対して、従来プロトコルのファイルサーバと同様にアクセスを受け、同様に、応答することが可能となる。
【００３２】
ゲートウェイ部２５は、全てのＤＦＳサーバ２上に存在する必要はなく、従来プロトコルのクライアントからのアクセスポイントとなりうるＤＦＳサーバ２上にのみ存在すればよい。すなわち、ゲートウェイ部２５は、従来プロトコルのクライアントからアクセスが行われるＤＦＳサーバにのみ必要となる。このため、通常のＤＦＳクライアント３からアクセスを行う場合、ゲートウェイ部２５は必要ではない。
【００３３】
ゲートウェイ部２５は、図５に示すように、従来プロトコル処理部３１と、ＤＦＳアクセス部３２と、ディレクトリ管理部３３とにより構成される。
【００３４】
従来プロトコル処理部３１は、ＮＦＳクライアント、ＣＩＦＳクライアントからの従来プロトコルを受け付け、従来プロトコルに合った応答を返す処理を行う処理部である。この従来プロトコル処理部３１は、受け付けるプロトコル毎に存在し、対応するプロトコルの内容を判断し、要求に応じて他の処理部に処理の要求を行う。
【００３５】
ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求を受け付け、ＤＦＳ制御部２１内のＤＦＳ処理部２６との橋渡しを行う処理部である。すなわち、ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求に応じて、ＤＦＳに対する要求を作成し、ＤＦＳ処理部２６を介してＤＦＳのファイルにアクセスを行うための処理部である。
【００３６】
ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ構造上のファイルとＤＦＳでのファイル識別子であるＧＵＩＤとの対応を管理するための処理部である。従来プロトコルによるファイルの指定は、そのファイルが存在するディレクトリを示すパス名とディレクトリ内で一意のファイル名とにより行われる。これに対し、ＤＦＳによるファイルの指定は、ＧＵＩＤというシステム内で一意である識別子によって行われる。ＤＦＳは、従来プロトコルでのディレクトリに当たる構造を持っている場合、その構造を使用することにより、従来ファイルシステムのファイルとＧＵＩＤとの対応を取ることが可能である。しかし、ＤＦＳの中には、ディレクトリに当たる構造を有しないシステムも存在する。すなわち、このディレクトリに当たる構造を有しないＤＦＳは、ＧＵＩＤのみで全システム内でのファイルを一意に認識することができるため、ファイルのパスに当たる構造を必要としない。
【００３７】
このようなディレクトリ構造を持たないＤＦＳは、従来プロトコルでアクセスを行うことを可能とするために、ディレクトリ構造のパスで指定されるファイルとＧＵＩＤとの対応を取るための仕組みが必要である。これを行うディレクトリ管理部３３は、ディレクトリ構造のパスで指定されるファイルとＧＵＩＤとの対応を取るための仕組みを提供するものである。
【００３８】
ディレクトリ管理部３３は、従来プロトコルからのディレクトリ操作やディレクトリ情報の読み出し要求に対する処理を行う。このため、ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ管理情報と同等のディレクトリ管理情報を持つ。
【００３９】
図６はディレクトリ管理情報５０の構造を説明する図である。ディレクトリ管理情報５０は、複数のエントリ５１により構成されている。そして、エントリ５１は、図３により説明したディレクトリまたはファイル毎に存在する。
【００４０】
各エントリ５１は、そのディレクトリまたはファイルが属するディレクトリである親ディレクトリのエントリへのポインタであるｐ＿ｐａｒｅｎｔ５２と、そのエントリ５１がディレクトリの場合、そのディレクトリに属するディレクトリまたはファイルの１つへのポインタであるｐ＿ｓｕｂｄｉｒ５３と、同一のディレクトリのエントリ同士を指すポインタである ｐ＿ｃｈｉｌｄ５４と、ディレクトリまたはファイルの名前を格納するｆ＿ｎａｍｅ５５とを有する。また、エントリ５１がファイルの場合、ＤＦＳ上でそのファイルを識別するファイル群識別子がｆ＿ｉｄ５６に格納される。このディレクトリ管理情報５０の各エントリ５１は、ｐ＿ｐａｒｅｎｔ５２、ｐ＿ｓｕｂｄｉｒ５３、 ｐ＿ｃｈｉｌｄ５４の３種類のポインタによりディレクトリ構造に対応した構造に作成されている。そのため、パスに指定されたディレクトリのエントリについてポインタを順にたどっていくことにより目的のファイルのエントリ５１にたどり着くことが可能である。そして、そのエントリ５１には、ファイル群識別子が格納されているため、従来プロトコルのファイルシステムで指定するパス名とファイルから、ＤＦＳのファイル群識別子を求めることが可能である。
【００４１】
すなわち、いま、図６の最上段に示すエントリが、図３に示すルートエントリであるとすると、図６の中段に示すエントリは、図３に示すディレクトリｄｉｒａ、ｄｉｒｂ、ｆｉｌｅ１ 等に相当し、最上段に示すエントリのｐ＿ｓｕｂｄｉｒ５３がディレクトリｄｉｒａに相当する中段右側のエントリを指し示し、この中段右側のエントリの ｐ＿ｃｈｉｌｄ５４がディレクトリｄｉｒｂに相当する中段右側のエントリを指し示す。同様に、ディレクトリｄｉｒａに相当する中段右側のエントリのｐ＿ｓｕｂｄｉｒ５３がディレクトリｄｉｒａ１ に相当する下段のエントリを指すことになる。
【００４２】
従って、従来クライアントからのパス名とそのファイルのファイル名とが、図３で説明したように、例えば、／ｄｉｒａ／ｄｉｒａ２／ｄｉｒａ２２／ｆｉｌｅ０００１ と指定されたとき、ディレクトリに従って、順にエントリ５１を辿っていくことにより、ディレクトリまたはファイルの名前を格納するｆ＿ｎａｍｅ５５に指定されたファイル名を持つエントリを探すことができ、これにより、ファイル群識別子ｆ＿ｉｄ５６を得ることができる。
【００４３】
前述したようなディレクトリ管理情報５０へのファイルの登録は、次のような場合に行われる。１つ目は、従来プロトコルでファイルを作成する場合である。この場合、パス名とファイル名とが指定されてファイルが作成されるので、従来プロトコル処理部３１は、それに合わせてエントリを作成し、ディレクトリ管理情報５０のパス名に当たる位置にエントリを追加すればよい。２つ目は、ＤＦＳプロトコルでファイルを作成する場合である。この場合、そのままではディレクトリ管理情報５０が作成されないため、従来プロトコルからアクセスを行うことができない。そのため、ＤＦＳで作成したファイルに従来プロトコルからアクセスを行いたい場合、ＤＦＳ処理部２６は、ゲートウェイ部２５に対してディレクトリへの登録要求を行う必要がある。この登録要求は、ＤＦＳ処理部２６からパス名、ファイル名及び登録するファイルのファイル群識別子を指定してゲートウェイ部２５に行われる。
【００４４】
また、前述のディレクトリ管理情報５０は、システム内の各ＤＦＳサーバ２に存在するゲートウェイ部同士で通信する等により共有することができる。これにより、各アクセスポイントから同一のファイルシステムとしてアクセスを行うことが可能となる。または、各ＤＦＳサーバ２のそれぞれのゲートウェイ部２５が別個のディレクトリ管理情報５０を持つようにすることができ、これにより、それぞれのアクセスポイントで異なるファイルシステムとして見せることも可能である。
【００４５】
図７は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートであり、次に、これについて説明する。
【００４６】
（１）従来プロトコルで、あるディレクトリ内のファイルの参照を行う場合、従来プロトコルクライアント４または５は、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する参照を行うためのアクセスを行う。
【００４７】
（２）従来プロトコル処理部３１は、前述のようなファイルを特定した参照要求を受けた場合、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。ディレクトリ管理部３３は、従来のファイルシステムでディレクトリを１階層ずつたどるのと同様に、ディレクトリ管理部３３の持つディレクトリ管理情報５０のエントリについて順にポインタをたどって指定のファイルのエントリにたどり着く。そして、そのエントリから指定されたファイル名のファイル群識別子を得て、従来プロトコル処理部３１に返す（ステップ８１）。
【００４８】
（３）従来プロトコル処理部３１は、ＧＵＩＤを得るためにファイル群識別子の最新世代番号をＤＦＳアクセス部３２に対して問い合わせる。ＤＦＳアクセス部３２は、ＤＦＳのプロトコルを使用することにより、ファイル群識別子を管理する他のＤＦＳサーバ２に問い合わせる等の方法により最新の世代番号を求め、従来プロトコル処理部３１に返す（ステップ８２）。
【００４９】
（４）従来プロトコル処理部３１は、ステップ８１、８２で得たファイル群識別子と世代番号とからＧＵＩＤを求める（ステップ８３）。
【００５０】
（５）従来プロトコル処理部３１は、ステップ８３で求めたＧＵＩＤを使用してＤＦＳアクセス部３２に対してＧＵＩＤの読み出し要求を発行する。この要求を受けたＤＦＳアクセス部３２は、ＤＦＳプロトコルを使用してＤＦＳに対して要求を発行し読み出し要求に対するデータを得る（ステップ８４）。
【００５１】
（６）従来プロトコル処理部３１は、ステップ８４で、ＤＦＳアクセス部３２が読み出したデータを応答として、参照要求を行ったクライアントに返す（ステップ８５）。
【００５２】
図８は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートであり、次に、これについて説明する。
【００５３】
（１）従来プロトコルで、あるディレクトリ内のファイルの更新を行う場合、従来プロトコルクライアント４または５は、ファイル参照時と同様に、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する更新を行うためのアクセスを行う。
【００５４】
（２）従来プロトコル処理部３１は、前述のようなファイルを特定して更新要求を受けた場合、受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否か（これについての詳細は後述する）、すなわち、すでに更新中のデータに対する更新か否かを判定する（ステップ９１）。
【００５５】
（３）ステップ９１の判定で、すでに更新中のデータに対する更新ではなかった場合、従来プロトコル処理部３１は、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。そのため、従来プロトコル処理部３１は、参照処理の場合と同様に、ディレクトリ管理部３３にファイル群識別子を問い合わせる。更新書込みの場合、既に存在するファイルに対する書込みであるため、ディレクトリ管理テーブルにエントリが存在する。参照のときと同様に、このエントリを求めることで、ファイル群識別子を得ることができる。また、ファイルの新規作成の場合、新規に作成されるファイルに対するエントリは存在しない。この場合、ファイルの作成要求時に、ディレクトリ管理情報５０にエントリを作成して登録すると共に、ＤＦＳ処理部２６に対してもファイル作成要求を発行し、ＤＦＳ処理部２６からファイル群識別子を得る処理を行う必要がある。その後は、新しく作成したファイルに対して、更新時と同様に後述するステップ９５からの処理を行い、データの書込みを行えばよい（ステップ９２）。
【００５６】
（４）ファイル群識別子を得た後、ファイルの更新内容を書き込むために、ファイル識別子の指すファイル群に新しい世代を作成する必要がある。このために、従来プロトコル処理部３１は、ステップ９３で、ＤＦＳアクセス部３２に対して新世代作成の要求発行を依頼する（ステップ９３）。
【００５７】
（５）ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して新世代を登録し、得た世代番号を応答として従来プロトコル処理部３１に返す。従来プロトコル処理部３１は、この応答の世代番号とファイル群識別子からＧＵＩＤを得ることができる（ステップ９４）。
【００５８】
（６）従来プロトコルは、ファイルへの一連の更新でも、１度の処理要求で行われることは限らない。例えば、ＮＦＳでは設定によりサイズの変更が可能ではあるが、通常、更新要求は、８ＫＢ単位という決まった大きさ毎のファイルの更新処理として行われ、８ＫＢを越える更新を行う場合、複数の更新要求に分割されて行われる。例えば、２４ＫＢの更新を行いたいような場合、３つの８ＫＢの更新に分割されて行われることとなる。このような分割されて行われる更新要求毎に新たな世代番号が作成されるのを防ぐため、一旦ファイルの更新を開始すると、その更新が終了するまでファイルが更新中であることを記憶しておく必要がある。このため、従来プロトコル処理部３１は、更新を開始したファイルを後述するファイル監視テーブルに登録する（ステップ９５）。
【００５９】
（７）ステップ９１の判定で、すでに更新中のデータに対する更新であった場合、従来プロトコル処理部３１は、後述するファイル監視テーブルからＧＵＩＤを得る（ステップ９６）。
【００６０】
（８）従来プロトコル処理部３１は、ステップ９５の処理で、ファイル監視テーブルへの登録の後、または、ステップ９６の処理処理で、ファイル監視テーブルからＧＵＩＤを得た後、ステップ９７で、ＧＵＩＤを指定して更新要求のデータの書き込みをＤＦＳアクセス部３２に依頼する。ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して書き込みの要求を行う（ステップ９７）。
【００６１】
（９）書き込み終了後、従来プロトコル処理部３１は、ＤＦＳ処理部２６からの応答をＤＦＳアクセス部３２を介して受け取り、従来プロトコルクライアントに対して更新要求の完了の応答を返す（ステップ９８）。
【００６２】
図９はファイル監視テーブルの構造を説明する図である。このテーブル７０の各エントリは、更新中のファイルに対応する。エントリの内容は、ファイルを識別するための情報７２と、書き込み中のファイルの世代を表す世代番号７３からなる。ファイルを識別するための情報７２として、この図９ではディレクトリ情報のエントリへのポインタとしてｐ＿ｄｅｎｔｒｙを用いている。
【００６３】
受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否かは、ファイル監視テーブル７０に登録されている情報を調べることにより知ることができ、従来プロトコル処理部３１は、２つ目以降の要求である場合、新たに世代を作成しないようにする。このために、図８により説明した処理において、従来プロトコル処理部３１は、更新要求を受け取った場合、ステップ９１の処理で、ファイル監視テーブル７０を調べ、既に更新中のファイルに対する更新要求であるか否かをチェックしている。そして、更新中でない場合、前述したように、ステップ９２に進み、新世代を作成してデータの書き込みを行うことになる。また、既に更新中であった場合、ステップ９６で、ファイル監視テーブル７０からＧＵＩＤを得て、そのＧＵＩＤに対してステップ９７で、データの書き込み要求を行う。
【００６４】
ゲートウェイ部２５は、前述したようにしてファイルの更新要求を処理することが可能であるが、作成した新しい世代の登録を完了させるために、この世代への更新の終了をＤＦＳ処理部２６に通知する必要がある。このために、ゲートウェイ部２５は、従来プロトコルクライアントから従来プロトコルで送られてくる一連の更新要求の終了を監視する必要がある。
【００６５】
この一連の更新要求の終了を示すトリガは、それぞれのプロトコルにより異なる。例えば、ＣＩＦＳのように、ファイルに対して操作を行うときにオープンし、終了するときにクローズを行うような、ファイル操作中の状態を持つプロトコルである場合、操作終了のクローズ要求がこの更新要求の終了を示すトリガに当たる。これに対し、ＮＦＳは、ファイルのオープンやクローズに当たる操作がなく、ファイルが操作中であるか否かを示す状態を持たない。このようなプロトコルの場合、別のトリガで操作の終了を判断する必要がる。
【００６６】
この場合のトリガとしては複数の場合が考えられる。１つは、更新要求が到着する時間間隔である。従来プロトコルクライアントは、ゲートウェイ部２５に対して一連の更新を分割して発行するが、通常、分割された１つの更新要求が終了するとすぐに次の更新要求を発行する。このため、ゲートウェイ部２５は、更新要求が到着する時間間隔を監視し、ある一定時間以上次の更新要求が到着しない場合に、一連の更新要求が終了したとみなすことができる。また、別のトリガとしてコミットの要求が考えられる。例えば、ＮＦＳのバージョン３以降のものは、更新を行ったファイルの内容をディスクに反映させる方法としてコミットというコマンドが用意されている。コミットの発行契機は、特に規定されているわけではないが、通常、あるまとまった意味のある更新が終了した場合に発行される。このため、ゲートウェイ部２５は、このコミットの要求が到着した場合に一連の更新要求が終了したとみなすことができる。但し、コミットは、更新の終了時に必ず発行されるとは限らないので、このコミットのみをトリガとすると更新の終了を認識することができない場合があるので、先に説明した時間監視と組み合わせて用いる必要がある。
【００６７】
前述のようなトリガを監視して新しい世代作成の終了を判断する方法は、本来の一連の更新の終了以前にトリガだと認識し世代作成を終了してしまう可能性がある。例えば、一定時間をトリガとしている方法は、ネットワーク１の状態等の理由により次の更新要求の到着が遅れることにより、本来引き続いて行われている更新を終了と判断してしまう場合がある。しかし、このような場合でも、余計に世代が追加されてしまうだけで、ファイルの更新内容が失われなければ特に問題はない。一度途切れたと判断して世代作成を終了してしまった後、更新要求を受け取った場合、また新たに世代を作成してその世代に書き込みを行えばよい。
【００６８】
図１０は世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートであり、次に、これについて説明する。
【００６９】
ゲートウェイ部２５は、ステップ１０１で、前述したような更新終了のトリガ発生を待ち、トリガ発生時に処理を開始する。更新終了のトリガ発生があると、ステップ１０２で、従来プロトコル処理部３１は、ファイル監視テーブル７０を参照し、作成中の世代のＧＵＩＤを得る。ステップ１０３で、このＧＵＩＤに対して、ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に更新終了の要求を発行する。ＤＦＳ処理部２６での更新終了の処理が完了後、ステップ１０４で、従来プロトコル処理部３１は、ファイル監視テーブル７０から当該エントリを削除し、ファイルに対する更新中の状態を解除する。
【００７０】
前述のようにして、ゲートウェイ部２５は、従来プロトコルを用いるクライアント４、５からのＤＦＳのファイルに対するアクセスが可能である。
【００７１】
前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００７２】
前述で説明した実施形態は、ＤＦＳとして追記型のファイルシステムを前提として説明したが、本発明は、追記型でないＤＦＳに対しても適用することが可能である。この場合、ファイルの世代という考えはなく、ファイルが更新されてもＧＵＩＤの値は変化しない。そのため、ディレクトリ管理情報５０のｆ＿ｉｄ５６にファイル群識別子の代わりに直接ファイルのＧＵＩＤを持つようにすればよい。そして、図７におけるファイルの参照時のフローでは、ステップ８１でＧＵＩＤを得ることができ、ステップ８２とステップ８３とは不要となる。同様に、図８に示すファイルの更新時のフローでは、ステップ９２でＧＵＩＤを得ることになり、世代作成のステップ９３とＧＵＩＤを得るステップ９４とは不要となる。
【００７３】
また、前述した本発明の実施形態は、ゲートウェイ部２５をＤＦＳサーバ２内に内蔵させるとして説明したが、本発明は、ゲートウェイ部２５をＤＦＳサーバ２内に実装しなくてもよい。例えば、他の実装位置として、ネットワーク１上にゲートウェイ部２５の処理を行うゲートウェイサーバを持つ場合や、従来プロトコルクライアント４や５内に組み込むことが考えられる。
【００７４】
図１１は本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。図１１において、１１０はゲートウェイサーバであり、他の符号は図１の場合と同一である。
【００７５】
図１１に示す例は、前述で説明したゲートウェイ部２５をネットワーク１上に設けたゲートウェイサーバ１１０として備えた例である。この場合、従来プロトコルクライアント４や５は、ゲートウェイサーバ１１０に対してアクセスを行うことになる。そして、ゲートウェイサーバ１１０は、ＤＦＳサーバ２に対して、ＤＦＳプロトコルを用いてアクセスを行う。ゲートウェイサーバ１１０は、ゲートウェイ部２５と同等の処理を行う。
【００７６】
前述したゲートウェイ部２５のＤＦＳアクセス部３２は、ＤＦＳ処理部２６と連携して処理を行っていたが、図１１に示す例の場合、ＤＦＳサーバ２と別のサーバ上にゲートウェイ部の機能が実装されるため、前述した連携した処理をおこなうことが不可能となる。その代わりに、図１１に示す例のシステムは、ゲートウェイサーバ１１０内に設けられるＤＦＳアクセス部３２がＤＦＳクライアントとなり、ＤＦＳプロトコルを使用してＤＦＳサーバ２に要求を行うことにより同等の処理を行うことが可能である。
【００７７】
また、従来プロトコルクライアントに組み込む方法としては、例えば、ＮＦＳのプロトコル処理部にこのゲートウェイ部２５の機能を組み込むことが考えられる。この場合、上位のＮＦＳを使用するプログラムは、ＮＦＳのプロトコルを用いて処理を行って、ゲートウェイ部２５の機能がＮＦＳのプロトコルをＤＦＳプロトコルに変換し、ネットワーク１上ではＤＦＳのプロトコルを用いてＤＦＳサーバ２にアクセスを行うこととなる。
【００７８】
前述した本発明の実施形態によれば、ＮＦＳやＣＩＦＳ等の従来プロトコルのファイルシステムに存在するディレクトリ構造をエミュレートし、ディレクトリ構造上でファイルの存在する位置を示すパス名とファイルの名前であるファイル名とによりアクセスを行う方式を、ＤＦＳでのファイル識別子であるＧＵＩＤによるアクセスに変換することにより、従来プロトコルを使用してＤＦＳ上のファイルに対するアクセスを行うことができる。
【００７９】
また、本発明の実施形態によれば、ＤＦＳが追記型のファイルシステムである場合、従来プロトコルの更新処理を新しい世代の作成処理に変換することにより、参照時には、世代管理されているファイル群から最新の世代のファイルを求め、そのファイルのデータにアクセスを行うことが可能となる。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施形態による分散ファイルシステムの構成例を示すブロック図である。
【図２】ファイル群識別子と世代番号とからＧＵＩＤを求める方法の一例を説明する図である。
【図３】従来プロトコルクライアントが用いるディレクトリ構造について説明する図である。
【図４】ＤＦＳサーバの構成を示すブロック図である。
【図５】ゲートウェイ部の構成を示すブロック図である。
【図６】ディレクトリ管理情報５０の構造を説明する図である。
【図７】従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートである。
【図８】従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートである。
【図９】ファイル監視テーブルの構造を説明する図である。
【図１０】世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートである。
【図１１】本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。
【符号の説明】
【００８１】
１ ネットワーク
２ ＤＦＳサーバ
３ ＤＦＳクライアント
４ ＮＦＳクライアント
５ ＣＩＦＳクライアント
２１ ＤＦＳ制御部
２２ ディスクドライブ
２３ 主メモリ
２４ ＯＳ
２５ ゲートウェイ部
２６ ＤＦＳ処理部
２７ ディスクドライブ処理部
２８ ＣＰＵ
２９ ＨＤＤ
３１ 従来プロトコル処理部
３２ ＤＦＳアクセス部
３３ ディレクトリ管理部
１１０ ゲートウェイサーバ
【特許請求の範囲】
【請求項１】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムにおいて、分散してファイルを格納している複数のＤＦＳサーバをネットワーク上に備え、前記複数のＤＦＳサーバの少なくとも１つは、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることを特徴とする分散ファイルシステム。
【請求項２】
前記ゲートウェイ部は、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成して分散ファイルシステムにアクセスを行い、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成することを特徴とする請求項１記載の分散ファイルシステム。
【請求項３】
前記ゲートウェイ部は、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を受け付け、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いてファイルを特定する分散ファイルシステムにアクセス行うことを特徴とする請求項１記載の分散ファイルシステム。
【請求項４】
前記ゲートウェイ部は、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることを特徴とする請求項３記載の分散ファイルシステム。
【請求項５】
前記ゲートウェイ部は、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を受け付け、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込むことにより行うことを特徴とする請求項１記載の分散ファイルシステム。
【請求項６】
前記ゲートウェイ部は、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行うことを特徴とする請求項５記載の分散ファイルシステム。
【請求項７】
前記ゲートウェイ部は、複数の要求からなる一連のファイルの内容の変更要求を受け付け、１つの世代に変更内容を書き込み、一連の変更要求の終了を認識して世代の作成を完了することを特徴とする請求項５記載の分散ファイルシステム。
【請求項８】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムの分散してファイルを格納している分散ファイルシステムサーバにおいて、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることを特徴とする分散ファイルシステムサーバ。
【請求項９】
前記ゲートウェイ部は、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成して分散ファイルシステムにアクセスを行い、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成することを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１０】
前記ゲートウェイ部は、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を受け付け、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いてファイルを特定する分散ファイルシステムにアクセス行うことを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１１】
前記ゲートウェイ部は、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることを特徴とする請求項１０記載の分散ファイルシステムサーバ。
【請求項１２】
前記ゲートウェイ部は、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を受け付け、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込むことにより行うことを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１３】
前記ゲートウェイ部は、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行うことを特徴とする請求項１２記載の分散ファイルシステムサーバ。
【請求項１４】
前記ゲートウェイ部は、複数の要求からなる一連のファイルの内容の変更要求を受け付け、１つの世代に変更内容を書き込み、一連の変更要求の終了を認識して世代の作成を完了することを特徴とする請求項１２記載の分散ファイルシステムサーバ。
【請求項１５】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセス方法において、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスすることを特徴とする分散ファイルシステムへのアクセス方法。
【請求項１６】
前記プロトコルの変換が、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成し、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成する変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項１７】
前記プロトコル変換が、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いたアクセス要求への変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項１８】
前記要求の変換が、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることにより行われることを特徴とする請求項１７記載の分散ファイルシステムへのアクセス方法。
【請求項１９】
前プロトコル変換が、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込む要求への変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項２０】
前記要求の変換が、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行う要求への変換であることを特徴とする請求項１９記載の分散ファイルシステムへのアクセス方法。
【請求項２１】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセスを行う処理プログラムであって、ファイルの参照時、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定する情報を、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子に変換するステップと、前記識別子を用いてファイルをアクセスするステップと、参照のために読み出したデー
タを応答として返すステップとを有することを特徴とする処理プログラム。
【請求項２２】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセスを行う処理プログラムであって、ファイルの更新時、すでに更新中のデータの更新であるか否かを判定するステップと、すでに更新中のデータの更新ではない場合に、更新ファイルの識別子を得るステップと、ファイルデータ更新中を登録するステップと、前記識別子を用いてファイルをアクセスしてデータ書き込みを要求するステップとを有することを特徴とする処理プログラム。
【請求項１】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムにおいて、分散してファイルを格納している複数のＤＦＳサーバをネットワーク上に備え、前記複数のＤＦＳサーバの少なくとも１つは、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることを特徴とする分散ファイルシステム。
【請求項２】
前記ゲートウェイ部は、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成して分散ファイルシステムにアクセスを行い、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成することを特徴とする請求項１記載の分散ファイルシステム。
【請求項３】
前記ゲートウェイ部は、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を受け付け、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いてファイルを特定する分散ファイルシステムにアクセス行うことを特徴とする請求項１記載の分散ファイルシステム。
【請求項４】
前記ゲートウェイ部は、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることを特徴とする請求項３記載の分散ファイルシステム。
【請求項５】
前記ゲートウェイ部は、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を受け付け、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込むことにより行うことを特徴とする請求項１記載の分散ファイルシステム。
【請求項６】
前記ゲートウェイ部は、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行うことを特徴とする請求項５記載の分散ファイルシステム。
【請求項７】
前記ゲートウェイ部は、複数の要求からなる一連のファイルの内容の変更要求を受け付け、１つの世代に変更内容を書き込み、一連の変更要求の終了を認識して世代の作成を完了することを特徴とする請求項５記載の分散ファイルシステム。
【請求項８】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムの分散してファイルを格納している分散ファイルシステムサーバにおいて、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることを特徴とする分散ファイルシステムサーバ。
【請求項９】
前記ゲートウェイ部は、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成して分散ファイルシステムにアクセスを行い、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成することを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１０】
前記ゲートウェイ部は、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を受け付け、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いてファイルを特定する分散ファイルシステムにアクセス行うことを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１１】
前記ゲートウェイ部は、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることを特徴とする請求項１０記載の分散ファイルシステムサーバ。
【請求項１２】
前記ゲートウェイ部は、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を受け付け、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込むことにより行うことを特徴とする請求項８記載の分散ファイルシステムサーバ。
【請求項１３】
前記ゲートウェイ部は、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行うことを特徴とする請求項１２記載の分散ファイルシステムサーバ。
【請求項１４】
前記ゲートウェイ部は、複数の要求からなる一連のファイルの内容の変更要求を受け付け、１つの世代に変更内容を書き込み、一連の変更要求の終了を認識して世代の作成を完了することを特徴とする請求項１２記載の分散ファイルシステムサーバ。
【請求項１５】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセス方法において、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスすることを特徴とする分散ファイルシステムへのアクセス方法。
【請求項１６】
前記プロトコルの変換が、集中型のファイルシステムに対する要求から、分散ファイルシステムに対する要求を作成し、分散ファイルシステムに対する要求の結果から集中型のネットワークファイルシステムに対する要求の結果を作成する変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項１７】
前記プロトコル変換が、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定するファイルシステムに対するアクセスを行うための要求を、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子を用いたアクセス要求への変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項１８】
前記要求の変換が、ディレクトリ操作をエミュレートし、ファイルのディレクトリ位置とファイル名とからファイルシステム上でファイルを一意に識別するためのファイルの識別子を求めることにより行われることを特徴とする請求項１７記載の分散ファイルシステムへのアクセス方法。
【請求項１９】
前プロトコル変換が、１度書き込んだファイルに対して内容を更新することが可能であるファイルシステムに対してアクセスを行うための要求を、１度書き込んだファイルに対して内容の更新を行うことが不可能で、ファイルの内容の変更を、ファイルの新しい世代を作成し、作成された新しい世代に対して書き込む要求への変換であることを特徴とする請求項１５記載の分散ファイルシステムへのアクセス方法。
【請求項２０】
前記要求の変換が、ファイルに対する参照要求に対し、ファイルシステムから最新の世代を求めてアクセスを行う要求への変換であることを特徴とする請求項１９記載の分散ファイルシステムへのアクセス方法。
【請求項２１】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセスを行う処理プログラムであって、ファイルの参照時、ディレクトリ構造を持ち、ファイルの存在するディレクトリ位置とディレクトリ内で一意のファイル名とによってファイルを特定する情報を、ディレクトリ構造を持たず、位置に関係なくシステム内で一意につけられた識別子に変換するステップと、前記識別子を用いてファイルをアクセスするステップと、参照のために読み出したデー
タを応答として返すステップとを有することを特徴とする処理プログラム。
【請求項２２】
集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセスを行う処理プログラムであって、ファイルの更新時、すでに更新中のデータの更新であるか否かを判定するステップと、すでに更新中のデータの更新ではない場合に、更新ファイルの識別子を得るステップと、ファイルデータ更新中を登録するステップと、前記識別子を用いてファイルをアクセスしてデータ書き込みを要求するステップとを有することを特徴とする処理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００７−２８７１８０（Ｐ２００７−２８７１８０Ａ）
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願番号】特願２００７−１９４０５７（Ｐ２００７−１９４０５７）
【出願日】平成１９年７月２６日（２００７．７．２６）
【分割の表示】特願２００３−６８５５３（Ｐ２００３−６８５５３）の分割
【原出願日】平成１５年３月１３日（２００３．３．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願日】平成１９年７月２６日（２００７．７．２６）
【分割の表示】特願２００３−６８５５３（Ｐ２００３−６８５５３）の分割
【原出願日】平成１５年３月１３日（２００３．３．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]