分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法
【課題】既存部分のソースコードの変更を回避しつつファイルの分散管理に対応すること。
【解決手段】分散ファイル操作プログラムは、ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、ファイルに関する操作要求を第一のプロトコルに基づいて生成し、前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する処理を実行させる。
【解決手段】分散ファイル操作プログラムは、ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、ファイルに関する操作要求を第一のプロトコルに基づいて生成し、前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する処理を実行させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法に関する。
【背景技術】
【０００２】
ＮＡＳ（Network Attached Storage）は、ネットワークに直接接続して使用することができるファイルサーバ専用機である。ＮＡＳのクライアントは、ＮＡＳ（サーバ上）に存在するファイルデータ保存領域をあたかも自分が内蔵するストレージのように使用することができる。通常、ＮＡＳとしての１台のサーバ（ＮＡＳサーバ）は、クライアント上において仮想化されているストレージ（ＮＡＳクライアント）と１対１に対応する。クライアント上において仮想化されているストレージとは、例えば、Ｗｉｎｄｏｗｓ（登録商標）におけるドライブが挙げられる。したがって、ＮＡＳとしてのサーバと当該仮想化されているストレージとが１対１に対応するとは、例えば、１つのドライブに対して、１台のサーバが割り当てられることをいう。
【０００３】
しかし、ＮＡＳクライアントとＮＡＳサーバとが１対１に対応する形態は、拡張性に欠ける。そこで、従来、ＮＡＳサーバのスケールアウトするための技術（スケールアウトＮＡＳ）が存在する。スケールアウトＮＡＳによれば、１つのＮＡＳクライアントは、複数のＮＡＳサーバにアクセス可能とされる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−４６６６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のスケールアウトＮＡＳにおいて、ファイルデータをファイル単位に複数のＮＡＳサーバに分散して格納するための処理は、ＮＡＳクライアントのＯＳ（Operating System）のカーネル内に組み込まれていた。したがって、オープンソースでないＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）等）を利用するＮＡＳクライアントに関して、複数のＮＡＳサーバによるファイルの分散管理対応を第三者が実装するのは実質的に不可能であった。ここでいう、第三者とは、ＯＳのソースコードの保有者以外の者等、ＯＳのソースコードの変更に関して正当な権限を有さない者をいう。
【０００６】
そこで、１つの側面として、既存部分のソースコードの変更を回避しつつファイルの分散管理に対応することができる分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法の提供を目的とする。
【課題を解決するための手段】
【０００７】
１つの案では、分散ファイル操作プログラムは、ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、ファイルに関する操作要求を第一のプロトコルに基づいて生成し、前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する処理を実行させる。
【発明の効果】
【０００８】
既存部分のソースコードの変更を回避しつつファイルシステムの分散対応を実現することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態におけるファイル管理システムの構成例を示す図である。
【図２】本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるファイル管理システムの機能構成例を示す図である。
【図４】ファイルの操作要求の送信時にフィルタ部が実行する処理手順の一例を説明するためのフローチャートである。
【図５】配置情報記憶部の構成例を示す図である。
【図６】ＲＥＡＤ応答メッセージの受信に応じてクライアント装置が実行する処理手順の一例を説明するためのフローチャートである。
【図７】ＯＳＤプロトコルのＲＥＡＤ応答メッセージの構造とＣＩＦＳプロトコルのＲＥＡＤ応答メッセージの構造とを示す図である。
【図８】ＯＳＤのＲＥＡＤ応答メッセージに対するＣＩＦＳのヘッダ部の上書きコピーを説明するための図である。
【図９】ＯＳＤのＲＥＡＤ応答メッセージに対してＣＩＦＳのヘッダ部を上書きできない場合のデータ処理を説明するための図である。
【図１０】具体的な実装系に本実施の形態を適用したクライアント装置の構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるファイル管理システムの構成例を示す図である。同図において、ファイル管理システム１は、クライアント装置１０、配置情報管理装置２０、及び複数のストレージサーバ３０等を含む。ファイル管理システム１に含まれる各装置は、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク４０（有線又は無線の別は問わない。）を介して通信可能とされている。なお、複数台のクライアント装置１０や複数台の配置情報管理装置２０が、ファイル管理システム１に含まれてもよい。
【００１１】
ストレージサーバ３０は、いわゆるＮＡＳ（Network Attached Storage）サーバであり、データを格納したファイル群を記憶（管理）する装置である。本実施の形態では、複数のストレージサーバ３０によって、複数のファイルが分散管理される。すなわち、ストレージサーバ３０は、本実施の形態においてファイル管理装置の一例である。なお、本実施の形態において、ストレージサーバ３０は、便宜上、ＯＳＤ（Object-based Storage Device）サーバであるとする。ＯＳＤサーバは、管理しているファイルに関して、オブジェクトベースのインタフェースを提供するサーバをいう。したがって、ストレージサーバ３０とのファイル操作に関する通信は、ＯＳＤプロトコルに基づいて行われる。
【００１２】
配置情報管理装置２０は、複数のストレージサーバ３０に分散管理されている、各ファイルの配置情報を記憶する装置である。配置情報とは、ファイルの配置位置を示す情報である。すなわち、配置情報管理装置２０は、各ファイルがいずれのストレージサーバ３０に配置されているかを示す情報を管理する。なお、本実施の形態において、配置情報管理装置２０は、便宜上、ＣＩＦＳ（Common Internet File System）サーバであるとする。すなわち、配置情報管理装置２０との通信は、ＣＩＦＳプロトコルに基づいて行われる。ＣＩＦＳプロトコルは、本実施の形態において第一のプロトコルの一例である。
【００１３】
クライアント装置１０は、いわゆるＮＡＳクライアントである。すなわち、クライアント装置１０は、ストレージサーバ３０において管理されているファイルの操作元となるコンピュータである。クライアント装置１０は、本実施の形態において、分散ファイル操作装置の一例である。
【００１４】
図２は、本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。同図において、クライアント装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。
【００１５】
クライアント装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１６】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってクライアント装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００１７】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【００１８】
また、クライアント装置１０が、ユーザによって直接操作される場合、クライアント装置１０は、キーボード及びマウス等の入力装置や、液晶ディスプレイ等の表示装置等を備えていてもよい。また、配置情報管理装置２０及びストレージサーバ３０についても、図２と同様のハードウェア構成を有していればよい。
【００１９】
図３は、本発明の実施の形態におけるファイル管理システムの機能構成例を示す図である。
【００２０】
同図において、ストレージサーバ３０は、サーバ部３１及びファイル記憶部３２等を有するファイル記憶部３２は、ストレージサーバ３０の補助記憶装置を用いてファイルの実体を記憶する。サーバ部３１は、ＯＳＤプロトコルに従って、クライアント装置１０からのファイル操作要求を受信する。サーバ部３１は、ファイル操作要求に係る処理を、ファイル記憶部３２に記憶されているファイルに対して実行し、処理結果を含む応答をＯＳＤプロトコルに従って返信する。ＯＳＤプロトコルは、本実施の形態において、第二のプロトコルの一例である。
【００２１】
配置情報管理装置２０は、配置情報管理部２１及び配置情報記憶部２２等を有する。配置情報記憶部２２は、複数のストレージサーバ３０に分散管理されている、各ファイルの配置情報を、配置情報管理装置２０の補助記憶装置を用いて記憶する。配置情報管理部２１は、操作対象とされたファイルの配置情報の取得要求を受信し、当該ファイルの配置情報を配置情報記憶部２２より取得する。配置情報管理部２１は、取得された配置情報をクライアント装置１０に返信する。
【００２２】
クライアント装置１０は、クライアント部１１、ファイル操作プロトコル制御部１２、フィルタ部１３、及び通信制御部１４等を有する。これら各部は、クライアント装置１０にインストールされるプログラムがＣＰＵ１０４に実行させる処理によって実現される。なお、各部は、一つのプログラムによって実現されなくてもよい。例えば、本実施の形態において、フィルタ部１３は、他の各部からは独立した別個のプログラムによって実現される。当該別個のプログラムは、分散ファイル操作プログラムの一例である。
【００２３】
クライアント部１１は、ファイルの操作要求元となるソフトウェア（例えば、アプリケーションプログラム等）である。クライアント部１１は、例えば、入力装置より入力されるファイルの操作指示又はネットワークを介して受信されるファイルの操作指示に応じ、当該操作指示に対応するファイルの操作要求をファイル操作プロトコル制御部１２に入力する。当該操作要求は、ファイル操作プロトコル制御部１２が提供するインタフェース（例えば、関数群）を介して入力される。
【００２４】
ファイル操作プロトコル制御部１２は、クライアント部１１より入力されたファイル操作要求に応じた、ＣＩＦＳプロトコルに基づくリクエストメッセージ（以下、「ＣＩＦＳリクエストメッセージ」という。）を生成する。すなわち、ファイル操作プロトコル制御部１２は、ストレージサーバ３０において管理されているファイルに対する操作要求をＣＩＦＳに基づいて生成する。なお、本実施の形態において、ファイル操作プロトコル制御部１２は、第一制御部の一例である。
【００２５】
通信制御部１４は、クライアント装置１０がネットワーク４０を介して行う通信を、インタフェース装置１０５を用いて制御する。通信制御部１４は、ＣＩＦＳよりも下位の層の通信プロトコルに基づく通信を制御する。「ＣＩＦＳより下位」とは、例えば、ＯＳＩ基本参照モデルにおける各層の上下関係に基づく表現である。例えば、通信制御部１４は、ＴＤＩ（transport driver interface ）によって通信要求の受け付け等を行う。ＴＤＩは、トランスポート層とセッション層との間の共通インタフェースであり、トランスポート層の違いを吸収する役割を有する。
【００２６】
なお、通常、ファイル操作プロトコル制御部１２によって生成されたＣＩＦＳリクエストメッセージは、通信制御部１４に入力され、通信制御部１４によって送出される。また、当該ＣＩＦＳメッセージに対する応答メッセージが通信制御部１４によって受信されると、通信制御部１４は、ファイル操作プロトコル制御部１２に対して当該応答メッセージを通知する。
【００２７】
ここで、「通常」とは、フィルタ部１３が存在しない場合をいう。但し、本実施の形態では、フィルタ部１３が存在する。したがって、「通常」とは異なる制御がフィルタ部１３によって行われる。すなわち、フィルタ部１３は、通信制御部１４へ入力される通信要求を横取り（インターセプト）する。したがって、フィルタ操作制御部からのＣＩＦＳリクエストメッセージもフィルタ部１３によって横取りされる。フィルタ部１３は、横取りしたＣＩＦＳリクエストメッセージにおいて操作対象とされているファイルの配置情報を配置情報管理装置２０に問い合わせる。フィルタ部１３は、配置情報管理装置２０より返信される配置情報が示すストレージサーバ３０へ、当該ファイルの操作要求を送信（転送）する。なお、ストレージサーバ３０は、ＯＳＤプロトコルに対応している。したがって、フィルタ部１３は、ＣＩＦＳリクエストメッセージからＯＳＤプロトコルに応じた操作要求（以下、「ＯＳＤリクエストメッセージ」という。）の変換も行う。変換されたＯＳＤリクエストメッセージは、通信制御部１４によって送信される。フィルタ部１３は、受信される応答に関してもメッセージ形式の変換を行う。このように、フィルタ部１３によって、複数のストレージサーバ３０によるファイルの分散管理に対する対応が行われる。換言すれば、ファイル操作プロトコル制御部１２は、ファイルの分散管理（すなわち、ファイルの配置）については関与しない。ファイル操作プロトコル制御部１２は、対応するサーバが一台であることが前提とされて実装されているからである。なお、本実施の形態においてＣＩＦＳサーバは、配置情報管理装置２０である。したがって、ファイル操作プロトコル制御部１２は、配置情報管理装置２０にファイルが管理されているという前提に基づいて処理を行う。但し、本実施の形態において、配置情報管理装置２０は、ファイルの配置情報の管理に用いられており、ファイルの実体の管理には用いられていない。
【００２８】
フィルタ部１３は、クライアント装置１０に動的に追加可能な形態で実装されることが望ましい。動的に追加可能な形態とは、既存部分（例えば、ファイル操作プロトコル制御部１２、及び通信制御部１４等、クライアント装置１０のＯＳのカーネル部）のソースコードの修正等を要さずに追加可能な形態をいう。例えば、Ｗｉｎｄｏｗｓ（登録商標）においては、フィルタドライバという仕組みが提供されている。したがって、フィルタ部１３は、通信制御部１４に対するフィルタドライバとして実装されてもよい。なお、フィルタ部１３は、本実施の形態において第二制御部の一例である。
【００２９】
以下、クライアント装置１０が実行する処理手順について説明する。図４は、ファイルの操作要求の送信時にフィルタ部が実行する処理手順の一例を説明するためのフローチャートである。
【００３０】
例えば、通信制御部１４に対して何らかの通信要求が入力されると、フィルタ部１３は、当該通信要求を横取りする（Ｓ１０１）。したがって、ファイル操作プロトコル制御部１２によって通信制御部１４に対して入力されるＣＩＦＳリクエストメッセージもフィルタ部１３によって横取りされる。続いて、フィルタ部１３は、横取りした通信要求が、ＣＩＦＳリクエストメッセージであるか否かを判定する（Ｓ１０２）。当該判定は、当該通信要求の所定の部分が、ＣＩＦＳプロトコルに従った形式であるか否かに基づいて行われればよい。当該通信要求がＣＩＦＳリクエストメッセージでない場合（Ｓ１０２でＮｏ）、フィルタ部１３は、当該通信要求をそのまま（加工せずに）通信制御部１４に入力する（Ｓ１０５）。この場合は、当該通信要求が、ファイル操作プロトコル制御部１２以外からの非図示のプログラムモジュールからの通信要求である場合に相当する。すなわち、通信制御部１４は、複数のプログラムモジュールより共用されるため、ファイル操作プロトコル制御部１２以外のプログラムモジュールからの通信要求も通信制御部１４に入力される。
【００３１】
一方、当該通信要求がＣＩＦＳリクエストメッセージである場合（Ｓ１０２でＹｅｓ）、当該ＣＩＦＳリクエストメッセージが示すファイルの操作要求が、ＲＥＡＤ（読み込み）要求又はＷＲＩＴＥ（書き込み）要求であるか否かを判定する（Ｓ１０３）。当該操作要求がＲＥＡＤ要求又はＷＲＩＴＥ要求ではない場合（Ｓ１０３でＮｏ）、フィルタ部１３は、当該ＣＩＦＳメッセージを通信制御部１４にそのまま入力する（Ｓ１０５）。したがって、当該ＣＩＦＳメッセージは、ＣＩＦＳサーバである配置情報管理装置２０に送信される。配置情報管理装置２０の配置情報管理部２１は、当該ＣＩＦＳメッセージに応じた処理を実行し、当該処理の実行結果を含む応答をクライアント装置１０に返信する。例えば、当該ＣＩＦＳメッセージがファイルのオープン要求を示すものであれば、配置情報管理部２１は、ファイルのオープン処理を実行し、当該ファイルの識別子（ファイルＩＤ）を含む応答をクライアント装置１０に返信する。したがって、配置情報管理装置２０は、ファイルのオープン要求に指定されるファイル名とファイルＩＤとの対応情報を記憶しておけばよい。または、配置情報管理装置２０が、ファイル名に基づいてファイルＩＤを導出可能な仕組みが、ファイル管理システム１に実装されていればよい。なお、ファイルＩＤは、ＣＩＦＳにおいて、ファイルを識別するために用いられるＩＤである。当該応答は、通信制御部１４によって受信され、フィルタ部１３を介してファイル操作プロトコル制御部１２に通知される。ファイル制御部は、当該応答に応じた戻り値をクライアント部１１に返却する。
【００３２】
なお、本実施の形態において、ファイルのオープン要求が配置情報管理装置２０に転送されるのは、ＯＳＤプロトコルには、ファイルのオープンという概念が無いためである。したがって、ファイルのオープンという概念を有するプロトコルに基づくストレージサーバ３０が利用される場合、ファイルのオープン要求も、ファイルのＲＥＡＤ要求又はＷＲＩＴＥ要求と同様に、ストレージサーバ３０に転送されるようにしてもよい。
【００３３】
一方、ＣＩＦＳメッセージが示すファイルの操作要求がＲＥＡＤ要求又はＷＲＩＴＥ要求である場合（Ｓ１０３でＹｅｓ）、フィルタ部１３は、ＣＩＦＳリクエストメッセージが示すファイルの操作要求において操作対象とされているファイルの配置情報を配置情報管理装置２０に問い合わせる（Ｓ１０４）。すなわち、フィルタ部１３は、当該配置情報の取得要求を配置情報管理装置２０に送信する。当該取得要求には、ＣＩＦＳリクエストメッセージが示すファイルの操作要求において操作対象とされているファイルのファイルＩＤが指定される。当該ファイルＩＤは、ＣＩＦＳにおいて、ファイルを識別するために用いられるＩＤであり、ＣＩＦＳリクエストメッセージに含まれている。なお、配置情報管理装置２０の識別情報（ＩＰアドレス等）は、予め、クライアント装置１０の補助記憶装置１０２に記録されていればよい。
【００３４】
配置情報管理装置２０において配置情報の取得要求が受信されると、配置情報管理部２１は、当該取得要求に指定されているファイルＩＤに対応する配置情報を配置情報記憶部２２より取得する。配置情報管理部２１は、取得された配置情報を含む応答をフィルタ部１３に返信する。
【００３５】
図５は、配置情報記憶部の構成例を示す図である。同図に示されるように、配置情報記憶部２２は、分散管理されているファイルごとに、ファイルＩＤ、サーバＩＤ、及びオブジェクトＩＤ等が記憶されている。
【００３６】
ファイルＩＤは、上記したようにＣＩＦＳのファイルＩＤである。サーバＩＤ及びオブジェクトＩＤは、本実施の形態における配置情報の一例である。すなわち、サーバＩＤは、ストレージサーバ３０の識別子である。サーバＩＤは、ストレージサーバ３０のＩＰアドレスでもよいし、ＩＰアドレスとは別の識別子であってもよい。後者の場合、配置情報記憶装置２０又はクライアント装置１０は、サーバＩＤとＩＰアドレスとの対応情報を記憶していればよい。オブジェクトＩＤは、ストレージサーバ３０内において、各ファイルを識別するための識別子である。本実施の形態において、ストレージサーバ３０は、各ファイルをオブジェクトとして扱うため、各ファイルの識別子はオブジェクトＩＤと呼ばれる。
【００３７】
したがって、本実施の形態の配置情報管理部２１は、サーバＩＤ及びオブジェクトＩＤを含む応答をクライアント装置１０に返信する。
【００３８】
配置情報の取得要求に対して、配置情報管理装置２０より正常な応答が返信されると（Ｓ１０６でＹｅｓ）、フィルタ部１３は、ＣＩＦＳリクエストメッセージをＯＳＤリクエストメッセージに変換し、当該ＯＳＤリクエストメッセージを送信する（Ｓ１０７）。正常な応答とは、配置情報を含む応答をいう。また、ＯＳＤリクエストメッセージの送信先は、取得された配置情報に含まれているサーバＩＤに係るストレージサーバ３０である。
【００３９】
ＣＩＦＳリクエストメッセージのＯＳＤリクエストメッセージへの変換及びＯＳＤリクエストメッセージの送信は、次のように行われる。ＣＩＦＳリクエストメッセージがＲＥＡＤ要求である場合、ＣＩＦＳリクエストメッセージのヘッダ部の内容に基づいてＯＳＤリクエストメッセージのヘッダ部が生成される。フィルタ部１３は、当該ヘッダ部を通信制御部１４に入力する。通信制御部１４は、当該ヘッダ部を該当するストレージサーバ３０に送信する。なお、ＲＥＡＤ要求の場合、ＣＩＦＳリクエストメッセージにはデータ部は存在しない。したがって、ＯＳＤリクエストメッセージについても、ヘッダ部がその全部となる。また、ＯＳＤリクエストメッセージのヘッダ部には、操作対象のファイルの識別子として、取得された配置情報に含まれているオブジェクトＩＤが指定される。
【００４０】
ＲＥＡＤ要求を示すＯＳＤリクエストメッセージを受信したストレージサーバ３０のサーバ部３１は、当該ＯＳＤリクエストメッセージに指定されているオブジェクトＩＤに対応するファイルよりデータを読み込む。サーバ部３１は、読み込まれたデータをデータ部に含む応答メッセージ（以下、「ＲＥＡＤ応答メッセージ」という。）をＯＳＤプロトコルに基づいて返信する。
【００４１】
一方、ＣＩＦＳリクエストメッセージがＷＲＩＴＥ要求である場合、まず、ＣＩＦＳリクエストメッセージのヘッダ部の内容に基づいてＯＳＤリクエストメッセージのヘッダ部が生成される。フィルタ部１３は、当該ヘッダ部を通信制御部１４に入力する。通信制御部１４は、当該ヘッダ部を該当するストレージサーバ３０に送信する。なお、ＯＳＤリクエストメッセージのヘッダ部には、操作対象のファイルの識別子として、取得された配置情報に含まれているオブジェクトＩＤが指定される。また、ＣＩＦＳリクエストメッセージのヘッダ部のサイズが、ＯＤＡリクエストメッセージのヘッダ部のサイズ以上である場合、後述されるＲＥＡＤ応答メッセージの受信時と同様に、ＣＩＦＳリクエストメッセージのヘッダ部に、ＯＤＡリクエストメッセージのヘッダ部が上書きされてもよい。この場合、ＯＤＡリクエストメッセージのヘッダ部用のバッファ領域（メモリ領域）を改めて確保したり、メモリコピーを行ったりする必要性を無くすことができる。
【００４２】
ＷＲＩＴＥ要求の場合、ＣＩＦＳリクエストメッセージにはデータ部が存在する。データ部は、書き込み要求の対象のファイルに書き込まれるデータを格納する部分である。したがって、ＯＳＤリクエストメッセージについてもヘッダ部の送信に続いて、データ部の送信が行われる。ここで、通信制御部１４がＴＣＰ（Transmission Control Protocol）を利用する場合、データの送信用のインタフェースは、ｉｏｖｅｃ形式（複数バッファ形式）である。したがって、後述されるＲＥＡＤ応答メッセージの受信時とは異なり、ヘッダ部とデータ部との関係（繋がり）は考慮される必要はない。よって、フィルタ部１３は、ＣＩＦＳメッセージに含まれているデータ部をそのまま通信制御部１４に入力する。通信制御部１４は、当該データ部を、該当するストレージサーバ３０に送信する。
【００４３】
ＷＲＩＴＥ要求を示すＯＳＤリクエストメッセージを受信したストレージサーバ３０のサーバ部３１は、当該ＯＳＤリクエストメッセージに指定されているオブジェクトＩＤに対応するファイルに対して、ＯＳＤリクエストメッセージに含まれているデータを書き込む。サーバ部３１は、書き込み処理の結果等を示す応答（以下、「ＷＲＩＴＥ応答」という。）をＯＳＤプロトコルに基づいて返信する。
【００４４】
続いて、ＲＥＡＤ応答メッセージがストレージサーバ３０より返信された際に、クライアント装置１０が実行する処理手順について説明する。
【００４５】
図６は、ＲＥＡＤ応答メッセージの受信に応じてクライアント装置が実行する処理手順の一例を説明するためのフローチャートである。
【００４６】
通信制御部１４によってＲＥＡＤ応答メッセージが受信されると、当該ＲＥＡＤ応答メッセージの受信が、フィルタ部１３に通知される（Ｓ２０１）。より詳しくは、通信制御部１４は、データ（例えば、ＲＥＡＤ応答メッセージ）の受信に応じイベントを発生させる。フィルタ部１３のイベントハンドラは、当該イベントによってデータの受信を検知する。ここで、ＲＥＡＤ応答メッセージには、ＯＳＤプロトコルのヘッダ部及びデータ部が含まれている。通信制御部１４からのイベントでは、ＲＥＡＤ応答メッセージを格納したバッファ（以下、「受信バッファ」という。）の先頭アドレスと受信バッファのサイズとがフィルタ部１３に通知される。
【００４７】
続いて、フィルタ部１３は、ＲＥＡＤ応答メッセージをファイル操作プロトコル制御部１２に通知するための処理に関連するメモリアドレスのアライメントの境界の最大値を判定する（Ｓ２０２）。本実施の形態において、アライメントとは、メモリ領域にデータ等を格納する場合に、その先頭番地（先頭アドレス）が規則的な値となるように調整することをいう。例えば、先頭アドレスが偶数となるようにアライン（位置合わせ）されたり、Ｎバイト境界にアラインされたりする。ＲＥＡＤ応答メッセージをファイル操作プロトコル制御部１２に通知するための処理に関連するメモリアドレスのアライメントとは、例えば、メモリコピーに関するアライメントや、ファイル操作プロトコル制御部１２のＲＥＡＤバッファのアライメント等である。ステップＳ２０２では、これらの各種アライメントの境界の最大値が判定される。例えば、メモリコピーに関するアライメントの境界が４バイトであり、ファイル操作プロトコル制御部１２のＲＥＡＤバッファのアライメントの境界が８バイトである場合、８バイトが最大値とされる。
【００４８】
なお、各種アライメントの境界は、例えば、ＯＳ等より動的に取得可能なシステム環境であれば、ステップＳ２０２において動的に取得されればよい。また、動的に取得可能なシステム環境でなければ、予め計算され、補助記憶装置１０２に記録されている固定値が、ステップＳ２０２において取得されればよい。
【００４９】
続いて、フィルタ部１３は、受信された、ＯＳＤプロトコルのＲＥＡＤ応答メッセージのヘッダ部のサイズ（ヘッダ長）を計算する。また、フィルタ部１３は、これから生成されるＣＩＦＳプロトコルのＲＥＡＤ応答メッセージのヘッダ部のサイズを計算する（Ｓ２０３）。
【００５０】
図７は、ＯＳＤプロトコルのＲＥＡＤ応答メッセージの構造とＣＩＦＳプロトコルのＲＥＡＤ応答メッセージの構造とを示す図である。同図において、（１）は、ＯＳＤプロトコルのＲＥＡＤ応答メッセージ（以下、「ＯＳＤのＲＥＡＤ応答メッセージ」という。）の構造を示す。（２）は、ＣＩＦＳプロトコルのＲＥＡＤ応答メッセージ（以下、「ＣＩＦＳのＲＥＡＤ応答メッセージ」という。）の構造を示す。同図では、各メッセージを構成するフィールド（項目）ごとに、データ型、フィールド名、及び概要が示されている。各フィールドの詳細については、各プロトコルの仕様書に詳しいため、ここでの説明は省略する。
【００５１】
同図に示されるように、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部又はＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を構成する各フィールドのデータ型は、予め決まっている。そして、各フィールドのサイズはデータ型によって決まる。したがって、それぞれのメッセージのヘッダ長は、それぞれのヘッダ部を構成するフィールドのサイズの合計によって算出することができる。
【００５２】
続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ長ＡとＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ長Ｂとを比較する（Ｓ２０４）。ヘッダ長Ａがヘッダ長Ｂ以上である場合（Ｓ２０４でＹｅｓ）、フィルタ部１３は、ヘッダ長Ａとヘッダ長Ｂとの差分α（ヘッダ長Ａ−ヘッダ長Ｂ）が、アライメントの境界の最大値の整数倍であるか否かを判定する（Ｓ２０５）。
【００５３】
差分αが、アライメントの境界の最大値の整数倍である場合（Ｓ２０５でＹｅｓ）、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部に基づいて、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を生成する（Ｓ２０６）。続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージに対して、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を上書きコピーする（Ｓ２０７）。この際、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスから差分αだけ後方にずらした位置が、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部に一致するように当該ヘッダ部の上書きを行う。なお、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスとは、受信バッファの先頭アドレスと同義である。
【００５４】
図８は、ＯＳＤのＲＥＡＤ応答メッセージに対するＣＩＦＳのヘッダ部の上書きコピーを説明するための図である。
【００５５】
同図において、（Ａ）は、上書き前の受信バッファの内容（すなわち、ＯＳＤのＲＥＡＤ応答メッセージ）を示す。同図の例では、ＯＳＤのＲＥＡＤ応答メッセージのデータサイズはｄ１とされている。
【００５６】
（Ｂ）は、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部（ＣＩＦＳヘッダ部）が上書きされた受信バッファの内容である。（Ｂ）では、ヘッダ長Ａとヘッダ長Ｂとの差分α分だけ後方にずらされてＣＩＦＳヘッダ部が上書きされている。その結果、ＣＩＦＳヘッダ部とデータ部とが連続した状態となる。（Ｂ）に示される、受信バッファの先頭から差分αだけ後方にずらされたアドレスａ以降の部分が、ＣＩＦＳのＲＥＡＤ応答メッセージに相当する。したがって、同図において、ＣＩＦＳのＲＥＡＤ応答メッセージのデータサイズは、ｄ１−αである。
【００５７】
続いて、フィルタ部１３は、ＣＩＦＳのＲＥＡＤ応答メッセージの先頭アドレス（アドレスａ）とデータサイズ（ｄ１−α）とをファイル操作プロトコル制御部１２に通知する（Ｓ２０８）。ファイル操作プロトコル制御部１２は、先頭アドレス及びデータサイズによって特定されるＣＩＦＳのＲＥＡＤ応答メッセージに基づいて、クライアント部１１への応答を行う。
【００５８】
このように、本実施の形態では、ＣＩＦＳのＲＥＡＤ応答メッセージ用に改めてバッファが確保されるのではなく、ＯＳＤのＲＥＡＤ応答メッセージの受信バッファに対してＣＩＦＳヘッダ部の上書きが行われて、ＣＩＦＳのＲＥＡＤ応答メッセージが生成される。したがって、メモリコピーの回数を削減することができ、ＣＰＵの使用率を低く維持することができる。斯かる効果は、ファイルへのアクセス数が増加すればするほど、顕著なものとなる。
【００５９】
また、ＣＩＦＳのＲＥＡＤ応答メッセージの先頭アドレスのずれは、アライメントの境界の最大値の整数倍である。すなわち、当該先頭アドレスのずれは、ＯＳＤのＲＥＡＤ応答メッセージに基づいてＣＩＦＳのＲＥＡＤ応答メッセージが生成され、当該ＣＩＦＳのＲＥＡＤ応答メッセージがファイル操作プロトコル制御部１２に通知されるまでに関連するアライメントの境界の要件を全て満たすものである。したがって、ＣＩＦＳヘッダ部のコピー時や、ファイル操作プロトコル制御部１２への先頭アドレスの通知時等において、処理が不正となるのを回避することができる。
【００６０】
一方、ヘッダ長Ａがヘッダ長Ｂより大きい場合（Ｓ２０４でＮｏ）、ＯＳＤのＲＥＡＤ応答メッセージにＣＩＦＳヘッダ部を上書きすることはできない。また、差分αがアライメントの最大値の整数倍でない場合（Ｓ２０５でＮｏ）、ＣＩＦＳヘッダ部の先頭アドレスをアライメントの境界に一致させることはできない。したがって、これらの場合、フィルタ部１３は、ステップＳ２０６と同様にＣＩＦＳヘッダ部を生成し、生成されたＣＩＦＳヘッダ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する（Ｓ２０９）。続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのデータ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する（Ｓ２１０）。ステップＳ２１０において通知される先頭アドレスは、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスからヘッダ長Ａだけ後方にずらされた値である。また、ステップＳ２１０において通知されるデータサイズは、ＯＳＤのＲＥＡＤ応答メッセージからヘッダ長を差し引いた値である。但し、当該データ部のサイズは、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部のｌｅｎフィールド（図７（１）参照）に基づいて特定されてもよい。
【００６１】
図９は、ＯＳＤのＲＥＡＤ応答メッセージに対してＣＩＦＳのヘッダ部を上書きできない場合のデータ処理を説明するための図である。
【００６２】
同図において（Ｃ）は、ステップＳ２０９に対応する。すなわち、受信バッファとは別のメモリ領域に生成されたＣＩＦＳヘッダ部の先頭アドレスｂとデータサイズｄ２とがファイル操作プロトコル制御部１２に通知される。（Ｄ）は、ステップＳ２１０に対応する。すなわち、受信バッファ内のＯＳＤのＲＥＡＤ応答メッセージのデータ部の先頭アドレスｃとデータサイズｄ３とがファイル操作プロトコル制御部１２に通知される。
【００６３】
なお、ＯＳＤのＷＲＩＴＥ応答メッセージが受信された場合は、図６に示されるような複雑な処理は必要とされない。ＷＲＩＴＥ応答メッセージは、データ部を含まないからである。この場合、フィルタ部１３は、受信されたＯＳＤのＷＲＩＴＥ応答メッセージのヘッダ部に基づいて、ＣＩＦＳヘッダ部を生成する。フィルタ部１３は、生成されたＣＩＦＳヘッダ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する。
【００６４】
上述したように、本実施の形態によれば、ＣＩＦＳリクエストメッセージがフィルタ部１３によって横取りされ、操作対象のファイルの配置情報が示すストレージサーバ３０に、操作要求が転送される。したがって、ファイル操作プロトコル制御部１２や通信制御部１４等の既存部分に対する変更を回避しつつファイルの分散管理に対応することができる。
【００６５】
また、フィルタ部１３は、ＣＩＦＳプロトコルとＯＳＤプロトコルとの間の変換をも行う。その結果、ファイル操作プロトコル制御部１２が対応していないプロトコルに対応したストレージサーバ３０を利用して、ファイルの分散管理を行うこともできる。
【００６６】
なお、ＣＩＦＳプロトコル及びＯＳＤプロトコルは、一例に過ぎない。ＮＦＳ（Network File System）プロトコル等、その他の遠隔的なファイル管理用のプロトコルによって、本実施の形態において例示したプロトコルが代替されてもよい。
【００６７】
また、ファル操作プロトコル制御部１２が利用するプロトコルとフィルタ部１３が利用するプロトコルとは同じでもよい。例えば、配置情報管理装置２０及びストレージサーバ３０の双方がＣＩＦＳサーバであってもよい。この場合、フィルタ部１３によるプロトコルの変換処理は不要となる。
【００６８】
なお、本実施の形態を具体的な実装系に適用した例を図１０に示す。図１０は、具体的な実装系に本実施の形態を適用したクライアント装置の構成例を示す図である。
【００６９】
同図では、Ｗｉｎｄｏｗｓ（登録商標）において採用されているリモートＦＳＤ（FileSystem Driver）の仕組みに対して本実施の形態が適用された例を示されている。
【００７０】
同図のクライアント装置１０ａでは、クライアントアプリケーション１１１、Ｋｅｒｎｅｌ３２．ｄｌｌ１１２及びＮｔｄｌｌ．ｄｌｌ１１３等がクライアント部１１を構成する。また、リダイレクタ１２１と呼ばれるファイルシステムドライバ（ＦＳＤ）とキャッシュマネージャ１２２とがファイル操作プロトコル制御部１２を構成する。また、ＴＤＩフィルタ１３１は、フィルタ部１３に相当する。また、プロトコルドライバ１４１は、通信制御部１４に相当する。
【００７１】
クライアントアプリケーション１１１は、ファイルの操作要求元となる任意のアプリケーションプログラムである。クライアントアプリケーションは、Ｋｅｒｎｅｌ３２．ｄｌｌ１１２に含まれている関数を呼び出すことにより、ファイルの操作要求を入力する。当該操作要求は、Ｎｔｄｌｌ．ｄｌｌ１１３を介してリダイレクタ１２１に入力される。通常、リダイレクタ１２１が生成し、プロトコルドライバ１４１を介して送信しようとするＣＩＦＳリクエストメッセージは、ＴＤＩフィルタ１３１によって横取りされる。ＴＤＩフィルタ１３１は、図４において説明した処理順を実行して、ＣＩＦＳリクエストメッセージをＯＳＤリクエストメッセージに変換し、ＯＳＤリクエストメッセージの送信をプロトコルドライバ１４１に実行させる。
【００７２】
ＯＳＤリクエストメッセージからの応答がプロトコルドライバ１４１によって受信されると、ＴＤＩフィルタ１３１は、図６を用いて説明した処理手順を実行する。
【００７３】
なお、Ｗｉｎｄｏｗｓ（登録商標）環境において、ＴＤＩフィルタ１３１は、フィルタドライバとして実装されるのが好適である。
【００７４】
図１０の例では、ＴＤＩフィルタ１３１以外の部分に修正を加えることなく、ＴＤＩフィルタ１３１を組み込むことができる。その結果、クライアント装置１０ａについて、既存部分（ＯＳのカーネル等）に変更を回避しつつファイルの分散管理に対応させることができる。
【００７５】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００７６】
以上の説明に関し、更に以下の項を開示する。
（付記１）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行させる分散ファイル操作プログラム。
（付記２）
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータに実行させる付記１記載の分散ファイル操作プログラム。
（付記３）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータに実行させる付記２記載の分散ファイル操作プログラム。
（付記４）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記３記載の分散ファイル操作プログラム。
（付記５）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続される分散ファイル操作装置であって、
ファイルに関する操作要求を第一のプロトコルに基づいて生成する第一制御部と、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する第二制御部と、
を有する分散ファイル操作装置。
（付記６）
前記第二制御部は、前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する付記５記載の分散ファイル操作装置。
（付記７）
前記第二制御部は、前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする付記６記載の分散ファイル操作装置。
（付記８）
前記第二制御部は、前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記７記載の分散ファイル操作プログラム。
（付記９）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータが、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行する分散ファイル操作方法。
（付記１０）
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータが実行する付記９記載の分散ファイル操作方法。
（付記１１）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータが実行する付記１０記載の分散ファイル操作方法。
（付記１２）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記１１記載の分散ファイル操作方法。
【符号の説明】
【００７７】
１ ファイル管理システム
１０ クライアント装置
１１ クライアント部
１２ ファイル操作プロトコル制御部
１３ フィルタ部
１４ 通信制御部
２０ 配置情報管理装置
２１ 配置情報管理部
２２ 配置情報記憶部
３０ ストレージサーバ
３１ サーバ部
３２ ファイル記憶部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス
【技術分野】
【０００１】
本発明は、分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法に関する。
【背景技術】
【０００２】
ＮＡＳ（Network Attached Storage）は、ネットワークに直接接続して使用することができるファイルサーバ専用機である。ＮＡＳのクライアントは、ＮＡＳ（サーバ上）に存在するファイルデータ保存領域をあたかも自分が内蔵するストレージのように使用することができる。通常、ＮＡＳとしての１台のサーバ（ＮＡＳサーバ）は、クライアント上において仮想化されているストレージ（ＮＡＳクライアント）と１対１に対応する。クライアント上において仮想化されているストレージとは、例えば、Ｗｉｎｄｏｗｓ（登録商標）におけるドライブが挙げられる。したがって、ＮＡＳとしてのサーバと当該仮想化されているストレージとが１対１に対応するとは、例えば、１つのドライブに対して、１台のサーバが割り当てられることをいう。
【０００３】
しかし、ＮＡＳクライアントとＮＡＳサーバとが１対１に対応する形態は、拡張性に欠ける。そこで、従来、ＮＡＳサーバのスケールアウトするための技術（スケールアウトＮＡＳ）が存在する。スケールアウトＮＡＳによれば、１つのＮＡＳクライアントは、複数のＮＡＳサーバにアクセス可能とされる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−４６６６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のスケールアウトＮＡＳにおいて、ファイルデータをファイル単位に複数のＮＡＳサーバに分散して格納するための処理は、ＮＡＳクライアントのＯＳ（Operating System）のカーネル内に組み込まれていた。したがって、オープンソースでないＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）等）を利用するＮＡＳクライアントに関して、複数のＮＡＳサーバによるファイルの分散管理対応を第三者が実装するのは実質的に不可能であった。ここでいう、第三者とは、ＯＳのソースコードの保有者以外の者等、ＯＳのソースコードの変更に関して正当な権限を有さない者をいう。
【０００６】
そこで、１つの側面として、既存部分のソースコードの変更を回避しつつファイルの分散管理に対応することができる分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法の提供を目的とする。
【課題を解決するための手段】
【０００７】
１つの案では、分散ファイル操作プログラムは、ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、ファイルに関する操作要求を第一のプロトコルに基づいて生成し、前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する処理を実行させる。
【発明の効果】
【０００８】
既存部分のソースコードの変更を回避しつつファイルシステムの分散対応を実現することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態におけるファイル管理システムの構成例を示す図である。
【図２】本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるファイル管理システムの機能構成例を示す図である。
【図４】ファイルの操作要求の送信時にフィルタ部が実行する処理手順の一例を説明するためのフローチャートである。
【図５】配置情報記憶部の構成例を示す図である。
【図６】ＲＥＡＤ応答メッセージの受信に応じてクライアント装置が実行する処理手順の一例を説明するためのフローチャートである。
【図７】ＯＳＤプロトコルのＲＥＡＤ応答メッセージの構造とＣＩＦＳプロトコルのＲＥＡＤ応答メッセージの構造とを示す図である。
【図８】ＯＳＤのＲＥＡＤ応答メッセージに対するＣＩＦＳのヘッダ部の上書きコピーを説明するための図である。
【図９】ＯＳＤのＲＥＡＤ応答メッセージに対してＣＩＦＳのヘッダ部を上書きできない場合のデータ処理を説明するための図である。
【図１０】具体的な実装系に本実施の形態を適用したクライアント装置の構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるファイル管理システムの構成例を示す図である。同図において、ファイル管理システム１は、クライアント装置１０、配置情報管理装置２０、及び複数のストレージサーバ３０等を含む。ファイル管理システム１に含まれる各装置は、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク４０（有線又は無線の別は問わない。）を介して通信可能とされている。なお、複数台のクライアント装置１０や複数台の配置情報管理装置２０が、ファイル管理システム１に含まれてもよい。
【００１１】
ストレージサーバ３０は、いわゆるＮＡＳ（Network Attached Storage）サーバであり、データを格納したファイル群を記憶（管理）する装置である。本実施の形態では、複数のストレージサーバ３０によって、複数のファイルが分散管理される。すなわち、ストレージサーバ３０は、本実施の形態においてファイル管理装置の一例である。なお、本実施の形態において、ストレージサーバ３０は、便宜上、ＯＳＤ（Object-based Storage Device）サーバであるとする。ＯＳＤサーバは、管理しているファイルに関して、オブジェクトベースのインタフェースを提供するサーバをいう。したがって、ストレージサーバ３０とのファイル操作に関する通信は、ＯＳＤプロトコルに基づいて行われる。
【００１２】
配置情報管理装置２０は、複数のストレージサーバ３０に分散管理されている、各ファイルの配置情報を記憶する装置である。配置情報とは、ファイルの配置位置を示す情報である。すなわち、配置情報管理装置２０は、各ファイルがいずれのストレージサーバ３０に配置されているかを示す情報を管理する。なお、本実施の形態において、配置情報管理装置２０は、便宜上、ＣＩＦＳ（Common Internet File System）サーバであるとする。すなわち、配置情報管理装置２０との通信は、ＣＩＦＳプロトコルに基づいて行われる。ＣＩＦＳプロトコルは、本実施の形態において第一のプロトコルの一例である。
【００１３】
クライアント装置１０は、いわゆるＮＡＳクライアントである。すなわち、クライアント装置１０は、ストレージサーバ３０において管理されているファイルの操作元となるコンピュータである。クライアント装置１０は、本実施の形態において、分散ファイル操作装置の一例である。
【００１４】
図２は、本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。同図において、クライアント装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。
【００１５】
クライアント装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１６】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってクライアント装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００１７】
なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。
【００１８】
また、クライアント装置１０が、ユーザによって直接操作される場合、クライアント装置１０は、キーボード及びマウス等の入力装置や、液晶ディスプレイ等の表示装置等を備えていてもよい。また、配置情報管理装置２０及びストレージサーバ３０についても、図２と同様のハードウェア構成を有していればよい。
【００１９】
図３は、本発明の実施の形態におけるファイル管理システムの機能構成例を示す図である。
【００２０】
同図において、ストレージサーバ３０は、サーバ部３１及びファイル記憶部３２等を有するファイル記憶部３２は、ストレージサーバ３０の補助記憶装置を用いてファイルの実体を記憶する。サーバ部３１は、ＯＳＤプロトコルに従って、クライアント装置１０からのファイル操作要求を受信する。サーバ部３１は、ファイル操作要求に係る処理を、ファイル記憶部３２に記憶されているファイルに対して実行し、処理結果を含む応答をＯＳＤプロトコルに従って返信する。ＯＳＤプロトコルは、本実施の形態において、第二のプロトコルの一例である。
【００２１】
配置情報管理装置２０は、配置情報管理部２１及び配置情報記憶部２２等を有する。配置情報記憶部２２は、複数のストレージサーバ３０に分散管理されている、各ファイルの配置情報を、配置情報管理装置２０の補助記憶装置を用いて記憶する。配置情報管理部２１は、操作対象とされたファイルの配置情報の取得要求を受信し、当該ファイルの配置情報を配置情報記憶部２２より取得する。配置情報管理部２１は、取得された配置情報をクライアント装置１０に返信する。
【００２２】
クライアント装置１０は、クライアント部１１、ファイル操作プロトコル制御部１２、フィルタ部１３、及び通信制御部１４等を有する。これら各部は、クライアント装置１０にインストールされるプログラムがＣＰＵ１０４に実行させる処理によって実現される。なお、各部は、一つのプログラムによって実現されなくてもよい。例えば、本実施の形態において、フィルタ部１３は、他の各部からは独立した別個のプログラムによって実現される。当該別個のプログラムは、分散ファイル操作プログラムの一例である。
【００２３】
クライアント部１１は、ファイルの操作要求元となるソフトウェア（例えば、アプリケーションプログラム等）である。クライアント部１１は、例えば、入力装置より入力されるファイルの操作指示又はネットワークを介して受信されるファイルの操作指示に応じ、当該操作指示に対応するファイルの操作要求をファイル操作プロトコル制御部１２に入力する。当該操作要求は、ファイル操作プロトコル制御部１２が提供するインタフェース（例えば、関数群）を介して入力される。
【００２４】
ファイル操作プロトコル制御部１２は、クライアント部１１より入力されたファイル操作要求に応じた、ＣＩＦＳプロトコルに基づくリクエストメッセージ（以下、「ＣＩＦＳリクエストメッセージ」という。）を生成する。すなわち、ファイル操作プロトコル制御部１２は、ストレージサーバ３０において管理されているファイルに対する操作要求をＣＩＦＳに基づいて生成する。なお、本実施の形態において、ファイル操作プロトコル制御部１２は、第一制御部の一例である。
【００２５】
通信制御部１４は、クライアント装置１０がネットワーク４０を介して行う通信を、インタフェース装置１０５を用いて制御する。通信制御部１４は、ＣＩＦＳよりも下位の層の通信プロトコルに基づく通信を制御する。「ＣＩＦＳより下位」とは、例えば、ＯＳＩ基本参照モデルにおける各層の上下関係に基づく表現である。例えば、通信制御部１４は、ＴＤＩ（transport driver interface ）によって通信要求の受け付け等を行う。ＴＤＩは、トランスポート層とセッション層との間の共通インタフェースであり、トランスポート層の違いを吸収する役割を有する。
【００２６】
なお、通常、ファイル操作プロトコル制御部１２によって生成されたＣＩＦＳリクエストメッセージは、通信制御部１４に入力され、通信制御部１４によって送出される。また、当該ＣＩＦＳメッセージに対する応答メッセージが通信制御部１４によって受信されると、通信制御部１４は、ファイル操作プロトコル制御部１２に対して当該応答メッセージを通知する。
【００２７】
ここで、「通常」とは、フィルタ部１３が存在しない場合をいう。但し、本実施の形態では、フィルタ部１３が存在する。したがって、「通常」とは異なる制御がフィルタ部１３によって行われる。すなわち、フィルタ部１３は、通信制御部１４へ入力される通信要求を横取り（インターセプト）する。したがって、フィルタ操作制御部からのＣＩＦＳリクエストメッセージもフィルタ部１３によって横取りされる。フィルタ部１３は、横取りしたＣＩＦＳリクエストメッセージにおいて操作対象とされているファイルの配置情報を配置情報管理装置２０に問い合わせる。フィルタ部１３は、配置情報管理装置２０より返信される配置情報が示すストレージサーバ３０へ、当該ファイルの操作要求を送信（転送）する。なお、ストレージサーバ３０は、ＯＳＤプロトコルに対応している。したがって、フィルタ部１３は、ＣＩＦＳリクエストメッセージからＯＳＤプロトコルに応じた操作要求（以下、「ＯＳＤリクエストメッセージ」という。）の変換も行う。変換されたＯＳＤリクエストメッセージは、通信制御部１４によって送信される。フィルタ部１３は、受信される応答に関してもメッセージ形式の変換を行う。このように、フィルタ部１３によって、複数のストレージサーバ３０によるファイルの分散管理に対する対応が行われる。換言すれば、ファイル操作プロトコル制御部１２は、ファイルの分散管理（すなわち、ファイルの配置）については関与しない。ファイル操作プロトコル制御部１２は、対応するサーバが一台であることが前提とされて実装されているからである。なお、本実施の形態においてＣＩＦＳサーバは、配置情報管理装置２０である。したがって、ファイル操作プロトコル制御部１２は、配置情報管理装置２０にファイルが管理されているという前提に基づいて処理を行う。但し、本実施の形態において、配置情報管理装置２０は、ファイルの配置情報の管理に用いられており、ファイルの実体の管理には用いられていない。
【００２８】
フィルタ部１３は、クライアント装置１０に動的に追加可能な形態で実装されることが望ましい。動的に追加可能な形態とは、既存部分（例えば、ファイル操作プロトコル制御部１２、及び通信制御部１４等、クライアント装置１０のＯＳのカーネル部）のソースコードの修正等を要さずに追加可能な形態をいう。例えば、Ｗｉｎｄｏｗｓ（登録商標）においては、フィルタドライバという仕組みが提供されている。したがって、フィルタ部１３は、通信制御部１４に対するフィルタドライバとして実装されてもよい。なお、フィルタ部１３は、本実施の形態において第二制御部の一例である。
【００２９】
以下、クライアント装置１０が実行する処理手順について説明する。図４は、ファイルの操作要求の送信時にフィルタ部が実行する処理手順の一例を説明するためのフローチャートである。
【００３０】
例えば、通信制御部１４に対して何らかの通信要求が入力されると、フィルタ部１３は、当該通信要求を横取りする（Ｓ１０１）。したがって、ファイル操作プロトコル制御部１２によって通信制御部１４に対して入力されるＣＩＦＳリクエストメッセージもフィルタ部１３によって横取りされる。続いて、フィルタ部１３は、横取りした通信要求が、ＣＩＦＳリクエストメッセージであるか否かを判定する（Ｓ１０２）。当該判定は、当該通信要求の所定の部分が、ＣＩＦＳプロトコルに従った形式であるか否かに基づいて行われればよい。当該通信要求がＣＩＦＳリクエストメッセージでない場合（Ｓ１０２でＮｏ）、フィルタ部１３は、当該通信要求をそのまま（加工せずに）通信制御部１４に入力する（Ｓ１０５）。この場合は、当該通信要求が、ファイル操作プロトコル制御部１２以外からの非図示のプログラムモジュールからの通信要求である場合に相当する。すなわち、通信制御部１４は、複数のプログラムモジュールより共用されるため、ファイル操作プロトコル制御部１２以外のプログラムモジュールからの通信要求も通信制御部１４に入力される。
【００３１】
一方、当該通信要求がＣＩＦＳリクエストメッセージである場合（Ｓ１０２でＹｅｓ）、当該ＣＩＦＳリクエストメッセージが示すファイルの操作要求が、ＲＥＡＤ（読み込み）要求又はＷＲＩＴＥ（書き込み）要求であるか否かを判定する（Ｓ１０３）。当該操作要求がＲＥＡＤ要求又はＷＲＩＴＥ要求ではない場合（Ｓ１０３でＮｏ）、フィルタ部１３は、当該ＣＩＦＳメッセージを通信制御部１４にそのまま入力する（Ｓ１０５）。したがって、当該ＣＩＦＳメッセージは、ＣＩＦＳサーバである配置情報管理装置２０に送信される。配置情報管理装置２０の配置情報管理部２１は、当該ＣＩＦＳメッセージに応じた処理を実行し、当該処理の実行結果を含む応答をクライアント装置１０に返信する。例えば、当該ＣＩＦＳメッセージがファイルのオープン要求を示すものであれば、配置情報管理部２１は、ファイルのオープン処理を実行し、当該ファイルの識別子（ファイルＩＤ）を含む応答をクライアント装置１０に返信する。したがって、配置情報管理装置２０は、ファイルのオープン要求に指定されるファイル名とファイルＩＤとの対応情報を記憶しておけばよい。または、配置情報管理装置２０が、ファイル名に基づいてファイルＩＤを導出可能な仕組みが、ファイル管理システム１に実装されていればよい。なお、ファイルＩＤは、ＣＩＦＳにおいて、ファイルを識別するために用いられるＩＤである。当該応答は、通信制御部１４によって受信され、フィルタ部１３を介してファイル操作プロトコル制御部１２に通知される。ファイル制御部は、当該応答に応じた戻り値をクライアント部１１に返却する。
【００３２】
なお、本実施の形態において、ファイルのオープン要求が配置情報管理装置２０に転送されるのは、ＯＳＤプロトコルには、ファイルのオープンという概念が無いためである。したがって、ファイルのオープンという概念を有するプロトコルに基づくストレージサーバ３０が利用される場合、ファイルのオープン要求も、ファイルのＲＥＡＤ要求又はＷＲＩＴＥ要求と同様に、ストレージサーバ３０に転送されるようにしてもよい。
【００３３】
一方、ＣＩＦＳメッセージが示すファイルの操作要求がＲＥＡＤ要求又はＷＲＩＴＥ要求である場合（Ｓ１０３でＹｅｓ）、フィルタ部１３は、ＣＩＦＳリクエストメッセージが示すファイルの操作要求において操作対象とされているファイルの配置情報を配置情報管理装置２０に問い合わせる（Ｓ１０４）。すなわち、フィルタ部１３は、当該配置情報の取得要求を配置情報管理装置２０に送信する。当該取得要求には、ＣＩＦＳリクエストメッセージが示すファイルの操作要求において操作対象とされているファイルのファイルＩＤが指定される。当該ファイルＩＤは、ＣＩＦＳにおいて、ファイルを識別するために用いられるＩＤであり、ＣＩＦＳリクエストメッセージに含まれている。なお、配置情報管理装置２０の識別情報（ＩＰアドレス等）は、予め、クライアント装置１０の補助記憶装置１０２に記録されていればよい。
【００３４】
配置情報管理装置２０において配置情報の取得要求が受信されると、配置情報管理部２１は、当該取得要求に指定されているファイルＩＤに対応する配置情報を配置情報記憶部２２より取得する。配置情報管理部２１は、取得された配置情報を含む応答をフィルタ部１３に返信する。
【００３５】
図５は、配置情報記憶部の構成例を示す図である。同図に示されるように、配置情報記憶部２２は、分散管理されているファイルごとに、ファイルＩＤ、サーバＩＤ、及びオブジェクトＩＤ等が記憶されている。
【００３６】
ファイルＩＤは、上記したようにＣＩＦＳのファイルＩＤである。サーバＩＤ及びオブジェクトＩＤは、本実施の形態における配置情報の一例である。すなわち、サーバＩＤは、ストレージサーバ３０の識別子である。サーバＩＤは、ストレージサーバ３０のＩＰアドレスでもよいし、ＩＰアドレスとは別の識別子であってもよい。後者の場合、配置情報記憶装置２０又はクライアント装置１０は、サーバＩＤとＩＰアドレスとの対応情報を記憶していればよい。オブジェクトＩＤは、ストレージサーバ３０内において、各ファイルを識別するための識別子である。本実施の形態において、ストレージサーバ３０は、各ファイルをオブジェクトとして扱うため、各ファイルの識別子はオブジェクトＩＤと呼ばれる。
【００３７】
したがって、本実施の形態の配置情報管理部２１は、サーバＩＤ及びオブジェクトＩＤを含む応答をクライアント装置１０に返信する。
【００３８】
配置情報の取得要求に対して、配置情報管理装置２０より正常な応答が返信されると（Ｓ１０６でＹｅｓ）、フィルタ部１３は、ＣＩＦＳリクエストメッセージをＯＳＤリクエストメッセージに変換し、当該ＯＳＤリクエストメッセージを送信する（Ｓ１０７）。正常な応答とは、配置情報を含む応答をいう。また、ＯＳＤリクエストメッセージの送信先は、取得された配置情報に含まれているサーバＩＤに係るストレージサーバ３０である。
【００３９】
ＣＩＦＳリクエストメッセージのＯＳＤリクエストメッセージへの変換及びＯＳＤリクエストメッセージの送信は、次のように行われる。ＣＩＦＳリクエストメッセージがＲＥＡＤ要求である場合、ＣＩＦＳリクエストメッセージのヘッダ部の内容に基づいてＯＳＤリクエストメッセージのヘッダ部が生成される。フィルタ部１３は、当該ヘッダ部を通信制御部１４に入力する。通信制御部１４は、当該ヘッダ部を該当するストレージサーバ３０に送信する。なお、ＲＥＡＤ要求の場合、ＣＩＦＳリクエストメッセージにはデータ部は存在しない。したがって、ＯＳＤリクエストメッセージについても、ヘッダ部がその全部となる。また、ＯＳＤリクエストメッセージのヘッダ部には、操作対象のファイルの識別子として、取得された配置情報に含まれているオブジェクトＩＤが指定される。
【００４０】
ＲＥＡＤ要求を示すＯＳＤリクエストメッセージを受信したストレージサーバ３０のサーバ部３１は、当該ＯＳＤリクエストメッセージに指定されているオブジェクトＩＤに対応するファイルよりデータを読み込む。サーバ部３１は、読み込まれたデータをデータ部に含む応答メッセージ（以下、「ＲＥＡＤ応答メッセージ」という。）をＯＳＤプロトコルに基づいて返信する。
【００４１】
一方、ＣＩＦＳリクエストメッセージがＷＲＩＴＥ要求である場合、まず、ＣＩＦＳリクエストメッセージのヘッダ部の内容に基づいてＯＳＤリクエストメッセージのヘッダ部が生成される。フィルタ部１３は、当該ヘッダ部を通信制御部１４に入力する。通信制御部１４は、当該ヘッダ部を該当するストレージサーバ３０に送信する。なお、ＯＳＤリクエストメッセージのヘッダ部には、操作対象のファイルの識別子として、取得された配置情報に含まれているオブジェクトＩＤが指定される。また、ＣＩＦＳリクエストメッセージのヘッダ部のサイズが、ＯＤＡリクエストメッセージのヘッダ部のサイズ以上である場合、後述されるＲＥＡＤ応答メッセージの受信時と同様に、ＣＩＦＳリクエストメッセージのヘッダ部に、ＯＤＡリクエストメッセージのヘッダ部が上書きされてもよい。この場合、ＯＤＡリクエストメッセージのヘッダ部用のバッファ領域（メモリ領域）を改めて確保したり、メモリコピーを行ったりする必要性を無くすことができる。
【００４２】
ＷＲＩＴＥ要求の場合、ＣＩＦＳリクエストメッセージにはデータ部が存在する。データ部は、書き込み要求の対象のファイルに書き込まれるデータを格納する部分である。したがって、ＯＳＤリクエストメッセージについてもヘッダ部の送信に続いて、データ部の送信が行われる。ここで、通信制御部１４がＴＣＰ（Transmission Control Protocol）を利用する場合、データの送信用のインタフェースは、ｉｏｖｅｃ形式（複数バッファ形式）である。したがって、後述されるＲＥＡＤ応答メッセージの受信時とは異なり、ヘッダ部とデータ部との関係（繋がり）は考慮される必要はない。よって、フィルタ部１３は、ＣＩＦＳメッセージに含まれているデータ部をそのまま通信制御部１４に入力する。通信制御部１４は、当該データ部を、該当するストレージサーバ３０に送信する。
【００４３】
ＷＲＩＴＥ要求を示すＯＳＤリクエストメッセージを受信したストレージサーバ３０のサーバ部３１は、当該ＯＳＤリクエストメッセージに指定されているオブジェクトＩＤに対応するファイルに対して、ＯＳＤリクエストメッセージに含まれているデータを書き込む。サーバ部３１は、書き込み処理の結果等を示す応答（以下、「ＷＲＩＴＥ応答」という。）をＯＳＤプロトコルに基づいて返信する。
【００４４】
続いて、ＲＥＡＤ応答メッセージがストレージサーバ３０より返信された際に、クライアント装置１０が実行する処理手順について説明する。
【００４５】
図６は、ＲＥＡＤ応答メッセージの受信に応じてクライアント装置が実行する処理手順の一例を説明するためのフローチャートである。
【００４６】
通信制御部１４によってＲＥＡＤ応答メッセージが受信されると、当該ＲＥＡＤ応答メッセージの受信が、フィルタ部１３に通知される（Ｓ２０１）。より詳しくは、通信制御部１４は、データ（例えば、ＲＥＡＤ応答メッセージ）の受信に応じイベントを発生させる。フィルタ部１３のイベントハンドラは、当該イベントによってデータの受信を検知する。ここで、ＲＥＡＤ応答メッセージには、ＯＳＤプロトコルのヘッダ部及びデータ部が含まれている。通信制御部１４からのイベントでは、ＲＥＡＤ応答メッセージを格納したバッファ（以下、「受信バッファ」という。）の先頭アドレスと受信バッファのサイズとがフィルタ部１３に通知される。
【００４７】
続いて、フィルタ部１３は、ＲＥＡＤ応答メッセージをファイル操作プロトコル制御部１２に通知するための処理に関連するメモリアドレスのアライメントの境界の最大値を判定する（Ｓ２０２）。本実施の形態において、アライメントとは、メモリ領域にデータ等を格納する場合に、その先頭番地（先頭アドレス）が規則的な値となるように調整することをいう。例えば、先頭アドレスが偶数となるようにアライン（位置合わせ）されたり、Ｎバイト境界にアラインされたりする。ＲＥＡＤ応答メッセージをファイル操作プロトコル制御部１２に通知するための処理に関連するメモリアドレスのアライメントとは、例えば、メモリコピーに関するアライメントや、ファイル操作プロトコル制御部１２のＲＥＡＤバッファのアライメント等である。ステップＳ２０２では、これらの各種アライメントの境界の最大値が判定される。例えば、メモリコピーに関するアライメントの境界が４バイトであり、ファイル操作プロトコル制御部１２のＲＥＡＤバッファのアライメントの境界が８バイトである場合、８バイトが最大値とされる。
【００４８】
なお、各種アライメントの境界は、例えば、ＯＳ等より動的に取得可能なシステム環境であれば、ステップＳ２０２において動的に取得されればよい。また、動的に取得可能なシステム環境でなければ、予め計算され、補助記憶装置１０２に記録されている固定値が、ステップＳ２０２において取得されればよい。
【００４９】
続いて、フィルタ部１３は、受信された、ＯＳＤプロトコルのＲＥＡＤ応答メッセージのヘッダ部のサイズ（ヘッダ長）を計算する。また、フィルタ部１３は、これから生成されるＣＩＦＳプロトコルのＲＥＡＤ応答メッセージのヘッダ部のサイズを計算する（Ｓ２０３）。
【００５０】
図７は、ＯＳＤプロトコルのＲＥＡＤ応答メッセージの構造とＣＩＦＳプロトコルのＲＥＡＤ応答メッセージの構造とを示す図である。同図において、（１）は、ＯＳＤプロトコルのＲＥＡＤ応答メッセージ（以下、「ＯＳＤのＲＥＡＤ応答メッセージ」という。）の構造を示す。（２）は、ＣＩＦＳプロトコルのＲＥＡＤ応答メッセージ（以下、「ＣＩＦＳのＲＥＡＤ応答メッセージ」という。）の構造を示す。同図では、各メッセージを構成するフィールド（項目）ごとに、データ型、フィールド名、及び概要が示されている。各フィールドの詳細については、各プロトコルの仕様書に詳しいため、ここでの説明は省略する。
【００５１】
同図に示されるように、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部又はＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を構成する各フィールドのデータ型は、予め決まっている。そして、各フィールドのサイズはデータ型によって決まる。したがって、それぞれのメッセージのヘッダ長は、それぞれのヘッダ部を構成するフィールドのサイズの合計によって算出することができる。
【００５２】
続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ長ＡとＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ長Ｂとを比較する（Ｓ２０４）。ヘッダ長Ａがヘッダ長Ｂ以上である場合（Ｓ２０４でＹｅｓ）、フィルタ部１３は、ヘッダ長Ａとヘッダ長Ｂとの差分α（ヘッダ長Ａ−ヘッダ長Ｂ）が、アライメントの境界の最大値の整数倍であるか否かを判定する（Ｓ２０５）。
【００５３】
差分αが、アライメントの境界の最大値の整数倍である場合（Ｓ２０５でＹｅｓ）、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部に基づいて、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を生成する（Ｓ２０６）。続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージに対して、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部を上書きコピーする（Ｓ２０７）。この際、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスから差分αだけ後方にずらした位置が、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部に一致するように当該ヘッダ部の上書きを行う。なお、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスとは、受信バッファの先頭アドレスと同義である。
【００５４】
図８は、ＯＳＤのＲＥＡＤ応答メッセージに対するＣＩＦＳのヘッダ部の上書きコピーを説明するための図である。
【００５５】
同図において、（Ａ）は、上書き前の受信バッファの内容（すなわち、ＯＳＤのＲＥＡＤ応答メッセージ）を示す。同図の例では、ＯＳＤのＲＥＡＤ応答メッセージのデータサイズはｄ１とされている。
【００５６】
（Ｂ）は、ＣＩＦＳのＲＥＡＤ応答メッセージのヘッダ部（ＣＩＦＳヘッダ部）が上書きされた受信バッファの内容である。（Ｂ）では、ヘッダ長Ａとヘッダ長Ｂとの差分α分だけ後方にずらされてＣＩＦＳヘッダ部が上書きされている。その結果、ＣＩＦＳヘッダ部とデータ部とが連続した状態となる。（Ｂ）に示される、受信バッファの先頭から差分αだけ後方にずらされたアドレスａ以降の部分が、ＣＩＦＳのＲＥＡＤ応答メッセージに相当する。したがって、同図において、ＣＩＦＳのＲＥＡＤ応答メッセージのデータサイズは、ｄ１−αである。
【００５７】
続いて、フィルタ部１３は、ＣＩＦＳのＲＥＡＤ応答メッセージの先頭アドレス（アドレスａ）とデータサイズ（ｄ１−α）とをファイル操作プロトコル制御部１２に通知する（Ｓ２０８）。ファイル操作プロトコル制御部１２は、先頭アドレス及びデータサイズによって特定されるＣＩＦＳのＲＥＡＤ応答メッセージに基づいて、クライアント部１１への応答を行う。
【００５８】
このように、本実施の形態では、ＣＩＦＳのＲＥＡＤ応答メッセージ用に改めてバッファが確保されるのではなく、ＯＳＤのＲＥＡＤ応答メッセージの受信バッファに対してＣＩＦＳヘッダ部の上書きが行われて、ＣＩＦＳのＲＥＡＤ応答メッセージが生成される。したがって、メモリコピーの回数を削減することができ、ＣＰＵの使用率を低く維持することができる。斯かる効果は、ファイルへのアクセス数が増加すればするほど、顕著なものとなる。
【００５９】
また、ＣＩＦＳのＲＥＡＤ応答メッセージの先頭アドレスのずれは、アライメントの境界の最大値の整数倍である。すなわち、当該先頭アドレスのずれは、ＯＳＤのＲＥＡＤ応答メッセージに基づいてＣＩＦＳのＲＥＡＤ応答メッセージが生成され、当該ＣＩＦＳのＲＥＡＤ応答メッセージがファイル操作プロトコル制御部１２に通知されるまでに関連するアライメントの境界の要件を全て満たすものである。したがって、ＣＩＦＳヘッダ部のコピー時や、ファイル操作プロトコル制御部１２への先頭アドレスの通知時等において、処理が不正となるのを回避することができる。
【００６０】
一方、ヘッダ長Ａがヘッダ長Ｂより大きい場合（Ｓ２０４でＮｏ）、ＯＳＤのＲＥＡＤ応答メッセージにＣＩＦＳヘッダ部を上書きすることはできない。また、差分αがアライメントの最大値の整数倍でない場合（Ｓ２０５でＮｏ）、ＣＩＦＳヘッダ部の先頭アドレスをアライメントの境界に一致させることはできない。したがって、これらの場合、フィルタ部１３は、ステップＳ２０６と同様にＣＩＦＳヘッダ部を生成し、生成されたＣＩＦＳヘッダ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する（Ｓ２０９）。続いて、フィルタ部１３は、ＯＳＤのＲＥＡＤ応答メッセージのデータ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する（Ｓ２１０）。ステップＳ２１０において通知される先頭アドレスは、ＯＳＤのＲＥＡＤ応答メッセージの先頭アドレスからヘッダ長Ａだけ後方にずらされた値である。また、ステップＳ２１０において通知されるデータサイズは、ＯＳＤのＲＥＡＤ応答メッセージからヘッダ長を差し引いた値である。但し、当該データ部のサイズは、ＯＳＤのＲＥＡＤ応答メッセージのヘッダ部のｌｅｎフィールド（図７（１）参照）に基づいて特定されてもよい。
【００６１】
図９は、ＯＳＤのＲＥＡＤ応答メッセージに対してＣＩＦＳのヘッダ部を上書きできない場合のデータ処理を説明するための図である。
【００６２】
同図において（Ｃ）は、ステップＳ２０９に対応する。すなわち、受信バッファとは別のメモリ領域に生成されたＣＩＦＳヘッダ部の先頭アドレスｂとデータサイズｄ２とがファイル操作プロトコル制御部１２に通知される。（Ｄ）は、ステップＳ２１０に対応する。すなわち、受信バッファ内のＯＳＤのＲＥＡＤ応答メッセージのデータ部の先頭アドレスｃとデータサイズｄ３とがファイル操作プロトコル制御部１２に通知される。
【００６３】
なお、ＯＳＤのＷＲＩＴＥ応答メッセージが受信された場合は、図６に示されるような複雑な処理は必要とされない。ＷＲＩＴＥ応答メッセージは、データ部を含まないからである。この場合、フィルタ部１３は、受信されたＯＳＤのＷＲＩＴＥ応答メッセージのヘッダ部に基づいて、ＣＩＦＳヘッダ部を生成する。フィルタ部１３は、生成されたＣＩＦＳヘッダ部の先頭アドレスとデータサイズとをファイル操作プロトコル制御部１２に通知する。
【００６４】
上述したように、本実施の形態によれば、ＣＩＦＳリクエストメッセージがフィルタ部１３によって横取りされ、操作対象のファイルの配置情報が示すストレージサーバ３０に、操作要求が転送される。したがって、ファイル操作プロトコル制御部１２や通信制御部１４等の既存部分に対する変更を回避しつつファイルの分散管理に対応することができる。
【００６５】
また、フィルタ部１３は、ＣＩＦＳプロトコルとＯＳＤプロトコルとの間の変換をも行う。その結果、ファイル操作プロトコル制御部１２が対応していないプロトコルに対応したストレージサーバ３０を利用して、ファイルの分散管理を行うこともできる。
【００６６】
なお、ＣＩＦＳプロトコル及びＯＳＤプロトコルは、一例に過ぎない。ＮＦＳ（Network File System）プロトコル等、その他の遠隔的なファイル管理用のプロトコルによって、本実施の形態において例示したプロトコルが代替されてもよい。
【００６７】
また、ファル操作プロトコル制御部１２が利用するプロトコルとフィルタ部１３が利用するプロトコルとは同じでもよい。例えば、配置情報管理装置２０及びストレージサーバ３０の双方がＣＩＦＳサーバであってもよい。この場合、フィルタ部１３によるプロトコルの変換処理は不要となる。
【００６８】
なお、本実施の形態を具体的な実装系に適用した例を図１０に示す。図１０は、具体的な実装系に本実施の形態を適用したクライアント装置の構成例を示す図である。
【００６９】
同図では、Ｗｉｎｄｏｗｓ（登録商標）において採用されているリモートＦＳＤ（FileSystem Driver）の仕組みに対して本実施の形態が適用された例を示されている。
【００７０】
同図のクライアント装置１０ａでは、クライアントアプリケーション１１１、Ｋｅｒｎｅｌ３２．ｄｌｌ１１２及びＮｔｄｌｌ．ｄｌｌ１１３等がクライアント部１１を構成する。また、リダイレクタ１２１と呼ばれるファイルシステムドライバ（ＦＳＤ）とキャッシュマネージャ１２２とがファイル操作プロトコル制御部１２を構成する。また、ＴＤＩフィルタ１３１は、フィルタ部１３に相当する。また、プロトコルドライバ１４１は、通信制御部１４に相当する。
【００７１】
クライアントアプリケーション１１１は、ファイルの操作要求元となる任意のアプリケーションプログラムである。クライアントアプリケーションは、Ｋｅｒｎｅｌ３２．ｄｌｌ１１２に含まれている関数を呼び出すことにより、ファイルの操作要求を入力する。当該操作要求は、Ｎｔｄｌｌ．ｄｌｌ１１３を介してリダイレクタ１２１に入力される。通常、リダイレクタ１２１が生成し、プロトコルドライバ１４１を介して送信しようとするＣＩＦＳリクエストメッセージは、ＴＤＩフィルタ１３１によって横取りされる。ＴＤＩフィルタ１３１は、図４において説明した処理順を実行して、ＣＩＦＳリクエストメッセージをＯＳＤリクエストメッセージに変換し、ＯＳＤリクエストメッセージの送信をプロトコルドライバ１４１に実行させる。
【００７２】
ＯＳＤリクエストメッセージからの応答がプロトコルドライバ１４１によって受信されると、ＴＤＩフィルタ１３１は、図６を用いて説明した処理手順を実行する。
【００７３】
なお、Ｗｉｎｄｏｗｓ（登録商標）環境において、ＴＤＩフィルタ１３１は、フィルタドライバとして実装されるのが好適である。
【００７４】
図１０の例では、ＴＤＩフィルタ１３１以外の部分に修正を加えることなく、ＴＤＩフィルタ１３１を組み込むことができる。その結果、クライアント装置１０ａについて、既存部分（ＯＳのカーネル等）に変更を回避しつつファイルの分散管理に対応させることができる。
【００７５】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００７６】
以上の説明に関し、更に以下の項を開示する。
（付記１）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行させる分散ファイル操作プログラム。
（付記２）
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータに実行させる付記１記載の分散ファイル操作プログラム。
（付記３）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータに実行させる付記２記載の分散ファイル操作プログラム。
（付記４）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記３記載の分散ファイル操作プログラム。
（付記５）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続される分散ファイル操作装置であって、
ファイルに関する操作要求を第一のプロトコルに基づいて生成する第一制御部と、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する第二制御部と、
を有する分散ファイル操作装置。
（付記６）
前記第二制御部は、前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する付記５記載の分散ファイル操作装置。
（付記７）
前記第二制御部は、前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする付記６記載の分散ファイル操作装置。
（付記８）
前記第二制御部は、前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記７記載の分散ファイル操作プログラム。
（付記９）
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータが、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行する分散ファイル操作方法。
（付記１０）
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータが実行する付記９記載の分散ファイル操作方法。
（付記１１）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータが実行する付記１０記載の分散ファイル操作方法。
（付記１２）
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする付記１１記載の分散ファイル操作方法。
【符号の説明】
【００７７】
１ ファイル管理システム
１０ クライアント装置
１１ クライアント部
１２ ファイル操作プロトコル制御部
１３ フィルタ部
１４ 通信制御部
２０ 配置情報管理装置
２１ 配置情報管理部
２２ 配置情報記憶部
３０ ストレージサーバ
３１ サーバ部
３２ ファイル記憶部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス
【特許請求の範囲】
【請求項１】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行させる分散ファイル操作プログラム。
【請求項２】
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータに実行させる請求項１記載の分散ファイル操作プログラム。
【請求項３】
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータに実行させる請求項２記載の分散ファイル操作プログラム。
【請求項４】
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする請求項３記載の分散ファイル操作プログラム。
【請求項５】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続される分散ファイル操作装置であって、
ファイルに関する操作要求を第一のプロトコルに基づいて生成する第一制御部と、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する第二制御部と、
を有する分散ファイル操作装置。
【請求項６】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータが、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行する分散ファイル操作方法。
【請求項１】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータに、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行させる分散ファイル操作プログラム。
【請求項２】
前記操作要求を第二のプロトコルに基づく形式に変換し、変換後の前記操作要求を前記配置情報に係るファイル管理装置に送信する処理を前記コンピュータに実行させる請求項１記載の分散ファイル操作プログラム。
【請求項３】
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答のヘッダ部に対し、前記第一のプロトコルに応じたヘッダ部を上書きする処理を前記コンピュータに実行させる請求項２記載の分散ファイル操作プログラム。
【請求項４】
前記操作要求に対する応答としてファイルから読み取られたデータを含む、前記第二のプロトコルに基づく応答の受信に応じ、前記応答の第一のヘッダ部の先頭アドレスに対し、前記第一のヘッダ部の長さと前記第一のプロトコルに応じた第二のヘッダ部の長さとの差分だけ後方にずらした位置に前記第二のヘッダ部の先頭アドレスが一致するように、前記第二のヘッダ部を前記第一のヘッダ部に上書きする請求項３記載の分散ファイル操作プログラム。
【請求項５】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続される分散ファイル操作装置であって、
ファイルに関する操作要求を第一のプロトコルに基づいて生成する第一制御部と、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する第二制御部と、
を有する分散ファイル操作装置。
【請求項６】
ファイルの配置情報を管理する配置情報管理装置とファイルを記憶する複数のファイル管理装置とにネットワークを介して接続されるコンピュータが、
ファイルに関する操作要求を第一のプロトコルに基づいて生成し、
前記操作要求に含まれているファイルの識別子を指定して、前記配置情報管理装置に当該ファイルの配置情報を問い合わせ、
問い合わせに応じて返信される前記配置情報が示す前記ファイル管理装置に前記操作要求を送信する、
処理を実行する分散ファイル操作方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−１３７８５０（Ｐ２０１２−１３７８５０Ａ）
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願番号】特願２０１０−２８８３５８（Ｐ２０１０−２８８３５８）
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]