JP2005148962A - ファイルシステム - Google Patents

Abstract

【課題】
従来の計算機システムでは、ファイルのデータが更新されないことを保障しつつクライアントから指定されたファイル名を用いてファイルを管理することができなかった。
【解決手段】
計算機システムは、クライアントからファイルへのアクセス要求を受信する第一の計算機と、第一の計算機に接続され、ファイルの管理情報を格納する第一の記憶装置と、第一の計算機からデータへのアクセス要求を受信する第二の計算機と、第二の計算機に接続され、ファイルデータを格納する第二の記憶装置とを有する。
第一の計算機は、クライアントからファイルデータを受信する毎に、ファイルデータに識別情報を割り当てて、クライアントから指定されるファイル名と当該識別情報とを第一の記憶装置に格納する。また第一の計算機はファイルデータを第二の計算機を介して第二の記憶装置システムに格納する。
【選択図】図１

Description

本発明は、計算機からアクセスされるファイルを格納したファイルシステムに関し、特にネットワークに接続された複数のサーバ計算機及び複数の記憶装置によって実現される分散ファイルシステムに関する。

近年、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）の進化に伴い、さまざまな業務が電子化され、従来紙を用いて処理されていた業務は、電子的なデータである電子ファイル（以下、単に「ファイル」とも言う。）を用いて処理されるようになってきている。一方、契約書や取り引き履歴のように、監査や裁判の証拠として使用される書類は、その書類がオリジナルであり、かつ改ざんされていないことが保障されていなければならない。

現在、電子ファイルを格納するための記憶装置としては磁気ディスクが主流であり、計算機が磁気ディスク上にファイルシステムを構築し、計算機はファイルシステム上にファイルとして電子データを格納する形態が一般的である。磁気ディスクとファイルシステムを用いたファイルの格納方式では、ファイルを変更したり消去したりすることは容易であるため、ファイルがオリジナルであり、かつ改竄されていないことを保証するのは困難であった。

この問題を解決する技術として、例えば特許文献1に挙げられている技術が存在する。この技術では、記憶装置が当該記憶装置に格納するデータ全体からハッシュ値を計算し、算出したハッシュ値をデータの識別子とする。データが異なればハッシュ値も異なるため、ユーザが同じハッシュ値を用いてデータにアクセスする限り、当該データには変更がないことが保障される。

国際公開第９９／３８０９２号パンフレット

特許文献１では、データが変更されていないことを保障することは可能だが、ユーザがデータを取得するためには、当該データに対応するハッシュ値をユーザが記憶装置に対して与える必要がある。従って、保存したデータとハッシュ値の対応をユーザが管理する必要があり、管理コストが大きいという課題がある。

また特許文献１では、ユーザがデータに任意の名前をつけて当該データを記憶装置に保存することができないため、ユーザはハッシュ値を紛失すると、当該データにアクセスできなくなってしまう。

さらに特許文献１では、変更されたデータは元のデータとは全く別のデータとして、記憶装置に登録され管理され、変更後のデータと元のデータとの関係は記憶装置では管理していない。このため、データの変更後に、変更前のデータにデータを復元したい場合には、ユーザが変更前のデータと変更後のデータとの間の関係を管理しておく必要がある。

そこで、クライアント計算機からアクセスされるファイルを格納する計算機システムであって、クライアント計算機からの要求に基づいて記憶装置に格納されるデータ各々に異なる識別情報を付与して一旦格納されたデータは更新されることのないようデータを管理し、当該識別情報とクライアント計算機から指定されるファイル名とを関連付けて管理することのできる計算機システムを開示する。

また、クライアントからライト要求を受信した場合に、更新前のデータと更新後のデータとを関連付けて管理することのできる計算機システムを開示する。

計算機システムは、クライアント計算機からファイルへのアクセス要求を受信する第一の計算機と、第一の計算機に接続され、ファイルの管理情報を格納する第一の記憶装置システムと、第一の計算機からデータへのアクセス要求を受信する第二の計算機と、第二の計算機に接続され、ファイルデータを格納する第二の記憶装置システムとを有する。

第一の計算機は、クライアントからファイルに含まれるファイルデータを受信する毎に、ファイルデータに識別情報を割り当てて、ファイルデータを第二の計算機を介して第二の記憶装置システムに格納する。第一の記憶装置システムは、第一の計算機がファイルデータに割り当てた識別情報と、クライアントから指定されるファイル名とを記憶している。

第一の計算機は、クライアント計算機からファイルへのライト要求を受信すると、第二の記憶装置システムに既に格納されているライト対象のファイルのファイルデータに割り当てられている第一の識別情報とは異なる第二の識別情報を、ライト要求に伴いクライアントから受信するライトデータに割り当てる。そして第一の計算機は、第二の計算機を介して、既に第二の記憶装置システムに格納されているライト対象のファイルのファイルデータとは異なる第二の記憶装置システム内の記憶領域に、ライトデータを格納する。

更に第一の計算機は、第二の識別情報を、ライト対象のファイルのファイル名と第一の識別情報とに対応付けて、第一の記憶装置システムに格納する。

クライアント計算機から受信したライトデータに各々異なる識別情報を付与し、一旦格納されたデータは更新されることのないよう管理すると共に、ライトデータに付与された識別情報とクライアント計算機から指定されるファイル名とを関連付けて管理する計算機システムが実現できる。

また、更新前のデータと更新後のデータとを関連付けて管理することのできる計算機システムが実現できる。

以下、図を用いて本発明の実施形態を説明する。尚、以下に説明する実施形態により、本発明が限定されるものではない。

図１は本発明におけるファイルシステムの概念の一例を示す図である。

本発明のファイルシステムは、ファイル１２０と、ファイル１２０やＶｉｅｗ１００が登録されるView１００とで構成される。

View100は図１に示す例のように、階層構造を有しており、例えば図１のView3にはView4が登録されている（以下、図１のView3及びView4の様な階層関係を、View3はView4の親View、View4はView3の子Viewである、と表現する。）。

各Ｖｉｅｗ100はViewデータ110を有しており、Viewデータ110にはファイル１２０の他に子View１００が登録されている。Ｖｉｅｗデータ１１０は、ファイル１２０やＶｉｅｗ１１０が作成されたり、消去されるごとに新たに作成され、当該Viewデータに登録されるファイルやViewの識別情報を有する。Viewデータは、当該Viewデータが作成された時刻情報と共にView内で管理される。従って、Viewデータと当該Viewデータと共に管理されている時刻情報を参照すれば、ファイル１２０やViewの作成、削除等の更新履歴を知ることができる。

例えば図１の例では、Ｖｉｅｗ４（１００Ａ）にＶｉｅｗデータ１１０ＡとViewデータ１１０Ｂが登録されている。Ｖｉｅｗデータ１１０Ａは時刻date１におけるView4の状態を示す情報を保持しており、Viewデータ１１０Aにはファイル１２０Ａのみが登録されている。つまりViewデータ１１０Aは、View4には時刻date1時点においてファイル１２０Aのみが属していたことを示している。Ｖｉｅｗデータ１１０Ｂは時刻ｄａｔｅ２におけるView４の状態を示す情報を保持しており、Viewデータ１１０Bにはファイル１２０Ａ、１２０Ｂの２つのファイル及びView100Dが登録されている。つまり、Viewデータ１１０Bは、View4にはdate2の時点においてファイル１２０Aとファイル１２０Bの２つのファイル及びView6が属していたことを示している。

また、View100BにはViewデータ１００Cが登録されている。Viewデータ１００Cは時刻date1におけるView3の状態を示す情報であり、Viewデータ１００CにはView4のみが登録されている。つまりViewデータ１００Cは、View3には時刻date1において子ViewであるView4のみが属していたことを示している。またView100BにはViewデータ１００Cの他に登録されているViewデータは存在しないから、時刻date1以降View１００Bの状態に変化がないことも分かる。

このように、Ｖｉｅｗの登録情報に変更がある度にＶｉｅｗデータを作成することで、任意の時点におけるファイルおよびＶｉｅｗのセットをファイルシステム内で管理することができる。

図２は、本発明を適用した計算機システムの一例を示す図である。本計算機システムは、ユーザが使用する複数の計算機（以下クライアントと呼ぶ。）１０００、ファイル管理情報（以下メタデータと呼ぶ。）を管理するサーバ計算機であるコントロールノード（以下ＣＮと呼ぶ。）１２００、ＣＮ1200と接続されメタデータを格納する記憶装置１２３０Ａ、ファイルデータやViewデータを管理するサーバ計算機であるストレージノード（以下ＳＮと呼ぶ。）１３００、ＳＮ１３００と接続されファイルデータやViewデータを格納する記憶装置１２３０Ｂ、ＮＦＳプロトコルを用いてファイルアクセスを行う計算機（以下、ＮＦＳクライアントと呼ぶ。）１１００、ＣＩＦＳプロトコルを用いてファイルアクセスを行う計算機（以下ＣＩＦＳクライアントと呼ぶ。）１１１０、ＮＦＳプロトコルやＣＩＦＳプロトコルに従ったファイルアクセス要求をＣＮ１２００が用いているファイルアクセスプロトコルに変換する計算機（以下レガシーゲートウェイと呼ぶ。）１６００、レガシーゲートウェイ１６００に接続されレガシーゲートウェイがＮＦＳクライアント１１００やＣＩＦＳクライアント１１１０から受信したファイルデータを一時的に格納する記憶装置１２３０Ｃ、ＣＮ１２００やＳＮ１３００と連携するサーバ計算機（以下、外部ノードと呼ぶ。）１５００、外部ノード１５００に接続され外部ノードが使用するデータを格納する記憶装置１２３０D、および本計算機システムを管理する計算機（以下管理ノードと呼ぶ。）１４００を有する。

複数のクライアント１０００、ＣＮ１２００、ＳＮ１３００、ＮＦＳクライアント１１００、ＣＩＦＳクライアント１１１０、レガシーゲートウェイ１６００、外部ノード１５００、管理ノード１４００は、ネットワーク１７００によって接続され、これらの計算機は相互に通信可能である。

図13はSN1300及び記憶装置1230Bの一例を示す図である。

SNはプロセッサ、プロセッサによって実行されるストレージサーバプログラム（以下S-SVR1330と呼ぶ。）を格納したメインメモリ、入出力部、ネットワークに接続するためのネットワークインタフェース、及び記憶装置に接続するためのディスクアダプタを有する計算機である。ここでS-SVR1330は、CN1200がNFSやCIFSの様な一般的なファイルアクセスプロトコルを用いて、記憶装置1230Bに格納されているファイルデータやViewデータにアクセスできるよう、制御するためのプログラムである。

尚、クライアント１０００、ＣＮ１２００、ＮＦＳクライアント１１００、ＣＩＦＳクライアント、外部ノード１５００、管理ノードも、図13に示すＳＮ1300と同様の構成を有しているが、メインメモリに格納されるプログラムやデータが、ＳＮ1300とは異なる。また、クライアント1000、ＮＦＳクライアント１１００、ＣＩＦＳクライアント１１１０、管理ノード１４００はディスクアダプタを有していない点も、ＳＮ１３００とは異なる。

記憶装置1230Ｂは、計算機と接続するためのアダプタ、計算機から受信したデータやディスクから読み出したデータを一時的に格納するキャッシュメモリ、メインメモリ、メインメモリに格納されたプログラムやデータを用いてディスクを制御するディスク制御プロセッサ、ディスクに接続するためのディスクアダプタ、及び一または複数のディスクを有する。ディスクには、ファイルデータを格納しているファイルコンテナ１３１０及びViewデータを格納しているViewコンテナ１３２０が格納されている。

尚、記憶装置１２３０Ａ、記憶装置１２３０Ｃ、記憶装置１２３０Ｄも図13に示す記憶装置1230Ｂと同様の構成を有しているが、ディスクに格納されているデータは記憶装置1230Ｂとは異なる。

更に、ＳＮ1300と記憶装置1230Ｂは、ＮＡＳ(Network Attached storage)として１の筐体内に構成された１の装置であっても良い。同様に、ＣＮ1200と記憶装置1230Ａ、レガシーゲートウェイ1600と記憶装置1230Ｃ、及び外部ノード1500と記憶装置1230Ｄも各々NASとして一筐体内に構成されていても良い。

図２に戻って計算機システムの説明を続ける。

ＣＮ１２００は、クライアント１０００やレガシーゲートウェイと通信する時の接続情報(以下セッション情報と呼ぶ。)を保持するセッションテーブル（以下ＳＴと呼ぶ。）１２１０、オープンしたファイルの情報を保持するオープンファイルテーブル（以下ＯＦＴと呼ぶ。）１２６０、ファイルの管理を行うプログラムであるコントロールサーバ（以下ＣＳＶＲと呼ぶ。）１２７０、記憶装置１２３０Ａ上のデータベースを管理するデータベース管理サーバプログラム（以下ＤＢＭＳと呼ぶ。）１２２０をメインメモリ内に格納している。

記憶装置１２３０Ａは、ファイルやＶｉｅｗの属性情報を格納するデータベースである属性テーブル（以下ＡＴと呼ぶ。）１２４０、ファイルやＶｉｅｗの位置情報を格納するデータベースであるロケーションテーブル（以下ＬＴと呼ぶ。）１２５０をディスクに格納している。

外部ノード１５００は、ファイルシステムのアクセス履歴を管理するプログラムである履歴マネージャ１５１０、ユーザへの課金情報を管理するプログラムである課金マネージャ１５２０、アクセス権限情報を管理するプログラムであるＡＣＬマネージャ１５３０、ファイルの検索を行なう検索プログラム１５４０をメインメモリに格納している。図２に示す例では、これらのプログラムは、一つの外部ノード１５００に搭載されているが、各プログラムがそれぞれ異なる計算機に搭載されていてもよい。

記憶装置１２３０Ｄは、外部ノード１５００上の履歴マネージャ１５１０、課金マネージャ１５２０、ＡＣＬマネージャ１５３０のそれぞれが使用するデータベースをディスク内に格納する。

図３は、本実施形態におけるファイルの管理方法を説明する図である。ファイルは、ファイルの属性情報を保持するファイル属性エントリ２０００と、ファイルの実体でありユーザによって格納されるファイルデータを格納するファイルコンテナ１３１０で構成されている。

ファイル属性エントリ２０００は記憶装置１２３０AのＡＴ１２４０に保持され、ファイルコンテナ１３１０は記憶装置１２３０Ｂに保持される。

ファイル属性エントリ２０００は、C-SVR1270によってファイルデータに付与される計算機システム内で一意な識別子であるＧＵＩＤ、ユーザがファイルに付与する文字列名であるname、ファイルの作成日付であるＣｄａｔｅ、ファイルの更新日付であるＭｄａｔｅ、ファイルコンテナ１３１０に格納されているファイルデータのサイズを示すsize、ファイルの操作種別を示すｔｙｐｅ、更新前のファイルの元データの識別子であるａｎｃ＿ＧＵＩＤ、ファイルコンテナの格納位置を示すロケーション情報であるｃｏｎｔｅｎｔｓ＿Ｌｏｃ、ｃｏｎｔｅｎｔｓ＿Ｌｏｃで示されるファイルコンテナがファイルのどのオフセットのデータを保持しているのかを示すｃｏｎｔｅｎｔｓ＿Ｉｎｆｏ、ファイルに対するアクセス制御情報を保持するサーバの位置情報であるＡＣＴ＿ＭＧＲ＿ＩＤ、ファイルに対する課金情報を保持するサーバの位置情報であるＡＣＴ＿ＭＧＲ＿ＩＤで構成される。

ここでファイルの操作種別には、ＷＯＲＭ型と追記型の２種類がある。ＷＯＲＭ型ファイルは、一旦ファイルコンテナ1300にファイルデータが書き込まれ当該ファイルコンテナがファイル属性エントリ2000に登録されると、当該ファイルコンテナにデータを追記することができなくなるファイルである。追記型ファイルは、ファイルデータが書き込まれたファイルコンテナ1300がファイル属性エントリ2000に登録された後も、当該ファイルコンテナ1300にデータを追記できるファイルである。但し追記型ファイルにおいても、すでに書き込み済みのデータを上書きすることはできない。本実施形態においては、ファイルの操作種別はWORM型であるものとする。

図３の例は、ファイル属性エントリ２０００Ｂとファイルコンテナ１３１０Ｂで構成されるファイル（以下ファイルＢと呼ぶ。）と、ファイルＢの情報の一部を変更して作成されたファイル（以下ファイルＡと呼ぶ）との関係を示している。

ファイルＢは５１２ＭＢのデータをファイルコンテナ１３１０Ｂに保持している。

ファイルＡはファイルコンテナ1310Bに保持されたファイルBのファイルデータのうち、オフセット０からオフセット２００Ｍまでに対応するが変更されているファイルである。ファイルAはファイル属性エントリ２０００Ａ及びファイル属性エントリ２０００Ｂとファイルコンテナ１３１０Ａ及びファイルコンテナ１３１０Ｂとで構成される。ファイル属性エントリ２０００AのGUIDはファイルAに対してC-SVRが付与した識別子であり、ファイルBのGUIDとは異なる値を持つ。ファイル属性エントリ２０００Ａのｃｏｎｔｅｎｔｓ＿Ｌｏｃは、更新されたデータ即ちファイルＢとファイルＡの差分内容を保持するファイルコンテナ１３１０Ａの格納位置を示しており、ファイル属性エントリ２０００Aのｃｏｎｔｅｎｔｓ＿Ｉｎｆｏは、更新されたデータがファイルAのどの部分に相当するデータであるかを示すオフセットを示している。また、ファイル属性エントリ２０００Ａのａｎｃ＿ＧＵＩＤは、ファイルＢのＧＵＩＤを保持している。従ってファイル属性エントリ２００Aのanc_GUIDを用いれば、クライアント計算機からファイルAに対するアクセスがあった場合に、ファイルコンテナ１３１０Ａが保持していないデータをファイルＢのファイルコンテナを参照して取得することが可能となる。

図４はＶｉｅｗの管理方法の一例を示している。Ｖｉｅｗには、ファイルや子Ｖｉｅｗのユーザから指定された文字列名とそのファイル若しくは子Viewの識別子であるＧＵＩＤのペアを複数登録することができ、Viewを用いることによって、ユーザは文字列名を指定してファイルを特定することができるようになる。また、外部ノード１５００上の検索エンジン１５４０とViewとを連携させ、検索エンジンが実行されることによって得られた結果をViewに登録することができる。また、検索方法をスクリプトファイルとして記憶装置１２３０Dに格納しておき、定期的に当該スクリプトファイルを検索エンジン１５４０が実行して、その検索結果をViewに登録することで、動的なＶｉｅｗの更新を行うことができる。

ＶｉｅｗはＶｉｅｗ属性エントリ２１００とＶｉｅｗコンテナ２２００で構成される。

Ｖｉｅｗ属性エントリは、C-SVR1270によってViewに付与される計算機システム内で一意な識別子であるＧＵＩＤ、ユーザがViewに付与する文字列名であるname、Viewの作成日付であるＣｄａｔｅ、Viewの更新日付であるＭｄａｔｅ、View属性であることを示すｔｙｐｅ、親ViewのGUIDであるparent_GUID、Viewコンテナの格納位置を示すｃｏｎｔｅｎｔｓ＿Ｌｏｃ、Viewコンテナ内に格納される最新のViewデリミタのViewコンテナの先頭位置からのオフセットであるcontents_info、Viewに対するアクセス制御情報を保持するサーバを示すＡＣＴ＿ＭＧＲ＿ＩＤ、Viewに対する課金情報を保持するサーバを示すＡＣＴ＿ＭＧＲ＿ＩＤに加え、スクリプトファイルのＧＵＩＤであるｓｃｒｉｐｔ＿ＧＵＩＤ、スクリプトの実行間隔を示すｓｃｒｉｐｔ＿ｉｎｔｅｒｖａｌを有する。View属性エントリ２１００は、ファイル属性エントリ同様、記憶装置1230AのＡＴ１２４０に格納される。このため、ｔｙｐｅの値によりＶｉｅｗ属性かファイル属性かを判断する。前述の通り、ファイル属性の場合には、ＷＯＲＭ型か追記型のいずれかの値がｔｙｐｅに格納される。Ｖｉｅｗ属性の場合は、Ｖｉｅｗ型を示す値が格納される。

Ｖｉｅｗコンテナ２２００は、複数のＶｉｅｗデリミタ２２１０と複数のＶｉｅｗデータ２２２０で構成される。

Ｖｉｅｗデリミタ２２１０はＶｉｅｗデータ２２２０とペアでＶｉｅｗコンテナ２２００に登録され、Ｖｉｅｗデータ２２２０の登録時刻ｄａｔｅ、Ｖｉｅｗデータのサイズｓｉｚｅ、一つ前のＶｉｅｗデータのＶｉｅｗコンテナ先頭からのオフセットＰｒｅｖで構成される。Ｖｉｅｗデータ２２２０はファイルの文字列名（以下ファイル名ともいう。）とファイルのＧＵＩＤのペアあるいは、Ｖｉｅｗの文字列名（以下View名ともいう。）とＶｉｅｗのＧＵＩＤのペアを複数保持する。

ある任意の時刻におけるファイルやViewを取得するには、CN1200のC-SVR1270がＶｉｅｗデリミタ２２１０に登録されている時刻を参照し、当該任意の時刻以前の時刻であって当該任意の時刻に最も近い時刻が登録されているViewデリミタ２２１０に対応するＶｉｅｗデータ２２２０を取得し、このViewデータ2220に登録されているGUIDを用いてファイル属性エントリ2000やView属性エントリ2100を検索すれば良い。検索の結果、ファイルコンテナ1310若しくはViewコンテナ2200の格納位置が分かれば、C-SVR1270は当該任意の時刻におけるファイルやViewのデータを取得することができる。

図４に示すView属性エントリ2100Aは図1のView４のView属性エントリを、Viewコンテナ2200Aは図１のView4のViewコンテナを、View属性エントリ2100Bは図１のView4の子ViewであるView6のView属性エントリを示している。

図４の例では、Ｖｉｅｗデリミタ２２１０ＡとＶｉｅｗデータ２２２０ＡがViewコンテナ２２００Aに登録された時点(date1時点)では、Ｖｉｅｗ4にはＦｉｌｅ１が登録されていたことを示している。このＶｉｅｗ４に対しdate2時点までにＦｉｌｅ２とView6を登録すると、Ｖｉｅｗデータ２２２０ＢとＶｉｅｗデリミタ２２１０ＢがＶｉｅｗコンテナ２２００Aに追加される。また、Ｖｉｅｗ属性エントリ2100Aのｃｏｎｔｅｎｔｓ＿ｉｎｆｏには、Ｖｉｅｗデリミタ２２１０ＢのＶｉｅｗコンテナ先頭からのオフセットが設定される。従ってC-SVRはView属性エントリのcontents_infoとcontents_Locを用いれば、最新のＶｉｅｗデータが参照できる。

図４で述べたＶｉｅｗ属性エントリ２１００は、記憶装置1230AのＡＴ１２４０に格納されており、Viewコンテナ2200は記憶装置1230Bに格納されている。

図５はオープンファイルテーブル（以下ＯＦＴとも呼ぶ。）１２６０の構造の一例を示している。OFT1260は、現在オープン中のファイル若しくはViewに関するデータが登録されるテーブルである。ユーザがクライアント1000、NFSクライアント1100、若しくはCIFSクライアント1110を介してCN1200に対し、ファイル若しくはViewの作成要求を送信すると、当該作成要求に基づきオープンされたファイルやViewの情報がOFT１２６０に保持される。

OFT１２６０には、ファイル若しくはViewをユーザが指定する際に用いられるハンドル２３００、オープンされたファイル若しくはViewの識別子であるＧＵＩＤ２３１０、当該ファイルやViewにアクセス可能なユーザの証明情報（以下ＣＲＥＤ）２３２０、セッションテーブルのエントリへのポインタ２３３０、及び当該ファイルやViewを登録している親ＶｉｅｗのＧＵＩＤ（以下親ＧＵＩＤ）２３４０を有している。

図６は、セッションテーブル（以下ＳＴともいう。）１２１０の一例を示している。ＳＴ１２１０はクライアント１０００とＣＮ1200間のユーザ接続情報を保持するテーブルである。クライアントが最初にCNにアクセスする際、クライアントとCNとの間では通信のためのセッションが確立される。セッション確立の際にはクライアントのユーザ認証も実行される。そこでクライアントとCN間でセッションが確立された際に、STには、クライアントとＣＮ1200間の接続を識別するためのセッション番号２４００、接続に使用されるソケットの識別情報２４１０、接続しているユーザの証明情報（以下ＣＲＥＤ）２４２０が登録される。STを用いれば、CNがクライアントから各種要求を受信した場合に、CNはどのセッションを介して受信した要求かを判別することにより、要求を発行したユーザを特定できるため、ファイルアクセス時のアクセス権チェックやファイル作成時のファイル作成ユーザの特定にSTを利用することができる。

以上で説明した計算機システムにおいて、ＣＮ１２００とＳＮ１３００が、クライアント１０００やレガシーゲートウェイ１６００に対して、ファイルの更新情報を保持するファイルシステムを提供する。尚、レガシーゲートウェイ１６００は、ＮＦＳクライアント１１００やＣＩＦＳクライアント１１１０に対し、ＮＦＳプロトコルまたはＣＩＦＳプロトコル等のレガシープロトコルを用いてファイルシステムにアクセスするための機能を提供する。即ち、レガシーゲートウェイは、ＮＦＳクライアント１１００やＣＩＦＳクライアント１１１０から受信した、ＮＦＳプロトコル若しくはＣＩＦＳプロトコルに従う要求を、ＣＮ１２００が処理可能なプロトコルに従う要求に変換して、ＣＮ１２００に送信し、またＣＮ１２００から受信した情報を、ＮＦＳプロトコル若しくはＣＩＳＦプロトコルに従う情報に変換してＮＦＳクライアントやＣＩＦＳクライアントに送信する。また、本実施形態ではＮＦＳプロトコルとＣＩＦＳプロトコルの例を説明しているが、他のプロトコルに対応したゲートウェイを設けることにより、他のプロトコルを用いたクライアントからのファイルシステムアクセスをサポートすることも可能である。

以下、本ファイルシステムにおける新規ファイルの作成処理、既存ファイルへのＷＲＩＴＥ処理および既存ファイルのリード処理を説明する。

始めに、図７を用いて新規ファイルの作成処理について説明する。

クライアント１０００からのファイル作成要求がＣＮ１２００に送信されると、ＣＮ１２００のプロセッサはＣ−ＳＶＲ１２７０を実行する。以下特に断りのない限り、ＣＮ１２００のプロセッサがＣ―ＳＶＲ１２７０を実行することにより行なう処理を、Ｃ−ＳＶＲ１２７０が実行すると表現する。

クライアントから送信されるファイル作成要求には、作成される新規ファイルが登録されるＶｉｅｗ（即ち作成される新規ファイルの親View）のハンドルと、作成されるファイルのファイル名およびファイルの操作種別の情報が含まれる。

尚、後述の様に、ファイルやＶｉｅｗが作成されると、作成されたファイルやＶｉｅｗのハンドルがクライアントに通知される。従って、親Ｖｉｅｗのハンドルは、親Viewが作成された際に既にクライアントに通知されているため、クライアントは予め親Ｖｉｅｗのハンドルを把握しているものとする。

また、クライアントは新規ファイルの親ViewのView名を含むオープン要求を、CNに送信し、オープン要求を受信したC-SVRがView属性エントリ２１００を検索してオープン要求中のView名に対応するGUIDを取得し、更にC−SVRが取得したGUIDを用いてOFTから親Viewのハンドルを取得し、これをクライアントに通知することとしても良い。この場合クライアントはView名を管理していれば、オープン要求をCNに送信することによりViewのハンドルを取得することができるので、Viewハンドルを管理する必要はない。

更には、クライアントが親ViewのView名を含むGUID取得要求をCNに送信し、CNがView名を用いてView属性エントリを検索して対応するGUIDを取得し、当該GUIDをクライアントに通知することとしても良い。その後、クライアントは通知されたGUIDを含むファイル作成要求をCNに送信すればよい。この場合、ファイル作成要求中に既に親ViewのGUIDが含まれているので、後述するステップ3000は省略することができ、ファイル作成要求中のGUIDを用いて後述のステップ3010以降の処理が実行される。

Ｃ−ＳＶＲ１２７０はファイル作成要求に含まれる親Ｖｉｅｗのハンドルを用いてＯＦＴ１２６０を検索し、当該ハンドルが含まれるＯＦＴ内のエントリ（以下ハンドルエントリ）を取得する（ステップ３０００）。

次にＣ―ＳＶＲ１２７０は、取得したハンドルエントリに含まれるＧＵＩＤを用いてＡＴ１２４０を検索し、当該ＧＵＩＤが登録されているＶｉｅｗ属性エントリを取得する。ここで、ＡＴ１２４０の検索は、実際にはＣ−ＳＶＲからの検索要求に従ってＣＮ１２００がＤＢＭＳ１２２０のプログラムを実行することにより実現する。

Ｃ−ＳＶＲ１２７０はＤＢＭＳによって取得したＶｉｅｗ属性エントリのＡＣＬ＿ＭＧＲ＿ＩＤフィールドを参照し、ＡＣＬマネージャ１５３０のＩＤを取得し、取得したＩＤを用いてＡＣＬマネージャ１５３０に対してアクセス権限チェック要求を送信する（ステップ３０１０）。このアクセス権限チェック要求には、ファイル作成要求を送信したユーザのユーザ認証情報（CRED）が含まれる。ACLマネージャは当該CREDで識別されるユーザの、親Viewに対するアクセス権限情報を記憶装置１２３０D内のデータベースから検索して、当該ユーザが親View内にファイルを作成する権限を有するかどうかチェックする。尚、C-SVRは、上述の様に、ST1210を用いることによってユーザ認証情報（CRED）を取得することができる。

次に、Ｃ−ＳＶＲ１２７０は、ＡＣＬマネージャからアクセス権限チェックの結果を受信し、クライアントから指定された親Ｖｉｅｗ内へ、当該クライアントが新規にファイルを作成する権限が有るか否かを調べる（ステップ３０２０）。ファイル作成権限がない場合、Ｃ−ＳＶＲ１２７０はファイル作成失敗という処理結果をクライアントに返信し（ステップ３０８０）、ファイル作成処理を終了する。

ファイル作成権限がある場合、Ｃ−ＳＶＲ１２７０は新規ファイルを作成する（ステップ３０３０）。具体的にはＣ−ＳＶＲは、新規ファイルに対応するファイル属性エントリ２０００をＡＴ１２４０内に設定すると共に、新規ファイルに対してＧＵＩＤを割りあて、クライアントから受信したファイル名と共に当該ＧＵＩＤを新しく設定したファイル属性エントリに格納する。またＣ−ＳＶＲは、クライアントから受信する新規ファイルのファイルデータを、ＳＮ１３００を介して記憶装置１２３０Ｂ内のファイルコンテナ１３１０に格納する。そしてＣ−ＳＶＲは、ファイルの作成時刻、ファイルデータのサイズ、ファイルのタイプ、ファイルデータの記憶装置１２３０Ｂ内での格納位置、ＡＣＬ＿ＭＧＲ＿ＩＤ、ＡＣＴ＿ＭＧＲ＿ＩＤも、ファイル属性エントリに登録する。

Ｃ―ＳＶＲ１２７０は、新規ファイルの作成結果を調べ（ステップ３０４０）、ファイル作成に失敗していることが分かると、ファイル作成失敗という処理結果をクライアントに返信し（ステップ３０８０）、ファイル作成処理を終了する。

ファイル作成に成功するとＣ−ＳＶＲ１２７０は、新規に作成したファイルの、親ＶｉｅｗのＶｉｅｗ属性エントリのｃｏｎｔｅｎｔｓ＿Ｌｏｃとｃｏｎｔｅｎｔｓ＿ｉｎｆｏを用いて、親ＶｉｅｗのＶｉｅｗコンテナから最新のＶｉｅｗデータをＣＮ１２００内部のバッファメモリに格納し、バッファメモリ上のＶｉｅｗデータの最後に、ステップ３０３０で作成したファイルのＧＵＩＤと、クライアントから受信したファイル作成要求に含まれていたファイル名を登録する（ステップ３０５０）。ここでＣ−ＳＶＲ１２７０は、ＮＦＳプロトコルまたはＣＩＦＳプロトコルのような公知技術を用いてＳＮ１３００と通信し、最新のＶｉｅｗデータを取得する。

次にＣ−ＳＶＲ１２７０は、バッファ上に作成したＶｉｅｗデータ用のＶｉｅｗデリミタを作成し、記憶装置１２３０Ｂ内に格納されている親ViewのＶｉｅｗコンテナの最後に、ＳＮ１３００を介して、Ｖｉｅｗデリミタ、Ｖｉｅｗデータの順でこれらのデータを追記する（ステップ３０６０）。

さらに、Ｃ−ＳＶＲ１２７０はＯＦＴ１２６０上に、作成した新規ファイル用のハンドルエントリを作成する（ステップ３０７０）。このときハンドルエントリのＨＡＮＤＬＥ２３００には当該ハンドルエントリのインデックス番号を、ＧＵＩＤ２３１０にはステップ３０３０で作成された新規ファイルのＧＵＩＤを、ＣＲＥＤ２３２０とＳＥＳＳＩＯＮ２３３０にはファイル作成要求を受信したセッションに関する情報が格納されているSTのエントリに登録されているＣＲＥＤおよびＳＥＳＳＩＯＮと同じ値を格納し、親ＶｉｅｗのＧＵＩＤ２３４０には、親ＶｉｅｗのＧＵＩＤを格納する。

最後に、ステップ３０７０でＣ−ＳＶＲは、作成したハンドルエントリのインデックス番号であるハンドルと、ファイル作成に成功したという結果をクライアントに返信してファイル作成処理を終了する（ステップ３０８０）。

以上述べたとおり、本発明ではＣ−ＳＶＲがファイルを新規作成する度に、新しいＶｉｅｗデータがＶｉｅｗコンテナに追記され、古いＶｉｅｗデータが上書きされることはないため、任意の時刻においてＣ−ＳＶＲが管理していたファイルのセットを、後に選び出すことができる。

尚、図７ではファイルの作成処理について説明したが、新規Ｖｉｅｗの作成処理も同様にして実行することができる。Ｖｉｅｗを作成する場合には、クライアントは新規Ｖｉｅｗが登録される親Ｖｉｅｗのハンドル、新規ＶｉｅｗのＶｉｅｗ名を有するＶｉｅｗ作成要求をＣ−ＳＶＲに送信する。また、新規Ｖｉｅｗの作成の場合には図７のステップ３０３０の処理がファイル作成処理とは異なり、Ｃ−ＳＶＲがＶｉｅｗ属性エントリを設定すると共に、新規ＶｉｅｗにＧＵＩＤを割り当て、当該ＧＵＩＤと新規ＶｉｅｗのＶｉｅｗ名を対応付けてＶｉｅｗ属性エントリにする。また、設定されたＶｉｅｗ属性エントリには、親ＶｉｅｗのＧＵＩＤの他、Ｖｉｅｗの作成時刻やタイプ等図4に示すＶｉｅｗ属性エントリ内の他の情報も、Ｃ−ＳＶＲによって設定される。更にＣ−ＳＶＲはＳＮ１３００を介して記憶装置１２３０Ｂ内に新規Ｖｉｅｗ用のＶｉｅｗコンテナを作成する。その他は、Ｖｉｅｗの作成処理も図７に示すファイル作成処理と同様の処理にて実行することができる。

次に、図８を用いてファイル書込み処理について説明する。クライアントからＣＮ１２００に送信されるファイル書き込み要求は、書き込みを行うファイルのハンドル、ライトデータ、書き込み開始オフセット、データサイズで構成される。

尚、書き込み対象のファイルのハンドルは、クライアントが予め取得しているものとする。クライアントが当該ファイルのハンドルを取得する手順は、ファイル作成処理においてクライアントが親Viewのハンドルを取得する手順とほぼ同様である。しかし、Ｖｉｅｗとは異なりファイルの場合は、ファイルが更新されると更新分のデータに対し新しいＧＵＩＤが割り当てられるので、同じファイル名に対応付けられているＧＵＩＤが複数存在する場合がある。

そこで、クライアントがファイル名を含むオープン要求をＣＮに送信して、ＣＮから書き込み対象のファイルのハンドルを取得する場合、オープン要求を受信したＣ―ＳＶＲはクライアントから受信したファイル名を登録している１又は複数のファイル属性エントリのうち、Ｍdateが最も現在の時刻に近い（言い換えればファイル属性エントリに格納されているＧＵＩＤが他のファイルのanc_ＧＵＩＤになっていない）ファイル属性エントリを選択して、このファイル属性エントリに登録されているＧＵＩＤ（以下最新オリジナルＧＵＩＤと呼ぶ。）を用いてＯＦＴからＶｉｅｗハンドルを取得するものとする。

またクライアントがファイル名を含むＧＵＩＤ取得要求をＣＮに送信した場合には、Ｃ−ＳＶＲは最新オリジナルＧＵＩＤをクライアントに返信するものとする。

Ｃ-ＳＶＲ１２７０は、クライアントからの書き込み要求を受信すると、書き込み要求に含まれるハンドルを用いてＯＦＴを検索し、書き込み対象のファイルのハンドルエントリを取得する(ステップ２６００）。

次にＣ―ＳＶＲ１２７０は、ハンドルエントリに含まれるＧＵＩＤ（以下オリジナルＧＵＩＤと呼ぶ。）を用いてＡＴ１２４０を検索し、オリジナルＧＵＩＤに対応するファイル属性エントリ２０００を取得する。ここで、ＡＴ１２４０の検索は、ＣＮ１２００がＤＢＭＳ１２２０のプログラムを実行して実現する。Ｃ-ＳＶＲ１２７０は取得したファイル属性エントリのＡＣＬ＿ＭＧＲ＿ＩＤフィールドを参照してＡＣＬマネージャＩＤを取得し、このACマネージャIDが示すＡＣＬ＿ＭＧＲに対してアクセス権限チェック要求を送信する（ステップ２６１０）。このアクセス権限チェック要求には、ファイル作成処理のステップ３０１０と同様の手順にてＣ−ＳＶＲが取得した、クライアントのユーザ認証情報（ＣＲＥＤ）が含まれており、ＡＣＬ＿ＭＧＲはこのＣＲＥＤを参照してユーザが書き込み対象のファイルに対し、書き込み権限を有するか否かデータベースを検索してチェックする。

次に、Ｃ-ＳＶＲ１２７０は、ＡＣＬ＿ＭＧＲから返信されたアクセス権限チェックの結果を調べる（ステップ２６２０）。ファイル書き込み権限がない場合、Ｃ-ＳＶＲ１２７０はファイル書き込み失敗という処理結果をクライアントに返信し（ステップ２６７０）、ファイル書き込み処理を終了する。

ファイル書き込み権限がある場合、Ｃ-ＳＶＲ１２７０は記憶装置１２３０Ｂ上に新しくファイルコンテナ（以下新規ファイルコンテナと呼ぶ。）を作成するようＳ-ＳＶＲ１３３０に要求し、クライアントから受信したライトデータをＳ−ＳＶＲ1330に送信して、Ｓ−ＳＶＲ１３３０にライトデータを新規ファイルコンテナに格納させる（ステップ２６３０）。このとき、新規ファイルコンテナの作成、および新規ファイルコンテナへのライトデータの格納処理は、Ｃ-ＳＶＲ１２７０とＳ-ＳＶＲ１３３０間でＮＦＳやＣＩＦＳプロトコルのような公知技術を用いて実現できる。

次にＣ-ＳＶＲ１２７０は、新たなＧＵＩＤ（以下新規ＧＵＩＤと呼ぶ）を新規ファイルコンテナに割り当てると共に、ＡＴ１２４０に新規ファイルコンテナに対するファイル属性エントリ１２４０（以下、新規ファイル属性エントリと呼ぶ。）を設定して、このファイル属性エントリに新規ＧＵＩＤを登録する（ステップ２６４０）。更にＣ−ＳＶＲは、新規ファイル属性エントリのＭｄａｔｅに現在の時刻を、ａｎｃ＿ＧＵＩＤにはオリジナルＧＵＩＤを、ｃｏｎｔｅｎｔｓ＿Ｌｏｃには新規ファイルコンテナの記憶装置１２３０Ｂ内のロケーションを、ｃｏｎｔｅｎｔｓ＿ｉｎｆｏにはクライアントから受信したファイル書き込み要求に含まれるオフセットとサイズを格納し、新規ファイル属性エントリのｎａｍｅ、Ｃｄａｔｅ、ｔｙｐｅ、ＡＣＬ＿ＭＧＲ＿ＩＤ、ＡＣＴ＿ＭＧＲ＿ＩＤの各フィールドにはオリジナルＧＵＩＤが登録されているファイル属性エントリの対応するフィールドと同じ値を格納する。またクライアントから受信したファイル書き込み要求中のオフセットとサイズを足した値である書き込み終了オフセット値がオリジナルＧＵＩＤのファイル属性エントリのｓｉｚｅフィールドの値より大きければ、ｓｉｚｅフィールドには書き込み終了オフセットの値が、小さければｓｉｚｅフィールドにはオリジナルＧＵＩＤのファイル属性エントリのｓｉｚｅフィールドの値が格納される。

次に、Ｃ−ＳＶＲ１２７０はＯＦＴ１２６０の書き込み対象ファイルのハンドルエントリに登録されている親ＧＵＩＤ２３４０で示されるＶｉｅｗ（即ち書き込み対象ファイルの親Ｖｉｅｗ）に、新規ファイルを登録する（ステップ２６５０）。この登録処理は以下の手順により実行される。まずＣ−ＳＶＲが、親Ｖｉｅｗの最新ＶｉｅｗデータをＳＮを介して記憶装置１２３０Ｂから読み出し、ＣＮ１２００のバッファに格納する。次にＣ−ＳＶＲは、バッファに格納されたＶｉｅｗデータの中からオリジナルＧＵＩＤが登録されているエントリを検索し、当該エントリ中のオリジナルＧＵＩＤの値を新規ＧＵＩＤに変更する。そしてＣ−ＳＶＲは、Ｓ−ＳＶＲを介して、変更後のＶｉｅｗデータを、最新Ｖｉｅｗデータとして親ＶｉｅｗのＶｉｅｗコンテナに追記する。ここで、変更後のＶｉｅｗデータをＶｉｅｗコンテナに追記する処理は、ＣＮ上に読み込んだＶｉｅｗデータ中のオリジナルＧＵＩＤを新規ＧＵＩＤに変更する点以外は、前述したファイル作成処理のステップ３０５０で説明した処理と同じである。

その後、Ｃ−ＳＶＲ１２７０は、ステップ２６００で取得したＯＦＴ上のハンドルエントリに登録されているＧＵＩＤ２３１０の値を、新規ＧＵＩＤに変更し（ステップ２６６０）、最後にファイル書き込み処理が成功したことを処理結果としてクライアントに返信し、ファイル書き込み処理を終了する。

次に、図１２を用いてファイルのリード処理について説明する。クライアントからＣＮ１２００に送信されるＲＥＡＤ要求には、リード対象のファイルのハンドル、ＲＥＡＤ開始オフセット、データサイズが含まれる。尚、クライアントはファイルへの書き込み処理において説明した手順と同様の手順により、リード対象のファイルのハンドルを予め把握しているものとする。

Ｃ―ＳＶＲ１２７０は、クライアントからのＲＥＡＤ要求を受信すると、ＲＥＡＤ要求に含まれるハンドル番号を用いてＯＦＴを検索し、ハンドルエントリを取得する(ステップ２８００）。

次にＣ―ＳＶＲ１２７０は、ハンドルエントリに含まれるＧＵＩＤを用いてＡＴ１２４０を検索し、当該ＧＵＩＤに対応するファイル属性エントリを取得する。ここで、ＡＴ１２４０の検索は、ＣＮ１２００がＤＢＭＳ１２２０のプログラムを実行して実現する。Ｃ―ＳＶＲ１２７０は取得したファイル属性エントリのＡＣＬ＿ＭＧＲ＿ＩＤフィールドを参照して、ＡＣＬマネージャＩＤを取得し、対応するＡＣＬ＿ＭＧＲに対してアクセス権限チェック要求を送信する（ステップ２８１０）。尚、アクセス権限チェック要求にはユーザ認証情報（ＣＲＥＤ）が含まれること、及びＡＣＬ＿ＭＧＲは当該ＣＲＥＤを用いてユーザのファイルリード権限の有無をチェックすること等は、上述のファイル作成処理、ファイル書き込み処理において説明した手順と同様である。

次に、Ｃ―ＳＶＲ１２７０は、ＡＣＬ＿ＭＧＲから返信されたアクセス権限チェックの結果を調べる（ステップ２８２０）。クライアントを使用しているユーザにＲＥＡＤ対象のファイルに対するＲＥＡＤ権限がない場合、ＣＳＶＲ１２７０はファイルＲＥＡＤ失敗という処理結果をクライアントに返信し（ステップ２８４０）、ファイルＲＥＡＤ処理を終了する。

ユーザにファイルＲＥＡＤ権限がある場合、Ｃ―ＳＶＲ１２７０はステップ２８１０で取得したファイル属性エントリ中のcontents_Locを取得し、記憶装置１２３０Ｂ内のcontents_Locが示す記憶領域上に存在するファイルコンテナから、データを読み出す（ステップ２８３０）。このとき、contents_Locが示すファイルコンテナに含まれるファイルデータは、同じくファイル属性エントリ中のcontents_Infoが示すオフセットとサイズで示される範囲のファイルデータである。このため、クライアントから受信したＲＥＡＤ要求に含まれる開始オフセットおよびデータサイズを、contents_Infoに含まれるオフセットおよびサイズと比較し、READ要求で示される範囲に含まれるファイルデータのみをcontents_Locが示すファイルコンテナから読み出す。ここで、READ要求の開始オフセットおよびデータサイズで示される範囲の全ファイルデータ読み出しが完了すれば、ステップ２８３０を終了する。一方、ステップ２８１０で取得したファイル属性エントリ中のcontents_Locが示すファイルコンテナだけで、READ要求で示される範囲のデータ読み出しが完了していない場合、ステップ２８１０で取得したファイル属性エントリのanc_GUIDに登録されているＧＵＩＤが示すファイル属性エントリ中のcontents_Locを取得して、当該contents_Locが示す記憶領域上に存在するファイルコンテナからも前述と同様の方法でデータを読み出す。ステップ２８３０におけるデータの読み出し処理は、READ要求で示された範囲のデータ読み出しが完了するか、最後のファイル属性エントリ（即ちanc_GUIDにＧＵＩＤが登録されていないファイル属性エントリ）中のcontents_Locが示す記憶領域上のファイルコンテナからデータを読み出すまで続けられる。このとき、ファイルデータの読み出し処理は、Ｃ―ＳＶＲ１２７０とＳ―ＳＶＲ１３３０間でＮＦＳやＣＩＦＳプロトコルのような公知技術を用いて実現できる。

最後にＣ―ＳＶＲ１２７０は、ステップ２８３０で読み出したデータ、読み出したデータのサイズ、および読み出し処理が成功したことを示す処理結果をクライアントに返信し、ファイルリード処理を終了する。

次に、図９を用いて、Ｖｉｅｗデータ取得処理を説明する。クライアント１０００は、Ｖｉｅｗのハンドルと時刻を指定したＶｉｅｗデータ取得要求をＣＮ１２００に送信することによって、指定時刻において指定されたＶｉｅｗに登録されていたファイルやＶｉｅｗを示す、Ｖｉｅｗデータを取得することができる。尚、上述のファイル作成処理にて説明した通り、クライアントはＶｉｅｗデータ取得要求の対象となっているＶｉｅｗのハンドルを予め把握しているものとする。

Ｃ―ＳＶＲ１２７０がクライアントからのＶｉｅｗデータ取得要求を受信すると、Ｃ−ＳＶＲは、Ｖｉｅｗデータ取得要求に含まれるハンドル番号を用いてＯＦＴを検索し、指定されたＶｉｅｗのハンドルエントリを取得する(ステップ２７００）。

次にＣ―ＳＶＲ１２７０は、ハンドルエントリに含まれるＧＵＩＤを用いてＡＴ１２４０を検索し、当該ＧＵＩＤに対応するＶｉｅｗ属性エントリを取得する。ここで、ＡＴ１２４０の検索は、ＣＮ１２００がＤＢＭＳ１２２０のプログラムを実行することにより実現される。Ｃ―ＳＶＲ１２７０はＶｉｅｗ属性エントリのＡＣＬ＿ＭＧＲ＿ＩＤフィールドを参照してＡＣＬマネージャＩＤを取得し、対応するＡＣＬ＿ＭＧＲに対してアクセス権限チェック要求を送信する（ステップ２７１０）。尚、アクセス権限チェック要求にユーザ認証情報（ＣＲＥＤ）が含まれること、Ｃ−ＳＶＲがＣＲＥＤを取得する方法、及びＡＣＬ＿ＭＧＲがユーザのＶｉｅｗデータに対するアクセス権限をチェックする方法等はファイル作成処理と同様である。

次に、Ｃ―ＳＶＲ１２７０は、ＡＣＬマネージャから返信されたアクセス権限チェックの結果を調べる（ステップ２７２０）。クライアントを使用しているユーザにＶｉｅｗデータ取得権限がない場合、Ｃ―ＳＶＲ１２７０はＶｉｅｗデータ取得失敗という処理結果をクライアントに返信し（ステップ２７７０）、Ｖｉｅｗデータ取得処理を終了する。

Ｖｉｅｗデータ取得権限がある場合、Ｃ−ＳＶＲはＤＢＭＳ１２２０を実行してＡＴ１２４０を検索し、ステップ２７００で取得したハンドルエントリ中のＧＵＩＤを含むＶｉｅｗ属性エントリを取得する。さらにＣ−ＳＶＲは、取得したＶｉｅｗ属性エントリのｃｏｎｔｅｎｔｓ＿Ｌｏｃとｃｏｎｔｅｎｔｓ＿ｉｎｆｏを用いて、Ｓ―ＳＶＲ１３３０を介して記憶装置１２３０Ｂ中のＶｉｅｗコンテナから最新のＶｉｅｗデリミタを取得する（ステップ２７３０）。

次にＣ−ＳＶＲは、取得したＶｉｅｗデリミタ中の時刻データ(date)と、クライアントがＶｉｅｗデータ取得要求中で指定した時刻データを比較する（ステップ２７４０）。Ｖｉｅｗデリミタ中の時刻が、クライアントが指定した時刻よりも古くない場合には、Ｃ−ＳＶＲはＳ−ＳＶＲを介して記憶装置１２３０Ｂ内のＶｉｅｗコンテナから、一つ前の世代のＶｉｅｗデリミタを取得する（ステップ２７５０）。Ｃ−ＳＶＲは、ステップ２７４０とステップ２７５０を、クライアントが指定した時刻よりも古いＶｉｅｗデリミタが取得できるまで繰り返す。

Ｃ−ＳＶＲが、クライアントが指定した時刻よりも古い時刻を持つＶｉｅｗデリミタを取得したら、Ｃ−ＳＶＲはＳ−ＳＶＲを介してそのＶｉｅｗデリミタに対応するＶｉｅｗデータを読み込み（ステップ２７６０）、当該Ｖｉｅｗデータをクライアントに送信して処理を終了する。

クライアントに返されたＶｉｅｗデータには、Ｖｉｅｗデータ取得要求においてクライアントが指定した時刻において、Ｖｉｅｗデータ取得要求中でクライアントが指定したＶｉｅｗに登録されている、Ｖｉｅｗ名とそのＶｉｅｗ名に対応するＧＵＩＤのセット、若しくは、ファイル名とそのファイル名に対応するＧＵＩＤのセット、若しくはその双方が含まれている。従って、クライアントは取得したファイルのＧＵＩＤを用いてリード要求をＣＮに発行し、Ｃ−ＳＶＲはクライアントから受信したＧＵＩＤを用いて前述のリード処理を行うことで、クライアントは任意の時点におけるファイルのデータを取得することができる。尚、クライアントはファイルのＧＵＩＤ有するリード要求を発行するので、図１２に示すステップ２８００は省略され、ステップ２８１０以降の処理がリード要求中のＧＵＩＤを用いてＣ−ＳＶＲによって実行される。

この様に、クライアントは最初に時刻とＶｉｅｗを指定したＶｉｅｗデータ取得要求をＣＮに発行して当該時刻におけるＶｉｅｗデータを取得し、次に取得したＶｉｅｗデータに含まれているＧＵＩＤを用いてファイルリード要求を発行することにより、任意時点におけるファイルデータを取得することができる。

尚、これら２つの処理（Ｖｉｅｗデータの取得とファイルデータのリード）を一括して行うインタフェース（たとえば２つの処理を一括して行うよう要求する特別なコマンド等）を設け、クライアントがファイル名と時刻をＣＮに対して指定するだけで、任意時刻のファイルデータを取得できるようにすることも可能である。

以上に説明した様に、ＣＮはクライアントから受信したデータ各々に異なる識別情報を付与し、この識別情報をクライアントから受信したファイル名と関連付けて記憶装置に格納するので、一旦格納されたデータは更新されることのないよう管理すると共に、ライトデータに付与された識別情報とクライアント計算機から指定されるファイル名とを関連付けて管理する計算機システムが実現できる。

また、ＣＮは更新前のファイルデータに付与された識別情報と、ファイルに対するライトデータに付与された識別情報とを関連付けて記憶装置に格納するので、更新前のファイルデータと更新後のファイルデータとを関連付けて管理することのできる計算機システムが実現できる。

更に、計算機システムにレガシゲートウェイを設け、ＮＦＳクライアントやＣＩＦＳクライアントからの要求をＣＮが採用しているプロトコルにレガシゲートウェイが変換してＣＮに送信するので、ＮＦＳやＣＩＦＳのように広く普及したファイルアクセスプロトコルを用いているクライアントからもファイルにアクセスすることができる計算機システムが実現できる。

次に図１０および図１１を用いて、本発明の第二の実施形態を説明する。図１０は本発明が適用される計算機システムの他の一例であり、コントロールノード（以下ＣＮ）１２００とストレージノード（以下ＳＮ）１３００が複数存在する点、イエローページサーバ（以下ＹＰ）１９００が存在する点、およびクライアント１０００とＣＮ１２００の対応を管理するディレクトリサーバ１８００が存在する点が図２に示す実施形態と異なる。

ＹＰ１９００は、ＧＵＩＤが計算機システム内で一意であることを保障するためのサーバである。ＹＰ１９００は計算機システムの未使用ＧＵＩＤを保持し、各ＣＮ１２００からの要求に応じて、一定個数の未使用ＧＵＩＤを一括してCNに割り当てる。各ＣＮ１２００は、ファイルやViewが新規に作成された場合や、ファイルが更新された場合に、ＹＰ１９００から割り当てられた未使用ＧＵＩＤのうちのひとつ選択して、作成されたファイル、View若しくはファイルの更新データに対して当該ＧＵＩＤを割り当てる。このように、ＹＰ１９００が各ＣＮ１２００に対して未使用ＧＵＩＤを一括して割り当てることで、システム内におけるＧＵＩＤの一意性を確保しつつ、ＹＰ１９００へのＧＵＩＤの問い合わせによる負荷を軽減することができる。

ディレクトリサーバ１８００は、クライアント１０００とＣＮ１２００の対応関係を管理するＣＮテーブル（以下ＣＮＴ）１８１０を保持しており、クライアント１０００からの問い合わせに応じて、ディレクトリサーバがＣＮＴテーブルを検索して、問い合わせを行ったクライアント１０００に対応するＣＮ１２００のＩＤを取得し、このＩＤをクライアントに返却する。

図１１はファイルコンテナおよびＶｉｅｗコンテナのロケーションを管理するロケーションテーブル（以下ＬＴ）１２５０の一例を示している。ロケーションテーブルは第一実施例と同様、ＣＮが接続されている記憶装置１２３０Ａ内に格納されており、ＣＮ内のＤＢＭＳによって検索される。ＬＴ１２５０は、ファイルまたはＶｉｅｗのＧＵＩＤを格納するＧＵＩＤフィールド４０００と、ファイルコンテナまたはＶｉｅｗコンテナの第一のロケーションを格納するフィールド（以下第一ロケーション）４１００と、第二のロケーションを格納するフィールド（以下第二ロケーション）４２００を有する。尚図１１は、ロケーションテーブルに2つのロケーション情報が登録されている例を示しているが、ＳＮの数および必要な冗長度に応じてロケーションテーブルに登録されるロケーション情報の数を増減させることも可能である。

第一の実施形態では、ＣＮ１２００がひとつしかなかったため全てのクライアント１０００およびレガシーゲートウェイ１６００からのファイルアクセス要求はひとつのＣＮ１２００に送信されていた。本実施形態では、前述の通りクライアント１０００とＣＮ１２００との対応をディレクトリサーバが管理する。

クライアント１０００は、ファイルアクセス要求（ファイル作成要求、ファイル書き込み要求、ファイルリード要求、Ｖｉｅｗデータ取得要求、オープン要求等を含む。）をＣＮ１２００に送信する前に、ファイルアクセス要求を送信するＣＮ１２００をディレクトリサーバ１８００に問い合わせる。この際クライアントはディレクトリサーバに自身のＩＤを通知する。ディレクトリサーバ１８００はクライアント１０００からの問い合わせを受信すると、問い合わせを送信してきたクライアントのＩＤを用いてＣＮＴ１８１０を検索し、一致したクライアントＩＤに対応するＣＮ１２００のＩＤを取得する。ＣＮ１２００のＩＤが取得できると、問い合わせ要求を送信してきたクライアントに対してＣＮ１２００のＩＤを送信する。

本実施形態では、ＣＮＴ１８１０におけるクライアントとＣＮ１２００との対応は、クライアント１０００の数とＣＮ１２００の数を勘案し静的にＣＮＴに登録されている。しかし、一つのＣＮ１２００に対して同時にアクセスしているクライアント数に偏りが発生した場合、ＣＮＴに登録されているクライアントとＣＮとの対応関係を動的に変更することも可能である。その場合、クライアント１０００からの問い合わせ要求とそれに対する返信をディレクトリサーバ１８００内で管理しておき、各ＣＮ１２００に現在割り当てられているクライアント１０００の数を管理しておく必要がある。

ディレクトリサーバ１８００からのアクセスすべきＣＮのＩＤを受信したクライアント１０００は、受信したＣＮ１２００のＩＤを用いてファイルアクセス要求を送信する。この後は第一の実施形態で記述した処理と同様の処理を行なう。

このように、複数のＣＮ１２００を計算機システム内に設けることにより、クライアントからのアクセスによるＣＮの負荷を適切に分散することができ、計算機システム全体の性能が向上する。また、片方のＣＮ１２００に障害が発生した場合でも、ディレクトリサーバがそれを検知し、障害検知後のクライアント１０００からの問い合わせ要求に対して障害が発生したＣＮ１２００以外のＣＮのＩＤを返すようにすることで、クライアントからのアクセス要求を処理し続けることが可能となり、計算機システムの可用性が向上する。

更に、第一の実施形態においては、ファイルコンテナまたはＶｉｅｗコンテナを格納するＳＮはひとつのみであったが、本実施形態においては、ひとつのファイルあるいはＶｉｅｗに対して複数のファイルコンテナあるいはＶｉｅｗコンテナを割り当て、異なる複数のＳＮを介して異なる複数の記憶装置に格納することができる。

第二の実施形態においては、Ｃ―ＳＶＲ１２７０がファイルコンテナあるいはＶｉｅｗコンテナをアクセスする際、まずＣ―ＳＶＲ１２７０がＤＢＭＳ１２２０を起動して記憶装置内のＬＴ１２５０をアクセスし、第一ロケーション４１００もしくは第二ロケーションのいずれかを選択するようにする。例えば、ＧＵＩＤの値に応じてＣ−ＳＶＲが選択するロケーションを第一ロケーションか第二ロケーションのいずれかにあらかじめ決めておく。そして、Ｃ−ＳＶＲ１２７０は選択したロケーションが示すＳ−ＳＶＲに対してファイルコンテナ若しくはＶｉｅｗコンテナのアクセス処理を実行する。この結果ＳＮ間での負荷分散が可能となる。また、片方のＳＮに障害が発生した場合、障害の発生をＣＮ１２００が検知し、障害検知後にファイルコンテナ若しくはＶｉｅｗコンテナにアクセスする場合には障害の発生していないＳＮを選択することで、計算機システムの耐障害性を向上させることができる。

ファイルシステムの概念の一例を示す図である。 計算機システムの一例を示す図である。 ファイルの構成の一例を示す図である。 Viewの構成の一例を示す図である。 オープンファイルテーブルの一例を示す図である。 セッションテーブルの一例を示す図である。 新規ファイル作成処理の一例を示す図である。 ファイル書き込み処理の一例を示す図である。 Ｖｉｅｗデータ取得処理の一例を示す図である。 計算機システムの他の一例を示す図である。 ロケーションテーブルの一例を示す図である。 ファイルのリード処理の一例を示す図である。 SN及び記憶装置の一構成例を示す図である。

符号の説明

１０００…クライアント
１２００…ＣＮ
１３００…ＳＮ
１２３０…記憶装置
１７００…ネットワーク
１６００…レガシーゲートウェイ
１４００…管理ノード
１５００…外部ノード

Claims (20)

1. クライアント計算機からファイルへのアクセス要求を受信する第一の計算機と、
   前記第一の計算機に接続され、ファイルの管理情報を格納する第一の記憶装置システムと、
   前記第一の計算機からデータへのアクセス要求を受信する第二の計算機と、
   前記第二の計算機に接続され、ファイルデータを格納する第二の記憶装置システムと、
   前記クライアント計算機、前記第一の計算機、及び前記第二の計算機に接続されるネットワークとを有する計算機システムであって、
   前記第一の計算機は、クライアント計算機からファイルデータを受信する毎に、ファイルデータに識別情報を割り当てて、ファイルデータを前記第二の計算機を介して前記第二の記憶装置システムに格納し、
   前記第一の記憶装置システムは、前記第一の計算機がファイルデータに割り当てた識別情報と、クライアントから指定される当該ファイルデータを有するファイルのファイル名とを記憶しており、
   前記第一の計算機は、クライアント計算機からファイルへのライト要求を受信すると、
   前記第二の記憶装置システムに既に格納されているライト対象のファイルのファイルデータに割り当てられている第一の識別情報とは異なる第二の識別情報を、前記ライト要求に伴い前記クライアントから受信するライトデータに割り当て、
   前記第二の計算機を介して、前記ライトデータを、前記第二の記憶装置システムに既に格納されている前記ライト対象のファイルデータとは異なる前記第二の記憶装置システム内の記憶領域に格納し、
   前記第二の識別情報を、前記ライト対象のファイルのファイル名と前記第一の識別情報とに対応付けて、前記第一の記憶装置システムに格納することを特徴とする計算機システム。
2. 請求項１記載の計算機システムにおいて、
   前記第二の記憶装置システムは、ファイルデータを格納するためのファイルコンテナを有しており、
   前記ライトデータは、前記ライト対象のファイルのファイルデータが格納されているファイルコンテナとは異なるファイルコンテナに格納されることを特徴とする計算機システム。
3. 請求項１記載の計算機システムにおいて、
   更にクライアント計算機からのファイルへのアクセス要求を受信し、受信したアクセス要求を前記第一の計算機が使用しているプロトコルに従ったアクセス要求に変換して、変換後のアクセス要求を前記第一の計算機に送信する第三の計算機を有することを特徴とする計算機システム。
4. 請求項１記載の計算機システムにおいて、
   前記第二の記憶装置システムは更に、少なくとも一以上のファイルのファイル名とファイルの識別情報との組を有するビューデータを格納しており、
   前記第一の記憶装置システムは更に、前記ビューデータの格納位置を含むビューの管理情報を格納しており、
   前記第一の計算機は、クライアント計算機からビューデータの読み出し要求を受信した場合に、前記第一の記憶装置システムに格納されているビューの管理情報に基づいて、前記第二の計算機を介して前記第二の計算機からビューデータを読み出すことを特徴とする計算機システム。
5. 請求項４記載の計算機システムにおいて、
   前記第二の記憶装置システムは更に、ビューデータと時刻情報とを関連付けて格納しており、
   ビューデータは、当該ビューデータに関連付けられた時刻情報が示す時刻において、前記第二の記憶装置システムに格納されているファイルデータに対応するファイル名とファイルの識別情報との組を有することを特徴とする計算機システム。
6. 請求項５記載の計算機システムにおいて、
   前記第一の計算機は、クライアント計算機から新規ファイルの作成要求を受信した場合に、作成された新規ファイルのファイル名とファイルの識別情報の組と、前記第二の記憶装置システムに格納されている他のファイルのファイル名とファイルの識別情報の組を有するビューデータを、前記新規ファイルが作成された時刻を示す時刻情報と関連付けて、前記第二の計算機を介して前記第二の記憶装置システムに格納することを特徴とする計算機システム。
7. 請求項５記載の計算機システムにおいて、
   前記第一の計算機は、前記ライト要求を受信した場合に、前記第一の識別情報と前記ファイル名との組、及び前記第二の識別情報と前記ファイル名との組を含むビューデータを、前記ライトデータを前記第二の記憶装置システムに書き込んだ時刻を示す時刻情報と共に、前記第二の計算機を介して前記第二の記憶装置システムに格納することを特徴とする計算機システム。
8. 請求項７記載の計算機システムにおいて、
   前記第一の計算機は、クライアント計算機から時刻情報を含むビューデータ読み出し要求を受信した場合に、ビューデータと関連付けられている時刻情報のうち、ビューデータ読み出し要求に含まれる時刻情報より古い時刻情報の中で最も新しい時刻情報を選択し、選択された時刻情報と関連付けられているビューデータを前記第二の計算機を介して前記第二の記憶装置システムから読み出し、前記クライアント計算機に送信することを特徴とする計算機システム。
9. 請求項１記載の計算機システムにおいて、
   更に、クライアント計算機のファイルに対するアクセス権限をチェックする第三の記憶装置システムを有しており、
   前記第一の計算機は、クライアント計算機からファイルへのアクセス要求を受信した場合に、前記第三の計算機にアクセス権限チェック要求を送信し、前記第三の計算機から受信するアクセス権限のチェック結果に応じて、クライアント計算機からのファイルへのアクセス要求に従って、ファイルへのアクセス処理を実行するか否かを決定することを特徴とする計算機システム。
10. クライアント計算機から受信するファイルへのアクセス要求に従って、ファイルへのアクセス処理を実行するためのプログラムであって、
    前記プログラムは、
    クライアント計算機からファイルへのアクセス要求を受信する第一の計算機と、
    前記第一の計算機に接続され、ファイルの管理情報を格納する第一の記憶装置システムと、
    前記第一の計算機からデータへのアクセス要求を受信する第二の計算機と、
    前記第二の計算機に接続され、ファイルデータを格納する第二の記憶装置システムと、
    前記クライアント計算機、前記第一の計算機、及び前記第二の計算機に接続されるネットワークとを有する計算機システムにおいて実行され、
    前記第一の計算機によって、ファイルデータをクライアント計算機から受信する度に当該ファイルデータに識別情報を割り当てるためのコードと、
    前記第二の計算機によって、前記第一の計算機がクライアント計算機から受信したファイルデータを前記第二の記憶装置システムに格納するためのコードと、
    前記第一の計算機によって、第一の計算機がファイルデータに割り当てた識別情報と、クライアントから指定される当該ファイルデータを有するファイルのファイル名とを前記第一の記憶装置システムに格納するためのコードと、
    前記第一の計算機によって、クライアント計算機からファイルへのライト要求を受信するためのコードと、
    前記第一の計算機によって、前記第二の記憶装置システムに格納されているライト対象のファイルのファイルデータに割り当てられている第一の識別情報とは異なる第二の識別情報を、前記ライト要求に伴い前記クライアントから受信するライトデータに割り当てるためのコードと、
    前記第二の計算機によって、前記ライトデータを前記第二の記憶装置システムに格納するためのコードと、
    前記第一の計算機によって、前記第二の識別情報を、前記ライト対象のファイルのファイル名と前記第一の識別情報とに対応付けて、前記第一の記憶装置システムに格納するためのコードとを有することを特徴とするプログラム。
11. 請求項１０記載のプログラムにおいて、
    前記第二の記憶装置システムは、ファイルデータを格納するためのファイルコンテナを有しており、
    前記ライトデータを前記第二の記憶装置システムに格納するためのコードは、 前記ライトデータを、前記ライト対象のファイルのファイルデータが格納されているファイルコンテナとは異なるファイルコンテナに格納するためのコードを有することを特徴とするプログラム。
12. 請求項１０記載のプログラムにおいて、
    更に前記計算機システムは、前記ネットワークに接続される第三の計算機を有しており、
    前記プログラムは、前記第三の計算機によって、クライアント計算機からのファイルへのアクセス要求を受信し、受信したアクセス要求を前記第一の計算機が使用しているプロトコルに従ったアクセス要求に変換して、変換後のアクセス要求を前記第一の計算機に送信するためのコードを有することを特徴とするプログラム。
13. 請求項１０記載のプログラムにおいて、
    更に、前記第二の記憶装置システムによって、少なくとも一以上のファイルのファイル名とファイルの識別情報との組を有するビューデータを格納するためのコードと、
    前記第一の記憶装置システムによって、前記ビューデータの格納位置を含むビューの管理情報を格納するためのコードと、
    前記第一の計算機によって、クライアント計算機からビューデータの読み出し要求を受信するためのコードと、
    前記第一の計算機によって、ビューデータの読み出し要求に従って、前記第一の記憶装置システムに格納されているビューの管理情報に基づいて、前記第二の計算機を介して前記第二の計算機からビューデータを読み出すためのコードとを有することを特徴とするプログラム。
14. 請求項１３記載のプログラムにおいて、
    前記第二の記憶装置システムによって、ビューデータを格納するためのコードは、ビューデータと時刻情報とを関連付けて格納するためのコードを有しており、
    ビューデータは、当該ビューデータに関連付けられた時刻情報が示す時刻において、前記第二の記憶装置システムに格納されているファイルデータに対応するファイル名とファイルの識別情報との組を有することを特徴とするプログラム。
15. 請求項１４記載のプログラムにおいて、更に、
    クライアント計算機から新規ファイルの作成要求を受信した場合に、前記第一の計算機によって、作成された新規ファイルのファイル名とファイルの識別情報の組、及び前記第二の記憶装置システムに格納されている他のファイルのファイル名とファイルの識別情報の組を有するビューデータを、前記新規ファイルが作成された時刻を示す時刻情報と関連付けて、前記第二の計算機を介して前記第二の記憶装置システムに格納するためのコードを有することを特徴とするプログラム。
16. 請求項１４記載のプログラムにおいて、更に、
    前記ライト要求を受信した場合に、前記第一の計算機によって、前記第一の識別情報と前記ファイル名との組、及び前記第二の識別情報と前記ファイル名との組を含むビューデータを、前記ライトデータを前記第二の記憶装置システムに書き込んだ時刻を示す時刻情報と共に、前記第二の計算機を介して前記第二の記憶装置システムに格納するためのコードを有することを特徴とするプログラム。
17. 請求項１６記載のプログラムにおいて、更に、
    クライアント計算機から時刻情報を含むビューデータ読み出し要求を受信した場合に、前記第一の計算機によって、ビューデータと関連付けられている時刻情報のうち、ビューデータ読み出し要求に含まれる時刻情報より古い時刻情報の中で、最も新しい時刻情報を選択し、選択された時刻情報と関連付けられているビューデータを前記第二の計算機を介して前記第二の記憶装置システムから読み出し、前記クライアント計算機に送信するためのコードを有することを特徴とするプログラム。
18. 請求項１記載のプログラムにおいて、更に
    前記計算機システムは、クライアント計算機のファイルに対するアクセス権限をチェックする第三の記憶装置システムを有しており、
    クライアント計算機からファイルへのアクセス要求を受信した場合に、前記第一の計算機によって、前記第三の計算機にアクセス権限チェック要求を送信し、前記第三の計算機から受信するアクセス権限のチェック結果に応じて、クライアント計算機からのファイルへのアクセス要求に従ってファイルへのアクセス処理を実行するか否かを決定するためのコードを有することを特徴とするプログラム。
19. 計算機システムにおけるファイルへのアクセス方法であって、
    前記計算機システムは、
    クライアント計算機からファイルへのアクセス要求を受信する第一の計算機と、
    前記第一の計算機に接続され、ファイルの管理情報を格納する第一の記憶装置システムと、
    前記第一の計算機からデータへのアクセス要求を受信する第二の計算機と、
    前記第二の計算機に接続され、ファイルデータを格納する第二の記憶装置システムと、
    前記クライアント計算機、前記第一の計算機、及び前記第二の計算機に接続されるネットワークとを有しており、
    前記第二の記憶装置システムは、ファイルデータを格納するためのファイルコンテナを有しており、
    前記第一の計算機が、クライアント計算機からファイルへのライト要求を受信するステップと、
    前記第二の記憶装置システムに格納されているライト対象のファイルのファイルデータに前記第一の計算機が割り当てた第一の識別情報とは異なる第二の識別情報を、前記ライト要求に伴い前記クライアント計算機から受信するライトデータに前記第一の計算機が割り当てるステップと、
    前記第二の計算機がライトデータを、前記ライト対象のファイルのファイルデータが格納されているファイルコンテナとは異なるファイルコンテナに格納するステップと、
    前記第一の計算機が、前記第二の識別情報を、前記ライト対象のファイルのクライアント計算機から指定されたファイル名と前記第一の識別情報と対応付けて前記第一の記憶装置システムに格納するステップとを有することを特徴とするファイルへのアクセス方法。
20. 請求項１９記載のファイルへのアクセス方法であって、
    前記計算機システムは、更にプロトコル変換を実行する第三の計算機を有しており、
    更に、クライアント計算機からのファイルへのアクセス要求を前記第三の計算機が受信するステップと、
    前記第三の計算機が、受信したアクセス要求を前記第一の計算機が使用しているプロトコルに従ったアクセス要求に変換して、変換後のアクセス要求を前記第一の計算機に送信するステップとを有することを特徴とするファイルへのアクセス方法。
    

Images