(57)【特許請求の範囲】
【請求項１】
並列処理システム用の並列仮想ファイルシステムを作成及び使用する方法であって、
ａ．  前記並列処理システムにおいて処理されるデータファイルを区分する段階と、
ｂ．  前記区分を、データファイルとディレクトリを有する１セットの同型データツリーとして前記並列処理システムの記憶装置に記憶する段階を有し、
ｃ．  前記データファイルのファイル構造のモデルを記憶するために、前記並列処理システムの記憶装置上にコントロールツリーを供給する段階を有し、前記コントロールツリーとデータツリーのセットの組合せが、マルチファイルを画定する前記マルチファイルシステム内の同型データファイルのセットと、マルチディレクトリを画定する前記マルチファイルシステム内の同型ディレクトリのセットと共に、前記マルチファイルシステムを画定し、
ｄ．  前記マルチファイルシステムにアクセスする又はこれを変更するための１セットのマルチファイルサブルーチンを供給する段階を有し、前記マルチファイルサブルーチンが、
(1)  遠隔手続き呼出しを使って、前記並列処理システムの処理コンポーネント上のファイルオペレーションを実行し、
(2)  各ファイルオペレーションに含まれるマルチファイル及びマルチデイレクトリ用のトランザクションロックを作成することにより、並列ファイルオペレーションの干渉を防ぎ、
(3)  各ファイルオペレーションの前後に、前記コントロールツリー内の前記データツリーの前記ファイル構造のモデルを維持することにより、前記データツリーの同型性を保存する、
ことを特徴とする方法。
【請求項２】
前記マルチファイルシステムへの構造変更の原子性を確実にするために、前記マルチファイルサブルーチンによって実行される各ファイルオペレーションに、分散トランザクション処理プロトコルを適用する段階をさらに有することを特徴とする請求項１に記載の方法。
【請求項３】
前記ファイルオペレーションによって成された全ての変更が確実に永久化又はロールバックされるようにするために、前記分散トランザクション処理プロトコルが、２位相コミットプロトコルを有することを特徴とする請求項２に記載の方法。
【請求項４】
前記分散トランザクション処理プロトコルが、ファイルオペレーションの最中に障害が起こった場合に、失敗したファイルオペレーションによって実行された部分的変更が未完のまま残るか、又は前記ファイルオペレーションが強制的に終了されるようにするために、各ファイルオペレーションの前に補助情報を記憶する段階を有することを特徴とする請求項２に記載の方法。
【請求項５】
全てのマルチファイル及びマルチディレクトリの各データファイルとディレクトリが、URL指定子によって識別されることを特徴とする請求項１に記載の方法。
【請求項６】
並列仮想システム用の並列仮想ファイルシステムを作成及び使用する方法であって、
(a)  前記並列処理システムにおいて処理されるデータファイルを区分する段階を有し、
(b)  前記並列処理システムの記憶装置に前記区分を記憶する段階を有し、前記記憶装置が、ネイティブデータファイルとネイティブディレクトリを有する１セットの同型データツリーとしてネイティブファイルシステムを有し、
(c)  前記データツリーのネイティブファイル構造のモデルを記憶するために、前記並列処理システムの記憶装置上にネイティブファイルとしてコントロールツリーを供給する段階を有し、前記コントロールツリーと前記データツリーのセットの組合せが、マルチファイルを画定する前記マルチファイルシステム内の同型データファイルのセットと、マルチディレクトリを画定する前記マルチファイルシステム内の同型ディレクトリのセットと共に、前記マルチファイルシステムを画定し、
(d)  前記マルチファイルシステムにアクセスするまたはこれを変更するための１セットのマルチファイルサブルーチンを供給する段階を有し、前記マルチファイルサブルーチンが、
(1)  遠隔手続き呼出しを使って、前記並列処理システムの処理コンポーネント上のネイティブファイルオペレーションを実行し、
(2)  各ネイティブファイルオペレーションに含まれるマルチファイルおよびマルチディレクトリ用のトランザクションロックを作成することにより、並列ネイティブファイルオペレーションの干渉を防ぎ、
(3)  前記コントロールツリー内の前記データツリーの前記ネイティブファイル構造の前記モデルを維持することにより、前記データツリーの同型性を保存する、
ことを特徴とする方法。
【請求項７】
前記マルチファイルシステムへの構造変更の原子性を確実にするために、前記マルチファイルサブルーチンによって実行される各ネイティブファイルオペレーションに、分散トランザクション処理プロトコルを適用する段階をさらに有することを特徴とする請求項６に記載の方法。
【請求項８】
前記ネイティブファイルオペレーションによって成された全ての変更が確実に永久化又はロールバックされるようにするために、前記分散トランザクション処理プロトコルが、２位相コミットプロトコルを有することを特徴とする請求項７に記載の方法。
【請求項９】
前記分配トランザクション処理プロトコルが、ネイティブファイルオペレーションの最中に障害が起こった場合に、失敗したネイティブファイルオペレーションによって実行された部分的変更が未完のまま残るか、又は前記ネイティブファイルオペレーションが強制的に終了されるようにするために、各ネイティブファイルオペレーションの前に補助情報を記憶する段階を有することを特徴とする請求項７に記載の方法。
【請求項１０】
全てのマルチファイルとマルチディレクトリの各データファイルとディレクトリが、URL指定子によって識別されることを特徴とする請求項６に記載の方法。
【請求項１１】
並列処理システム用の並列仮想ファイルシステムを作成及び使用するための、コンピュータ読出し可能媒体上に常駐するコンピュータプログラムであって、
(a)  前記並列処理システムにおいて処理されるデータファイルを区分し、
(b)  前記区分を、データファイルとディレクトリを有する１セットの同型データツリーとして前記並列処理システムの記憶装置に記憶し、
(c)  前記データツリーのファイル構造のモデルを記憶するために、前記並列処理システムの記憶装置上にコントロールツリーを供給し、前記コントロールツリーと前記データツリーのセットの組合せが、マルチファイルを画定する前記マルチファイルシステム内の同型データファイルのセットと、マルチディレクトリを画定する前記マルチファイルシステム内の同型ディレクトリのセットと共に、前記マルチファイルシステムを画定し、
(d)  前記マルチファイルシステムにアクセスする及びこれを変更するための１セットのマルチファイルサブルーチンを供給し、前記マルチファイルサブルーチンが、
(1)  遠隔手続き呼出しを使って、前記並列処理システムの処理コンポーネント上のファイルオペレーションを実行し、
(2)  各ファイルオペレーションに含まれるマルチファイル及びマルチディレクトリ用のトランザクションロックを作成することにより、並列ファイルオペレーションの干渉を防ぎ、
(3)  各ファイルオペレーションの前後に、前記コントロールツリー内の前記データツリーの前記ファイル構造のモデルを維持することにより、前記データツリーの同型性を保存する、
ことをコンピュータに生じさせる命令を有することを特徴とするコンピュータプログラムを記録した記録媒体。
【請求項１２】
前記マルチファイルシステムへの構成変更の原子性を確実にするために、前記マルチファイルサブルーチンによって実行される各ファイルオペレーションに、分散トランザクション処理プロトコルを適用させることをコンピュータに生じさせる命令を有することを特徴とする請求項11に記載のプログラムを記録した記録媒体。
【請求項１３】
前記ファイルオペレーションによって成された全変更が確実に永久化されるか、又はロールバックされるようにするために、前記分散トランザクション処理プロトコルが、２位相コミットプロトコルを有することを特徴とする請求項12に記載のプログラムを記録した記録媒体。
【請求項１４】
前記分散トランザクション処理プロトコルがさらに、ファイルオペレーションの最中に障害が起こった場合に、失敗したファイルオペレーションによって実行さる部分的変更が未完のまま残るか、又は前記ファイルオペレーションが強制的に終了されるようにするために、各ファイルオペレーションの前にコンピュータに補助情報を記憶させる命令を有することを特徴とする請求項12に記載のプログラムを記録した記録媒体。
【請求項１５】
全マルチファイルとマルチディレクトリの書くデータファイルとディレクトリが、URL指定子によって識別されることを特徴とする請求項11に記載のプログラムを記録した記録媒体。
【請求項１６】
並列処理システム用の並列仮想ファイルシステムを作成及び使用するための装置であって、
(a)  前記並列処理システム内で処理されるデータファイルを区分する手段と、
(b)  前記並列処理システムの記憶装置上に前記区分を記憶させる手段を有し、前記記憶装置が、ネイティブデータファイルとネイティブディレクトリを有する１セットの同型データツリーとしてネイティブファイルシステムを有し、
(c)  前記データツリーの前記ネイティブファイル構造のモデルを記憶させるために、前記並列処理システムの記憶装置上にネイティブファイルとしてコントロールツリーを供給する手段を有し、前記コントロールツリーと前記データツリーのセットの組合せが、マルチファイルを画定する前記マルチファイルシステム内の同型データファイルのセットと、マルチディレクトリを画定する前記マルチファイルシステム内の同型ディレクトリのセットと共に、前記マルチファイルシステムを画定し、
(d)  前記マルチファイルシステムにアクセスするまたはこれを変更するための１セットのマルチファイルサブルーチンを供給する手段を有し、前記マルチファイルサブルーチンが、
(1)  遠隔手続き呼出しを使って、前記並列処理システムの処理コンポーネント上のネイティブファイルオペレーションを実行し、
(2)  各ネイティブファイルオペレーションに含まれるマルチファイルおよびマルチディレクトリ用のトランザクションロックを作成することにより、並列ネイティブファイルオペレーションの干渉を防ぎ、
(3)  前記コントロールツリー内の前記データツリーの前記ネイティブファイル構造の前記モデルを維持することにより、データツリーの同型性を保存する、
ことを特徴とする装置。
【請求項１７】
前記マルチファイルシステムへの構造変更の原子性を確実にするために、前記マルチファイルサブルーチンによって実行される各ネイティブファイルオペレーションに、分散トランザクション処理プロトコルを適用する手段を有することを特徴とする請求項16に記載の装置。
【請求項１８】
前記ネイティブファイルオペレーションによって成された全ての変更が確実に永久化又はロールバックされるようにするために、前記分散トランザクション処理プロトコルが、２位相コミットプロトコルを有することを特徴とする請求項17に記載の装置。
【請求項１９】
前記分散トランザクション処理プロトコルがさらに、ネイティブファイルオペレーションの最中に障害が起こった場合に、失敗したネイティブファイルオペレーションによって実行された部分的変更が未完のまま残るか、又は前記ネイティブファイルオペレーションが強制的に終了されるようにするために、各ネイティブファイルオペレーションの前にコンピュータに補助情報を記憶させる命令を有することを特徴とする請求項17に記載の装置。
【請求項２０】
全てのマルチファイル及びマルチディレクトリの各データファイルとディレクトリが、URL指定子によって識別されることを特徴とする請求項16に記載の装置。
【発明の詳細な説明】
１．  発明の分野
本発明は、コンピュータ処理システムに関するものであり、特に、複数記憶装置を備えた単一プロセッサシステムを装備した並列処理システム用の並列仮想ファイルシステムに関するものである。
２．  関連技術の説明
単一プロセッサコンピュータの計算速度は、過去３０年間の間に凄まじい進歩を遂げた。しかし、多くの分野では、最速の単一プロセッサコンピュータさえも超える速度の計算能力が要求されている。この１例は、トランザクション処理である。トランザクション処理は、複数のユーザがコンピュータ資源に同時にアクセスし、また、商用的に許容可能なシステムとしては応答時間が短くなければならない。別の例は、データベースマイニングである。ここでは、数百ギガバイトの情報を処理しなければならず、シリアルコンピュータ上のデータ処理が数日又は数週間かかってしまう。そのため、このような問題を扱う様々な「並列処理」システムが開発された。説明の目的で、並列処理システムには、ローカルの（例えば、ＳＭＰコンピュータのようなマルチプロセッサシステム）、又はローカル的に分散した（例えば、クラスタ又はＭＰＰのような複数プロセッサシステム）、又は遠隔の、或いは遠隔的に分散した（例えば、ＬＡＮ又はＷＡＮネットワークを介して結合した複数のプロセッサ）、又はこれらのあらゆる組合せである複数の中央処理ユニット（ＣＰＵ）を利用したコンピュータのあらゆる構成が含まれる。さらに、本発明の内容において、複数の記憶装置を備えた並列処理システムは単一プロセッサシステムを含んでいる。
以下の手段により並列処理システムのハイパフォーマンスを達成することは慣用手段である。
●  コンピュータがアクセスするデータセットが、いくつかのばらばらな記録のセットに分割（「区分」）され、記憶装置のコレクション上に記憶される。この方法で分割されたデータセットは、「区分編成ファイル」と呼ばれ、各サブ分割は「区分」と呼ばれる。
●  アプリケーションを備え、データを処理するプログラムのいくつかのインスタンスは、プロセッサのコレクション上で実行されるか、又は１つのプロセッサ上で独立したタスクとして実行される。
●各プログラムインスタンスは、処理中の各区分編成ファイルの１つの区分にアクセスする。
この実行の利点は、複数の記憶装置を同時に使用できることにより、高い総合データ転送レートが得られ、また、複数のプロセッサを同時に使用できることにより、高い総合処理レートを得ることができることである。
このようなアプリケーションの開発者は、次に区分編成ファイルの管理及び使用の問題に直面する。その問題の内、直視すべきものは以下の通りである。
●  各区分編成ファイルは、作成され、最終的には削除されなければならない。
●  各区分編成ファイルは、アプリケーションによってアクセスされなければならない。
●  区分編成ファイルは、例えばファイルシステム内に組織されなければならない。
●  区分編成ファイルは、例えば損傷した際には修理するというように管理されなければならない。
これらの問題を解決するための従来技術における１つの方法は、以下の構成における特別なバリアントを用意することである。
●  システム内の各プロセッサが独自の記憶装置のセットを備える。
●  各記憶装置が、「同型」ファイルシステムすなわちファイルとディレクトリの同一配列を備え、ファイルの内容のみがシステム毎に異なるファイルシステムと共にセットアップされている。
●  アプリケーションが区分編成ファイルにおける何らかの変更を行いたい場合（例えば、ファイル作成）、アプリケーションはシステム内の全てのプロセッサのプログラムインスタンスを呼出す。各プログラムには同じパラメータ（例えばファイル名）が与えられている。
●  プログラムの各インスタンスが、ファイルシステムへの構造変更の観点から見て同一に動作することが必要である。例えば、あるプログラムインスタンスがファイルを作成すると、全てのプログラムインスタンスが同じファイルを作成しなければならない（すなわち、同じ名称を持つが、異なるファイルシステム内にあるファイル）。
これらの原理を固守する限り、ファイルシステムは同型である。
この従来技術アプローチはいくつかの有益な特徴を持つ。
●  プログラムが区分内でデータにアクセスする際、標準のファイルシステムインターフェースを使用することができる。
●  全てのファイルシステムが同型構造を有するため、単一ファイルシステム並みの管理で済む。これは、ファイルシステム管理が、主にシステム内のディレクトリとファイルの確立、監視、構造の変更の問題であるためである。同型ファイルシステムのコレクションの構造が単一ファイルシステムのものと同じ位に単純であるので、同型ファイルシステムの管理は、一般的に単一ファイルシステムのものと同じ位に単純である。
しかし、このアプローチにはいくつかの問題が伴う。
●  このような方策を使用したい全てのアプリケーションは、このアプローチの「手仕事による」実行を含まなければならない。
●  ユーザ又はアプリケーションが上述した従来技術からそれた場合には、様々なファイルシステムは徐々に異なる構造を入手する。現在では、管理者は様々な構成ファイルシステムに見られる異なる構造を理解及び管理する必要があるため、一旦同型性が失われると、システム管理がより複雑になってしまう。
●  不注意な時間にシステムがクラッシュした場合、ファイルシステムのみに特定の構造変更が行われた可能性がある。同型性を復旧するために、管理者は各ファイルシステム内を、不一致を探して調査し、意図したファイルシステム構造についての管理者の最上の理解に従って修理する必要がある。さらに、同型性が厳密に強制されていない場合、管理者はどの同型性からの逸脱が意図されたものであり、どれが人為的なものであるかを知る手立てがなくなってしまう。
●  ２つのアプリケーションが同時に「同型」ファイルシステムにアクセスする場合、互いに干渉し合う可能性がある。例えば、アプリケーションプログラムＡがファイルの名称変更を行い、アプリケーションプログラムＢがその同じファイルを削除しようとしたとすると、あるプロセッサではアプリケーションプログラＡが最初に実行されるが（ファイルの名称が変更される）、別のプロセッサではアプリケーションプログラムＢが最初に実行される（ファイルが削除される）。これにより同型性が喪失し、重大な管理問題を引起こしてしまう（恐らく、２つのアプリケーションは同時には実行されていないが、このようなエラーは一般的であり、このような一般的なエラーにとって同型性の喪失は許容できないものである）。
従って、並列処理システムにおける区分編成ファイルの管理方法が必要である。本発明はこのような方法を提供するものである。
発明の概要
本発明は、区分編成ファイルを管理するための並列仮想ファイルシステムであり、その幅広い概要は以下の通りである。
●  区分編成ファイルのパーティションは、１セットの同型の「データツリー」内に記憶される。
●  意図する構成のデータツリーのモデルを構築するために、「コントロールツリー」と呼ばれる追加のディレクトリツリーが使用される。コントロールツリーは、コンピュータシステムがデータツリー内でデータを「探す」（そのパス名を生成する）ことを許容する。
●  コントロールツリーとデータツリーのコレクションとの組合せは、「マルチファイルシステム」と呼ばれる。マルチファイルシステム内のファイルは、「マルチファイル」と呼ばれる。マルチファイルシステム内のディレクトリは「マルチディレクトリ」と呼ばれる。マルチファイル又はマルチディレクトリのデータ要素は「データ層」と呼ばれる。マルチファイル又はマルチディレクトリの制御要素は「コントロール層」と呼ばれる。
●  例えば、データツリーの構造を変更する場合又はマルチファイル又はマルチディレクトリのデータ層用の識別子を入手するといったように、マルチファイルシステムへのアクセス、又はこれを変更するために、１セットのマルチファイルサブルーチンが供給される。実用的には、マルチファイルサブルーチンはネイティブファイルシステムのインターフェース模造を備えている。
●  マルチファイルシステムのへの構造変更の原子性を確実にするために、遠隔手続きコール（ＲＰＣ）を供給し、また、本発明の実施例の１つにおいては分散トランザクション処理プロトコル（例えば、２位相コミット）を供給するマルチファイルサブルーチンが、分散計算環境を使用する。分散計算環境はまた、「分散ファイルオペレーション」（fileops）を供給しなければならない。
●  並列ファイルシステムオペレーションの干渉は、各ファイルシステムに「トランザクション」ロックを作成することによって防止される。
本発明は、トランザクションロックと、また、マルチファイルファイルオペレーションと連携したコントロールツリーの使用を介して同型性を保存する自動システムを含んでいる。データ及びファイルリカバリは、分散トランザクション処理プロトコルの使用によって提供される。
マルチファイルの目的とする使用法は、複数のプロセッサ（又は１つのプロセッサの複数のタスク）上で、複数のプログラムインスタンスの各々をマルチファイルの異なるデータファイル上で実行することによって動作する並列処理システムのコンポーネントとしての使用である。使用の一般的なパターンは次の通りである。
●  マルチファイルシステムにおける構造変更を実施するために、本発明のサブルーチンインターフェースを使用する中央「ドライバプログラム」。
●  様々な複数のプログラムインスタンスのラウンチが可能なドライバプログラム。一般に、マルチファイルシステム内の各データツリーについて１つのプログラムインスタンスが供給され、また、各プログラムインスタンスは一般に、異なる１つのデータツリーの内容に基づいて動作する。
●  上述の段階を、あらゆるアプリケーションにおいて複数回繰返すことができる。
本発明はいくつかの方法で適用できる。
●  アプリケーションの１部として。この場合、マルチファイルサブルーチンは、アプリケーションドライバの１部として含まれる。アプリケーションドライバとマルチファイルサブルーチンは、ドライバに代わって分散プログラムインスタンスを呼出し、マルチファイルソフトウェアに代わってfileopとＲＰＣを呼出す単一分散計算環境へのアクセスを共用する。
●  分散サービスとして。この場合、コントロール及びデータツリーを有するコンピュータの「オーナー」は、少なくとも１つの「マルチファイルサーバ」が常時実行していることを確かめる必要がある。以下に説明するサブルーチンが、サーバの１部としてはめ込まれ、これがさらに分散計算環境に組込まれる。これらのサービスを使用したいアプリケーションは、マルチファイルオペレーションを実行するために分散計算環境を介して適切なサービスと接触する「スタブサブルーチン」を含んでいる。分散計算環境は、マルチファイルソフトウェアに代わってfileopとＲＰＣを呼出す。マルチファイルシステムの採用に必要な作業を最小限にするために、これらのストランドタブサブルーチンはネイティブファイルシステムインターフェースのインターフェースを模造することが好ましい。従来のアプリケーションドライバとプログラムインスタンスの間の通信は、第２分散計算環境によって管理される。また、ドライバとプログラムインスタンスの間の通信は、マルチファイルサーバが使用するものと同一の分散計算環境によって管理されてもよい。
●  オペレーティングシステムの１部として。この場合、一般に、オペレーティングシステムのファイルシステムインターフェースは、マルチファイルコマンドを認識し、「ファイルシステムドライバ」インターフェースを介してこれらをマルチファイルサーバへとディスパッチするように拡張することができる。多くのオペレーティングシステム（例えば、Microsoft社のWindows NTオペレーティングシステム）は、この種の統合を利用するインターフェースを提供する。一旦マルチファイルサーバが係合すると、その実行は分散サービスの場合と非常に類似する。
次に、本発明の好ましい実施例を添付の図面と以下の説明によって説明する。本発明の詳細がわかれば、様々な追加の改良と変更が当業者にとっては明白になるであろう。
【図面の簡単な説明】
第１図は、本発明を備えたコンポーネントの関係を示すブロック図である。
第２図は、本発明のデータ構造を示すブロック図である。
第３図は、本発明の好ましい実施例のデータ構造の使用例を示すブロック図である。
第４図は、複数ファイルシステムのコントロールツリーにアクセスするため、また、本発明の好ましい実施例において一般に他の基本アルゴリズムサブルーチンによって要求される特定の制御情報を抽出するために、ほとんどの好ましいアルゴリズムによって使用されている基本サブルーチンを示すフローチャートである。
第５図は、本発明の第１の別の実施例を備えたコンポーネントの関係を示すブロック図である。
第６図は、本発明の第２の別の実施例を備えたコンポーネントの関係を示すブロック図である。
第７図は、本発明の第３の別の実施例を備えたコンポーネントの関係を示すブロック図である。
図面中で、同一の要素については同一の参照符号及び名称で示している。
発明の詳細な説明
この説明を通して、好ましい実施例及び例は本発明の限定としてよりも、代表例として考慮されるべきである。
概要
本発明は、区分編成ファイルを管理するための並列仮想ファイルシステムを備えている。第１図は、本発明を備えたコンポーネントの関係を示すブロック図である。本発明の好ましい実施例の幅広い特色は以下の通りである。
●  区分編成ファイルのパーティションは、１セットの同型の「データツリー」１内に記憶される（これは同型ファイルシステム使用の原理の穏当な一般化である）。
●  意図する構成のデータツリー１のモデルを構築するために、「コントロールツリー」２と呼ばれる追加のディレクトリツリーが使用される。コントロールツリー２は、コンピュータシステムがデータツリー１内でデータを「探す」（そのパス名を生成する）ことを許容する。
●  コントロールツリー２とデータツリー１のコレクションとの組合せは、「マルチファイルシステム」１０と呼ばれる。マルチファイルシステム１０内のファイルは、「マルチファイルと呼ばれる。マルチファイルシステム１０内のディレクトリは「マルチディレクトリ」と呼ばれる。マルチファイル又はマルチディレクトリのデータ要素は「データ層」と呼ばれる。マルチファイル又はマルチディレクトリの制御要素は「コントロール層」と呼ばれる。
●  例えば、データツリー１の構造を変更する場合又はマルチファイル又はマルチディレクトリのデータ層用の識別子を入手するといったように、マルチファイルシステムへのアクセス、又はこれを変更するために、１セットのマルチファイルサブルーチン４が供給される。実用的には、マルチファイルサブルーチン４はネイティブファイルシステムのインターフェース模造を備えている。
●  マルチファイルシステムのへの構造変更の原子性を確実にするために、遠隔手続きコール（ＲＰＣ）を供給し、また、本発明の実施例の１つにおいては分散トランザクション処理プロトコル（例えば、２位相コミット）を供給するマルチファイルサブルーチン４が、分散計算環境５を使用する。分散計算環境５はまた、マルチファイルＲＰＣsを実現する「分散ファイルオペレーション」（fileop）８（例えば第５図参照）を供給しなければならない。
●  並列ファイルシステムオペレーションの干渉は、各ファイルシステムに「トランザクション」ロックを作成することによって防止される。
マルチファイルの目的とする使用法は、複数のプロセッサ（又は１つのプロセッサの複数のタスク）上で、複数のプログラムインスタンスの各々をマルチチャネルの異なるデータファイル上で実行することによって動作する並列処理システムのコンポーネントとしての使用である。使用の一般的なパターンは次の通りである。
●  マルチファイルシステム１０における構造変更を実施するために、本発明のサブルーチンインターフェースを使用する中央「ドライバプログラム」６。
●  様々な複数のプログラムインスタンス７のラウンチが可能なドライバプログラム。一般に、マルチファイルシステム１０内の各データツリー１について１つのプログラムインスタンス７が供給され、また、各プログラムインスタンス７は一般に、異なる１つのデータツリー１のコンテンツ上で動作する。
●  上述の段階を、あらゆるアプリケーションにおいて複数回繰返すことができる。
データ構造
第２図は、本発明のデータ構造を示すブロック図である。本発明の好ましい実施例中のマルチファイルシステムは、１セットの同型のディレクトリとファイルツリーを備えており、この内の一方がコントロールツリー２を指定され、他方がデータツリー１を指定される。「同型」とは、様々なツリー内のファイルとディレクトリの間の１対１対応を意味し、これにより、特別に記載がない限り、このような全てのツリー内でディレクトリ、サブディレクトリ、ファイルの間の関係が同一になる。さらに、このようなツリーの各々に関連する要素が同一の名称を持っている。しかし、データファイルの内容は、一般に同じにはならない。
「深さ」という用語は、ツリー１の数を表す。マルチファイル２０は、コントロールツリー２内に１つのファイル（「制御ファイル」２１）を備え、関連するファイル（「データファイル」２２）を各データツリー内に備えている。マルチディレクトリ２３は、コントロールツリー内にディレクトリ（「制御ディレクトリ」２４）を備え、関連するディレクトリ（「データディレクトリ」２５）を各データツリー内に備えている。さらに、図に示すように、制御ディレクトリ２４の下に制御ディレクトリ２４ａが作成されてもよく、またさらに、各データディレクトリ２５の下にデータディレクトリ２５ａが作成されていもよい。様々なツリー１、２内の最頂マルチディレクトリ２３は、「ルートマルチディレクトリ」２６又は単に「ルート」と呼ばれる。１セットのホストファイルシステム２７は、データツリー１とコントロールツリー２のためのデータ記憶機構を提供する。
マルチファイル２０のデータファイル２２、又はマルチディレクトリ２３のデータディレクトリ２５はデータ層」と呼ばれる。マルチファイル２０の制御ファイル２１、マルチディレクトリ２３の制御ディレクトリ２４は「コントロール層」と呼ばれる。制御及びデータ層は総体的に「層」と呼ばれる。
好ましい実施例において、全てのマルチファイル/マルチディレクトリの全ての層が、好ましい実施例において下に示す形式を持ったテキストストリングである「ユニフォーム・リソース・ロケータ」（ＵＲＬ）によって識別される。
file://hostname/filename
ここで、‘file’指定子が文字通り受取られ、‘hostname’指定子は有効なインターネットホストネームであり、‘filename’指定子は、ネイティブファイルシステム上での有効なホストのファイル名である。分散/ネットワーク環境内のオブジェクトを識別するためにＵＲＬを使用することが一般的な実施である。この解釈は、ＵＲＬが、“hostname”と呼ばれるホスト上でのアクセスが可能な“filename”と呼ばれるファイルを参照するということである。
ＵＲＬ内の“file”指定子が“mfile”指定子によって置換される場合を除いて、マルチファイル２０又はマルチディレクトリ２３は、そのコントロール層のＵＲＬによって識別される。
コントロールツリー２は、様々なマルチファイル/マルチディレクトリのデータ層を探すのに必要な情報を記憶する。この情報は、ルートコントロール層のＵＲＬを含んだ制御ファイル２１の形式をとる。唯一の例外は、ルートデータ層用のＵＲＬを追加的に含むルートマルチディレクトリ制御ファイル２１ａだけである。マルチディレクトリ制御ファイル２１ａは、１つのマルチファイルシステムにおけるコントロールツリー２とデータツリー１の間の同型性からの単一退去である。
この因習によれば、“dir”がマルチディレクトリ２３のコントロール層である場合、“dir/.mdir”はそのマルチディレクトリ２３の制御ファイル２１である。
第３図は、本発明の好ましい実施例のデータ構造使用例を示すブロック図である。３つのコンピュータシステム、“master”、“node0”、“node1”を示している。それぞれにディレクトリを指定することにより、これらのシステム上に深度２のマルチファイルシステムを作成することができる。例えば、ルート制御ディレクトリは‘/mfs’、データディレクトリは、‘/disk0’、‘/disk1’であってよい。次に、図に示すように、マルチディレクトリ“foo”とマルチファイル“bar”を作成することができる。このマルチファイルシステムの様々な要素は以下の通りである。
A.  マルチファイルシステムのルート：
1.  URL = mfile://master/mfs
2.  control ply = file://master/mfs
3.  data plies = file://node0/disk0, file://nodel/disk1
4.  control file = file://master/mfs/.mdir
5.  control file contents = file://master/mfs, file://node0/disk0, file://node1/disk1
A.  マルチディレクトリ“foo：”
1.  URL = mfile://master/mfs/foo
2.  control ply = file://master/mfs/foo
3.  data plies = file://node0/disk0/foo, file://nodel/disk1/foo
4.  control file = file://master/mfs/foo/.mdir
5.  control file contents = file://master/mfs
A.  マルチファイル"bar"
1.  URL = mfile://master/mfs/bar
2.  control ply = file://master/mfs/bar
3.  data plies = file://node0/disk0/bar, file://nodel/disk1/bar
4.  control file = file://master/mfs/bar
5.  Control file contents = file://master/mfs
後で説明するアルゴリズムを用いれば、上述したマルチファイル２０とマルチディレクトリ２３のデータ構造の操作、アクセス、管理が可能である。
マルチファイルシステムの保全性を保護する
マルチファイルシステムの保全性の保護にはいくつかの危険が伴う。第１に、複数のユーザが同時にマルチファイルシステムの構造に変更を加えようとした場合、マルチファイルシステムにダメージを与えるように２つの要求が干渉してはならない。第２に、障害（例えばシステムクラッシュ）がマルチファイルシステムにダメージを与えてはならない。
第１の問題は、従来からよく知られているような「２位相ロッキング」プロトコルを採用することで解決できる。好ましい実施例において、並列して実行されている２つのファイルシステムが相互に干渉し合う可能性から守る目的で、特定の資源（例えばファイル、ディレクトリ等）にトランザクション「ロック」を使用して、各々のファイルシステムオペレーションが要求される。各ロックは、「共用モード」又は「独占モード」のどちらかにおいて得ることができる。複数ファイルオペレーションは、特定の資源上に共用モードロックを所有することができる。特定の資源上の独占モードロックは、その資源上にロック（共用又は独占）を所有するファイルシステムオペレーションが他にない場合にのみ得ることができる。最も単純な方法は、ファイルシステムを変更する際の任意時に（例えば、ファイル消去、ディレクトリ名変更）、コントロールツリーのルート上の独占ロックを入手し、コントロールツリー内の情報へのアクセス（例えば読出し）の最中に共用ロックを入手するというものである。ロックはファイルシステムオペレーションの最後に解除される（例えば、従来の２位相ロッキングプロトコルを使用する際のコミット時間）。
この技術は、並列マルチファイルファイルシステムオペレーションが存在する場合の同型性の喪失を防止する。しかし、この技術は、ファイルシステムを変形することができる並列ファイルシステムオペレーションの数を限定してしまう。これを修正するにはロックの粒度を減らす。例えば、各制御ディレクトリは関連するロックを備えている。制御ディレクトリ内のファイル又はディレクトリ上のいかなるオペレーションも、まず、適切な共用モード又は独占モードにおける関連したロックを入手する必要がある。
第２の問題（障害リカバリ）には、障害後に、システムがオペレーションを取消すか、又は無理に終了させるかのどちらかを保証する必要がある。これは、本発明下で、次の２つの異なる傷害リカバリ（ＦＲ）機構によって達成される。
ＦＲ１：全てのオペレーションを、分散トランザクション処理環境の制御下において実行する。システム障害が発生したら、トランザクション処理環境が、様々なファイルに対する部分的変更が確実に「ロールバック」されるようにする。
ＦＲ２：各オペレーションの開始時又はその付近に、補助情報を記憶するため、システム障害が発生した場合でも「ファイルシステムリカバリ」プログラムが妨害されたオペレーションによって実行された部分的変更を取消すか、又はオペレーションを強制的に終了する。
第１のファイルリカバリ方法には、次に示す特定のサービスを提供する分散トランザクション処理環境が必要である。
●  トランザクション開始、コミット、ロールバック。これらの用語の意味には、従来より知られる通常の意味を用いる。トランザクション開始命令は、分散計算環境に、後続の分散オペレーションの全てが１つのトランザクションにまとめられることを通知するため、このようなオペレーションの全ての実行が永久的にされるか、又はロールバックされる。トランザクションコミットオペレーションは、永久化されるトランザクション内で分散オペレーションの実行を生じる。ロールバックオペレーションは、取消されるトランザクション内で分散オペレーションの実行を生じる。万一障害が発生した場合には、コミットされていない全てのオペレーションにロールバックが自動的に開始される。あらゆる永続的なデータ記憶（例えば、“状態情報を入手”）を変更しないオペレーションの場合には、トランザクション開始とトランザクションコミットオペレーションを省略してもよい。
●  遠隔手続きコール（ＲＰＣ）。ＲＰＣ命令は、「命令識別子ストリング」によって指定されたサブルーチンを、「ホストネーム」によって指定されたある遠隔システムに呼出される。ＲＰＣ命令の発行元は、指定されたサブルーチンにパスされるパラメータを供給することができ；サブルーチンはRPCの発行元に戻される値を戻す。ＲＰＣがなんらかの永久データ構造（例えば、データ記憶システムの内容）を変更すると、ＲＰＣは分散計算環境によって画定されたトランザクションプロトコルに参加しなければならないため、もしトランザクションがロールバックされるとＲＰＣの実行は取消され、もしトランザクションがコミットされるとＲＰＣの実行は永久化される。
●  分散トランザクションファイルオペレーション（“fileops”）。fileopは、ＲＰＣを介して呼出すことができるサブルーチンであって、ネイティブファイルシステムに構造的変更を行うため、fileopは使用中の分散トランザクション処理スキームに参加することができる。これらの"fileop"は、分散トランザクション処理プロトコルに参加しなければならない。
従来技術では、分散トランザクション特徴を実行するために一般に使用される「２位相コミット」プロトコルを説明している。上の説明で必要とされる分散トランザクションとＲＰＣの組合せを実行する、市販のプログラム(Transarc製造のENCINAのような「トランザクションモニタ」)がある。
トランザクションfileopsは従来技術の１部ではないが、本発明の譲受人に譲渡された、１９９６年７月２日出願の出願番号第08/678,398号の、同時係属の米国特許出願明細書第“Restoring the State of a Set of Files”に説明されている。この明細書の開示については本明細書中で参照することで採用している。
トランザクションfileopsと共に分散トランザクション処理環境を使用することにより、複数のシステム上で記憶システムに構造変更を行うことができる。これにより、１）このような変更の全てが永久的にされるか、２）このような変更の全てがロールバックされる。この技術の組合せにより、マルチファイルシステムのコントロールツリー２とデータツリー１が確実に同型のまま残る。
システム障害が発生した場合、分散トランザクションシステムを使ってコミットされていない変更を全てロールバックする。ロックが使用されている場合には、ロックを解除する前にロールバックを終了しなければならない。
第２のファイルリカバリ方法には、以下に示す機能を支持する分散計算環境のみが必要である。
●  遠隔手続き呼出し（ＲＰＣ）。これは、トランザクション処理プロトコルと統合する必要がないことを除いて、前述のものと同様である。
●  分散トランザクションファイルオペレーション（“fileop”）。再び、ファイルに対する変更を行うためにＲＰＣSを使用するが、トランザクション処理プロトコルと統合する必要はない。
Open Software Foundationの“Distributed Computing Environment”（ＤＣＥ）スタンダードような様々な分散計算環境によってこれらの必要性を満たすことができる。
次に、不揮発性メモリ（例えば、ルート制御ディレクトリ内のファイル）に「補助情報」を記憶するために、この段階が各マルチファイルシステムアルゴリズム内に挿入される。オペレーションがどの永続的データ記憶にも変更を行わない場合には、「補助情報記憶」段階を省略することもできる。システム障害は発生した場合には、さらなるマルチファイルオペレーションを実行する前に「マルチファイルシステムリカバリ」ユーティリティを実行しなければならない。このユーティリティは補助情報を読取り、進行中のオペレーションを決定し、適切なリカバリルーチン（このようなルーチンの１つは、ファイルシステムの状態を変更する各オペレーションに供給される）を呼出す。
マルチファイルオペレーションの一般形式
上述の２つの方法を組合せた、マルチファイルを操作、アクセス、管理するためのアルゴリズムの一般形式を以下に示す。
1)  （ＦＲ１のみ）トランザクション開始
2)  コントロールツリー２のroot上の少なくとも１つの共用ロックを使ってマルチファイルシステムをロックする。資源によっては独占ロックが必要である場合もある。
3)  ＲＰＣを使用して、コントロールツリー２からの情報を読出す。
4)  要求されたオペレーションを実行する許可をユーザが持っているかどうかを決定する。
5)  （ＦＲ２のみ）補助情報を記憶する。
6)  １つ又はそれ以上のＲＰＣを使って、コントロールツリー２及びデータツリー１への変更を行う。
7)  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットするか、又はロールバックする。
8)  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
9)  ロックを解除する。
ＦＲ２を使用する場合、リカバリ時間に特定の動作を実行する。
マルチファイル/マルチディレクトリデータ構造を用いることで、完全な同型性の維持を含む従来技術の問題を回避する方法で区分ファイルを処理するために以下の好ましいアルゴリズムを使用することができる。
(1)  コントロール情報を入手するためのサブルーチン
第４図は、マルチファイルシステム１０のコントロールツリー２にアクセスするために、また、他の基本アルゴリズムサブルーチンによって一般に要求される特定のコントロール情報を抽出するために、ほとんどの好ましいアルゴリズムが使用する基本サブルーチンを示すフローチャートである。このルーチンはシステム内部に位置しており、次に示すＵＲＬとユーザ識別子が与えられていると仮定して、以下情報を入手する。
A.  特定のユーザが、そのファイルに関するどの許可を所有しているかについて表示する。作成許可、削除許可、読出し許可、書込み許可、及び/又は調査許可（ここで、「調査」許可はファイルの存在の有無を知る許可と、その層を見つける許可を含む）。
B.  １）ＵＲＬがマルチファイルと関連するかどうか、２）ＵＲＬがマルチディレクトリと関連するかどうか、３）このようなファイルの存在の有無について表示する。
C.  マルチファイルシステムのrootのためのＵＲＬ。
D.  コントロール層のためのＵＲＬ（これは、上述のように、タイプをfileからmfileに変更された“target”である）。
E.  データ層のためのＵＲＬの列
パラメータ：
A.  target−重要なマルチファイル/マルチディレクトリのURL。“target”のタイプは“mfile”でなければならない。
B.  user−システムの現在のユーザの識別子。
戻り値：
A.  permissions−ＵＲＬに関連したユーザの許可を表示する。また、特にユーザが調査、読出し、書込み、作成、及び/又は削除許可を所有しているかどうかを表示する。初期値は“unknown”である。
B.  category−ＵＲＬがマルチファイル、マルチディレクトリと関連するか、又は何にも関連しないか（すなわち、存在しない）を表示する。初期値は“unknown”である。
C.  root−マルチファイルシステムのルートを表示する。初期値は“unknown”である。
D.  control−コントロール層のＵＲＬ。
E.  expansion−data要素のＵＲＬを表示する。初期値は“unknown”である。
アルゴリズム：
A.  targetからホストネームhostとパスネームpathを抽出する（段階４０）。
B.  このアルゴリズムの残りの段階を実行する。host上のRPCを呼出す（段階４１）。
C.  pathのカテゴリーとuserの許可を決定するために、ネイティブファイルシステムインターフェースを使用する（段階42）。例えば、UNIXオペレーティングシステムにおいては、以下のように行われる。
1.  ユーザがファイルを調査する許可を所有していない場合、permissionsを“none”に設定し、システムから出る。
2.  そうでない場合は、permissionsを“probe”に設定し、継続する。
3.  pathの“parent”ディレクトリを抽出し、parettに記憶する。これは、pathの最後のコンポーネントを取ってしまうことで行える。例えば、“/mfs/foo”の親ディレクトリは“/mfs”である。
4.  pathもparentも存在しない場合には、categoryを“none”に設定し、システムから出る（この場合、作成許可も削除許可も認可されたとは考慮されないことに注意）。
5.  pathが存在しない場合は、categoryを“none”に設定する。
6.  pathがディレクトリに関連する場合は、categoryを“multidirectory”に設定する。
7.  pathがファイルに関連する場合は、categoryを“multifile”に設定する。
8.  pathが存在し、userがpathからの読出し許可を所有する場合は、permissionsに“read”を追加する。
9.  pathが存在し、userがパスへの書込み許可を所有する場合は、permissionsに“write”を追加する。
10.  parentが存在し、userがparentへの書込み許可を所有する場合、permissionsに“create”と“destroy”を追加する。
A.  マルチファイルシステムのルートのＵＲＬを探すために制御２内の情報を調べる（段階４３）。"file"のカテゴリによって適切な方法が異なる。
1.  categoryが“file”である場合、マルチディレクトリコントロールファイルpathからrootを抽出する。
2.  categoryが“none”である場合、親ディレクトリのコントロールファイルparent/.mdirからrootを抽出する。
3.  その他に、categoryが"directory"である場合があるが、この場合は、マルチディレクトリコントロールファイルpath/.mdirからrootを抽出する。
A.  targetのタイプを'mfile'から'file'に変更することにより、コントロールを生成する（段階44）。
B.  以下のようにexpansionを生成する（段階45）：
1.  ルートコントロールファイル(root/.mdir)からルートデータ層のＵＲＬを読出す。このリストをroot_expansionと呼ぶ。
2.  Controlの前部からrootを取り除き、rootからcontrolにパス名を与えることでrelative_pathを生成する。例えば、rootが“file://master/mfs”であり、controlが“file://master/mfs/bar”である場合、relative_pathは“bar”である。
3.  root_expansionにかけてルーピングすることによってexpansionを構成し、このようなＵＲＬの各々にrelative_pathを追加する。例えば、
control             =file://master/mfs/bar
root                =file://master/mfs
relative_path       =bar
root_expansion      =file://node0/disk0,
file://nodel/disk1
その結果、expansionは：
file://node0/disk0/bar,
file://node1/disk1/barとなる。
A.  戻り（ＲＰＣ終了）（段階４６）、サブルーチン終了（段階４７）
(2)  可変コントロールファイルフォーマット
可変コントロールフォーマットを用いて本発明を実行することが可能である。例えばexpansionを予め算出し、これらコントロールファイルに記憶することができる。これが終了したら、次は、コントロールファイル名を変更する際には（例えば「名称変更」オペレーションの後）、コントロールファイルの内容をアップデートするための追加コードが必要である。第２のオプションは、ルートURLをコントロールファイルから取除き、コントロールファイルを空にすることである。これが終了したら、targetの各親ディレクトリでルートマルチディレクトリコントロールファイル２１ａを検索することにより、ルートを探さなければならない。
(3)  マルチファイルシステムのロック/ロック解除
多くのファイルシステムオペレーションでは、同時オペレーションが互いに干渉しあうことを避けるためにファイルシステムの「ロック」又は「ロック解除」が必要である。従来技術は、これを実施するための幅広い方法を提供している。以下はこのオペレーションを達成するための１つの方法である。
A.  （例えば、操作中のマルチファイル/マルチディレクトリのコントロールファイルを読出すことで）マルチファイルシステムルートコントロールファイル２１ａを探す。
B.  主要な操作システム（例えばＵＮＩＸ）によって供給される「ロックファイル」オペレーションを用いてそのファイルをロックする。
C.  オペレーションの最後にそのファイルのロックを解除する。
(2)  エキスパンション
ユーザが書込んだアプリケーションは、マルチファイル/マルチディレクトリのデータ層のＵＲＬを頻繁に見つけなければならない。エキスパンションサブルーチンは、このＵＲＬを見つける能力を提供する。通常は、アプリケーションドライバが、以下のエキスパンションサブルーチンを使用し、各エキスパンション要素につき１つのプログラムインスタンスを作成するためのものである。
アーギュメント：
A.  target−拡張するマルチファイル/マルチディレクトリのURLアルゴリズム：
A.  好ましくはtargetのマルチファイルシステム及びコントロール層上の共用ロックを用いて、マルチファイルシステムをロックする。
B.  targetからコントロール情報を得る。
C.  万一、
1.  ユーザが“probe”許可を所有していない場合、
2.  Expansionが“unknown”である場合（これは、targetもそのディレクトリも存在しない場合に起こる）、
には中断する。
A.  ロックを解除する。
B.  expansionに戻る。
(2)  マルチファイルシステムの作成
このルーチンにより、管理者/ユーザが新規のマルチファイルシステムを作成することができる。このアルゴリズム内の段階は、上述した「通常」の場合とは若干異なる。詳細には、まだコントロールツリーが存在しないため、「コントロール情報入手」サブルーチンを使用することができず、また、やはり同じ理由で、マルチファイルシステムをロックすることができない。（これは理論的には可能であるが、２人の人物が同時に、同じ場所にマルチファイルシステムを作成しようとした場合、適切でない結果を招いてしまうために不可能である。システム管理者は、このルーチンへのアクセスを制御して、このような事態が生じていないことを段階的に確認すべきである。）
アーギュメント：
A.  control−マルチファイルシステムのルートコントロールディレクトリのＵＲＬ。
B.  data−マルチファイルシステムのルートデータディレクトリのＵＲＬのリスト。
C.  mode−マルチファイルシステムのルートディレクトリに認可されるアクセス許可を指定する「保護モード」。保護モードは基本ファイルシステム（例えばＵＮＩＸ）にしたがって指定される。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  一連のＲＰＣを使用して、ユーザが、control及びdataによって指定されたディレクトリを作成できるかどうかを決定する。作成できない場合には（例えば、その名称のディレクトリが既に存在する場合）、オペレーションを中断する。
C.  （ＦＲ２のみ）以下の補助情報を記憶する：
1.  control
2.  Data
A.  オペレーションを実行する：
1.  Fileopを使用して、modeによって指定されたアクセス許可を持つディレクトリcontrolを作成する。
2.  Fileopを使用して、dataディレクトリ用のＵＲＬを含むコントロールファイル“control/.mdir”を作成する。
3.  一連のfileopを使用して、data内に各々のディレクトリを作成する。再び、modeによって指定された保護モードを使用する。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
リカバリ（ＦＲ２のみ）
A.  control/.mdirが存在する場合はこれを削除する。
B.  controlが存在する場合はこれを削除する。
C.  data内にディレクトリが存在する場合はこれら全てのディレクトリを削除する。
D.  記憶された補助情報を読出し、オペレーションを（上述の）段階Ｄから再開する。
(6)  マルチファイルシステムの除去
この機能はマルチファイルシステムを除去するものである。これには、好ましい実施例では、マルチファイルシステムが空である必要がある。
アーギュメント：
A.  target−マルチファイルシステムのルートのＵＲＬ。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくは、コントロールツリー２のルーフ上の独占ロックを使用して、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  万一
1.  userが削除許可を所有していない場合、
2.  targetがディレクトリでない場合、
3.  targetがマルチファイルシステムのルートでない場合、
1.  targetが、そのコントロールファイル(.mdir)以外の全てを含む場合、
にはオペレーションを中断する。
A.  (FR2のみ)補助情報を記憶する：
1.  target
2.  control
3.  Expansion
A.  オペレーションを実行する：
1.  一連のfileopを使って、expansion内のディレクトリを除去する。
2.  Fileopを使って、ファイルcontrol/.mdirを除去する。
3.  Fileopを使ってディレクトリcontrolを除去する。
A.  (ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
C.  ロックを解除する。
リカバリ（ＦＲ２のみ）
A.  記憶された補助情報を読出し、オペレーションを（上述の）段階Ｆから再開する。
(7)  マルチディレクトリの作成
このルーチンは、ＵＲＬによって指定されたマルチディレクトリを作成するものである。
アーギュメント：
A.  target−作成するディレクトリ/マルチディレクトリのＵＲＬ。
B.  mode−新規に作成されたディレクトリに承認されるアクセス許可を指定する。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくはコントロールツリー２のルート上の共用ロックを用いて、また、コントロール層２４ａを作成する場所のコントロールディレクトリ２４上の独占ロックを用いて、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  以下が該当する場合には中断する：
1.  categoryが“nothing”以外のものである場合（すなわち、userが既存のマルチファイル又はマルチディレクトリに上書きするように命令した）。
2.  userが“create”許可を所有していない場合（これは、targetの親ディレクトリが存在しないために起こる）。
A.  (FR2のみ)補助情報を記憶する：
1.  target
2.  mode
3.  control
4.  expansion
A.  オペレーションを実行する：
1.  一連のfileopを用いて、expansion内に指定された各々のディレクトリを作成する。各々のディレクトリは、modeによって指定されたアクセス許可を備えている。
2.  fileopを用いて、controlによって指定されたコントロールディレクトリを作成する。
3.  fileopを用いて、rootを含有するマルチディレクトリコントロールファイル"control/.mdir"を作成する。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
C.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  control/.mdirを削除する
B.  controlを削除する
C.  expansionの全要素を削除する
D.  記憶した補助情報を読出し、オペレーションを（上述の）段階Fから再開する。
(8)マルチディレクトリの除去
このルーチンは、ＵＲＬによって指定されたマルチディレクトリを削除するためのものである。好ましい実施例では、マルチディレクトリは空でなくてはならない。
アーギュメント：
A.  target−削除するディレクトリ/マルチディレクトリのＵＲＬ。
アルゴリズム
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくは共用ロックを用いて、また、コントロール層２４ａが位置する場所のコントロールディレクトリ２４上の独占ロックを用いて、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  以下にいずれかに該当する場合にはオペレーションを中断する。
1.  userがディレクトリtargetを削除する許可を所有していない場合。
2.  targetがディレクトリでない場合。
3.  コントロールディレクトリが.mdir以外を含んでいる場合(controlの内容を読出すためにＲＰＣを使用する)。
A.  （ＦＲ２のみ）補助情報を記憶
1.  target
2.  control
3.  expansion
A.  オペレーションを実行する：
1.  fileopを用いてマルチディレクトリコントロールファイル(control/.MDIR)を削除する。
2.  fileopを用いてコントロールディレクトリ(control)を削除する。
3.  expansion内の全てのＵＲＬにかけてロープし、fileopを介してこれらを削除する。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
C.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  記憶した補助情報を読出し、（上述の）Ｆ段階から実行を再開する。
(9)  マルチファイルの作成
ＵＲＬによって指定されたマルチファイルを作成する。指定されたマルチファイルは既に存在するものであってはならない。
A.  target−作成するファイル/マルチファイルのＵＲＬ。
B.  mode−新規に作成されたファイルに承認されるアクセス許可を指定する。
アルゴリズム
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくはコントロールツリー２のルート上の共用ロックを用いて、また、コントロールファイル２１を作成する場所のコントロールディレクトリ２４上の独占ロックを用いて、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  以下のいずれかに該当する場合にはオペレーションを中断する：
1.  ファイルが存在する。
2.  userがファイル作成許可を所有していない（これは、targetの親ディレクトリが存在しないために起こる）。
A.  補助情報を記憶する：
1.  target
2.  mode
3.  control
4.  expansion
A.  オペレーションの実行：
1.  fileopを使用して、controlによって指定された、rootを含むコントロールファイルを作成する。
2.  一連のfileopを使用して、expansionによって指定された、modeによって指定されたアクセス許可を持つ各々のファイルを作成する。dataファイルは空である。
A.  (FR1のみ)オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  (FR2のみ)オペレーションの全段階が成功したら、補助情報を消去する。
C.  ロックを解除する。
(FR2のみ)リカバリ：
A.  controlを削除する。
B.  expansion内の全てのファイルを削除する。
C.  記憶した補助情報を読出し、（上述の）段階Ｆからオペレーションを再開する。
(9)  マルチファイルにリンクを作成する
このルーチンはマルチファイルにリンクを作成するものである（１つのファイルに複数のリンクを許容するＵＮＩＸのようなファイルシステムのみに適用可能である。）。リンクは全ての層に作成される（control及びdata）。
アーギュメント：
A.  target−リンクされるファイル。
B.  link−作成するリンクのＵＲＬ。
リンク作成オペレーションは、好ましい実施例において多くの規制がある：
A.  target及びlinkは両方共同じマルチファイルシステムの１部でなければならない。
B.  targetはディレクトリでなくてはならない。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくはコントロールツリー２のルート上の共用ロックを用いて、また、コントロールファイル２１を作成する場所のコントロールディレクトリ２４上の独占ロックを用いて、マルチファイルシステムをロックする。
C.  target（t_permission, t_category, t_root, t_control, t_expansion)用の、また、link（1_permission, l_category, l_root, l_control, l_expansion）用のコントロール情報を入手する。
D.  以下のいずれかに該当する場合、オペレーションを中断する：
1.  userがtarget用の「調査」許可を所有していない場合。
2.  userがlink用の「作成」許可を所有していない場合。
3.  既にlinkが存在する場合。
4.  targetが存在しない場合。
5.  targetがディレクトリである場合。
6.  T_rootとl_rootが異なる場合。
A.  補助情報を記憶する：
1.  target
2.  link
3.  t_control
4.  l_control
5.  l_expansion
A.  オペレーションを実行する：
1.  fileopを使って、t_controlに関連するリンクl_controlを作成する。
2.  t_expansionの要素に関連したl_expansionの各要素にリンクを作成するために、fileopを使ってl_expansionとt_expansionの要素をループする。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
C.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  l_controlを削除する。
B.  l_expansion内の全てのリンクを削除する。
C.  記憶した補助情報を読出し、（上述した）段階Ｆからオペレーションを再開する。
(9)  マルチファイルのアンリンク
このルーチンは、ＵＲＬによって指定されたマルチファイルを「アンリンク」するものである。内在するファイルシステムが１つのファイル（例えばＵＮＩＸ）に複数の「リンク」を許容する場合、これは実際にはファイルを削除したことにはならない。（少なくとも１つのリンクが存在する限り、そのファイルは存在する）。
アーギュメント：
A.  target−削除するリンクのＵＲＬ。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくはコントロールツリー２のルート上の共用ロックを用いて、また、コントロールファイル２１が位置する場所のコントロールディレクトリ２４上の独占ロックを用いて、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  以下のいずれかに該当する場合には、オペレーションを中断する：
1.  userが削除許可を所有していない場合。
2.  targetによって指定されたファイルが存在しない場合。
A.  （ＦＲ２のみ）補助情報を記憶する：
1.  target
2.  control
3.  expansion
A.  オペレーションを実行する：
1.  fileopを使用して、expansionによって指定されたファイルの各々を削除する。
2.  fileopを使用してcontrolを削除する。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を削除する。
C.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  補助情報を読出し、（上述の）段階Ｆからオペレーションを再開する。
(9)  ファイル/ディレクトリの属性の変更
実際にはこれは、例えば保護モードのオーナーのような、マルチファイル/マルチディレクトリの属性を変更するためのルーチンのファミリーである。属性の変更を実際に実行するためには、各属性は各々異なる方法を必要とする。１つのルーチンが複数の属性を変更する場合もある。例えば、ＵＮＩＸは、１つのファイルの‘owner’及び‘group’属性の両方を変更するルーチンを含んでいる。
アーギュメント：
A.  target−操作するマルチファイル/マルチディレクトリ２１、２４ａのＵＲＬである。
B.  attribute−変更する属性（単数又は複数）のための識別子である。
C.  value−属性（単数又は複数）のための新規値（単数又は複数）である。
アルゴリズム：
A.  (FR1のみ)トランザクションを開始する。
B.  好ましくは、コントロールツリー２のルート上の共用ロックを使用して、又は、コントロールファイル２１/コントロールディレクトリ２４ａが位置する場所のコントロールディレクトリ２４上の独占ロックを使用して、マルチファイルシステムをロックする。
C.  target用のコントロール情報を入手する。
D.  以下の場合にはオペレーションを中断する。
1.  targetによって指定されたファイル/ディレクトリが存在しない場合。
2.  userがattribute変更の許可を所有していない場合。これは、変更する属性による。例えば：
a.  保護モード：ユーザは特権を有するか、又はファイルを所有していなければならない。
b.  オーナーID：ユーザは特権を有していなければならない。
c.  グループID：ユーザは特権を有するか、又はファイルを所有し、表示されたグループのメンバーでなければならない。
A.  （ＦＲ２のみ）補助情報を記憶する：
1.  target
2.  attribute
3.  value
4.  control
5.  expansion
A.  fileopを使用して、表示されたcontrolのattributeと、expansionからvalueまでの各要素のattributeを変更する。
B.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
C.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
D.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  補助情報を読出し、（上述の）段階Ｆからオペレーションを再開する。
(9)  状態情報の入手
このルーチンにより、マルチファイル/マルチディレクトリのための状態情報を入手することができる。このような情報には、様々な属性（例えば、オーナー、アクセス許可）のための値と、そのファイル自体に関するその他の情報、例えばバイトで表したファイルの長さ、が含まれる。
マルチファイル/マルチディレクトリに関すると、好ましい実施例では状態情報には３つのクラスがある。
A.  コントロールファイル/ディレクトリから引継いだ属性。例えば「アイノード数」。
B.  データファイル/ディレクトリから引継がれ、全てのファイル/ディレクトリにかけて一定でなければならない属性。例えば「ブロックサイズ」。
C.  最大値を見つけることにより、コントロール及びデータファイル/ディレクトリにかけて集合した、また、全てのファイル/ディレクトリにかけて一定でなければならない属性。例えば「最も最近のアクセス時間」。
D.  合計を見つけることにより、データファイル/ディレクトリにかけて集合した属性。例えばバイトで示すサイズ。
アーギュメント：
A.  target−状態情報を所望するマルチファイル/マルチディレクトリの名称。
アルゴリズム：
注意：システム内では何も変更されないため、トランザクションの開始/コミット、補助情報の記憶/消去/回復を行う必要はない。
A.  コントロールツリー２のルート上の共用ロックを使って、又は、コントロールファイル２１/コントロールディレクトリ２４ａが位置する場所のディレクトリ上の共用ロックを使ってマルチファイルシステムをロックする。
B.  targetのためのコントロール情報を入手する。
C.  fileopを使って、expansion及びcontrol内の全てのＵＲＬについて状態情報を入手する。
D.  上述で入手した状態オブジェクトを集合することにより、状態オブジェクトを作成する。ＵＮＩＸでは以下のように行われる。
1.  装置ID。これは、ファイル/ディレクトリを記憶するために使用する物理的記憶装置のための識別子である。コントロールファイル/ディレクトリから引継がれる。
2.  アイノード数。これは、ＵＮＩＸファイルシステム内で固有のファイル/ディレクトリのための内部識別子である。コントロールファイル/ディレクトリから引継がれる。
3.  ファイルモード。これはアクセスコントロール情報を含み、また、何かがファイルであるか、ディレクトリであるか、その他の何かであるかを示す。これらは、全てのコントロール及びデータファイル/ディレクトリにかけて一定でなければならない。
4.  リンク数。これは、ファイル/ディレクトリへのハードリンクの数である。コントロールファイル/ディレクトリから引継がれる。
5.  UID、GID。これらは、ファイル/ディレクトリの「ユーザID」から「グループID」の数値識別子であり、アクセスコントロールの目的で使用される。コントロールファイル/ディレクトリから引継がれる。
6.  rdev。記憶装置のタイプのコード。コントロールファイル/ディレクトリから引継がれる。
7.  バイトで表すサイズ。オブジェクトの総合バイト数を表す整数である。ディレクトリについては、コントロールディレクイトリから引継がれ、ファイルについては、全データファイルにかけてのサイズの合計である。
8.  ブロックサイズ。ファイルシステムによって使用される「ブロックサイズ」を表す整数である。これは、全てのデータファイル内で一定でなければならず、また、データファイルから引継がれる。
9.  ブロック数。１つのファイルに使用されるブロックの総数を表す整数である。ディレクトリについては、コントロールディレクトリから引継がれる。データファイルについては、これは全データファイルにかけてのブロック数の合計である。
10.  アクセス時間、変更時間、チェンジ時間。これらは、ファイル/ディレクトリに関連して、ある動作が起きた時間を示すタイムスタンプである。これらは全ファイル/ディレクトリにかけて最大に計算される。
A.  コントロール及びデータファイル/ディレクトリの個々の状態オブジェクトが、配列として戻される。
B.  ロックを解除する。
(9)  マルチファイル/ディレクトリの名称変更
これは、マルチファイル/マルチディレクトリの名称を変更するものである。新旧両方の名称が同じマルチファイルシステムの１部でなければならない。
アーギュメント：
A.  old_path−マルチファイル/マルチディレクトリの現在の名称を表すURLである。
B.  new_path−マルチファイル/マルチディレクトリの新しい名称を表すURLである。
アルゴリズム：
A.  （ＦＲ１のみ）トランザクションを開始する。
B.  好ましくはマルチファイルシステムのルートにおける独占ロックを用いて、マルチファイルシステムをロックする。
C.  old_path (old_permission, old_category, old_root, old_control, old_expansion)のための、また、new_path(new_permission, new_category, new_root, new_control, new_expansion)のためのコントロール情報を入手する。
D.  以下のいずれかに該当する場合には、オペレーションを中断する。
1.  new_rootとold_rootが異なる場合。
2.  old_categoryが“none”である場合。
3.  old_categoryが“file”であり、new_categoryが“directory”である場合。
4.  old_categoryが“directory”であり、new_categoryが“file”である場合。
5.  new_categoryが“directory”であり、new_controlが“.mdir”以外のものを含んでいる場合。
A.  （ＦＲ２のみ）補助情報を記憶する：
1.  new_control
2.  old_control
3.  new_expansion
4.  old_expansion
5.  old_category
6.  new_category
A.  オペレーションを実行する：
1.  new_categoryが“directory”である場合、fileopを使用して、new_control/.mdir（リカバリ処理においてold_controlが存在しない場合は、この段階を省略する。）
2.  fileopを使用して、old_controlからnew_controlに名称を変更する。
3.  fileopを使用して、old_expansionの各要素をnew_expansionに変更する。
A.  （ＦＲ１のみ）オペレーションの全段階が成功したら、トランザクションをコミットする；又はロールバックする。
B.  （ＦＲ２のみ）オペレーションの全段階が成功したら、補助情報を消去する。
C.  ロックを解除する。
（ＦＲ２のみ）リカバリ：
A.  記憶した補助情報を読出し、（上述の）段階Ｆからオペレーションを再開する。
(9)  追加ファイルオペレーション
上述のルーチンは最も重要なファイルシステムオペレーションの実現を説明している。追加のファイルオペレーションも類似の方法で実現することができる。
(10)  ネイティブファイルシステムオペレーションとの互換性の追加
ファイルシステムの作成及び除去するためのオペレーションを除き、上述したオペレーションの全ては、非マルチファイルを、単一データ層を備えた（コントロール層は持たない）マルチファイルであるかのように扱えるように容易に拡張することができる。一般に、以下のアプローチを適用することができる。
A.  ターゲットのＵＲＬを調べ、特定のフィールドのデフォルトを取る。
1.  あるタイプがない場合（例えば“//node2/foo”）、デフォルトとして“file”をとる。
2.  ホストがない場合（例えば“file:/foo”）、ローカルホストネーム（例えば“node2”）をデフォルトとしてとる。
3.  実際にURLが相対パスネーム（例えば“foo”）である場合、“file”のタイプ、“localhost”のホストを追加することによりＵＲＬを作成し、「現在動作中のディレクトリ」を追加することにより相対パスネームを絶対パスネームへ変換する。（例えば、現在のホストが“node2”であり、現在動作中のディレクトリが“/homedir”である場合は、“foo”は“file://node2/homedir/foo”となる。）
A.  デフォルトされたＵＲＬが“mfile”のタイプを有する場合には、上述した適切なマルチファイルオペレーションを呼出す（例えば、マルチディレクトリの作成、マルチファイルの作成、等）。
B.  デフォルトされたＵＲＬが“file”のタイプを有する場合には、fileopを使用して、ネイティブファイルシステムを使った適切なオペレーションを実行する（例えば、名称変更、アンリンク、等）。例外として、ネイティブファイルシステム内に複製がない“expand”オペレーションである。このオペレーションは、好ましい実施例において以下の通り扱われる。
1.  ユーザがデフォルトされたURLへの“probe”アクセスを所有しているかどうかを決定する。
2.  所有している場合には、その単独メンバとしてデフォルトされたURLを持った長さ１の配列を戻す。
本発明の展開
本発明はいくつかの方法で利用できる。
●  アプリケーションの１部として。第５図は、アプリケーションの１部として本発明が実施されるコンポーネント間の関係を示すブロック図である。マルチファイルサブルーチン４は、アプリケーションドライバ６の１部として含まれる。アプリケーションドライバ６とマルチファイルサブルーチン４は、ドライバ６に代わって分散プログラムインスタンス７を呼出し、マルチファイルソフトウェアに代わってfileopとＲＰＣ ８を呼出す単一分散計算環境５へのアクセスを共用する。
●  分散サービスとして。第６図は、本発明が分散サービスとして実施されるコンポーネント間の関係を示すブロック図である。コントロール及びデータツリー１、２を有するコンピュータの「オーナー」は、少なくとも１つの「マルチファイルサーバ」４が常時実行していることを確かめる必要がある。以下に説明するサブルーチンが、サービス４の１部としてはめ込まれ、これがさらに分散計算環境５に組込まれる。これらのサービスを使用したいアプリケーションは、マルチファイルオペレーションを実行するために分散計算環境５ａを介して適切なサービス４と接触する「スタブサブルーチン」９を含んでいる。分散計算環境５ａは、マルチファイルソフトウェアに代わってfileopとRPC 8を呼出す。マルチファイルシステムの採用に必要な作業を最小限にするために、これらのストランドタブサブルーチン９はネイティブファイルシステムインターフェースのインターフェースを模造することが好ましい。従来のアプリケーションドライバとプログラム段階７の間の通信は、第２分散計算環境５ｂによって管理される。また、ドライバとプログラム段階の間の通信は、マルチファイルサーバが使用するものと同一の分散計算環境によって管理されてもよい。
●  オペレーティングシステムの１部として。第６図は、本発明がオペレーティングシステムの１部として実行されるコンポーネント間の関係を示すブロック図である。一般に、オペレーティングシステムのファイルシステムインターフェースは、マルチファイルコマンドを認識し、「ファイルシステムドライバ」インターフェース１１を介してこれらをマルチファイルサーバ４へとディスパッチするように拡張することができる。多くのオペレーティングシステム（例えば、Microsoft社のWindows NTオペレーティングシステム）は、この種の統合を利用するインターフェースを提供する。一旦マルチファイルサーバ４が係合すると、その実行は分散サービスの場合と非常に類似する。
プログラムの実行
本発明は、ハードウェア又はソフトウェアにおいて、又は両方の組合せにおいて実現することができる。しかし、本発明は、プログラム可能コンピュータ上で実行しているコンピュータプログラムにおいて実現することが好ましい。このプログラム可能コンピュータは、少なくとも１つのプロセッサ、データ記憶システム（揮発性と不揮発性メモリ及び/又は記憶要素）、少なくとも１つの入力装置、少なくとも１つの出力装置を備えている。本明細書中で述べている機能を実行するため、また、出力情報を生成するために、プログラムコードが入力データに適用される。出力情報は１つ又はそれ以上の出力装置に、従来の方法で適用される。
各プログラムは、コンピュータシステムと通信するために、高レベル手続き上の、又はオブジェクト指向のプログラミング言語において実行されることが好ましい。しかし、所望であれば、プログラムをアセンブラ言語又は機械言語において実現することも可能である。いずれの場合も、言語はコンパイル又は翻訳された言語であってよい。
ここで述べている手続きを実行するべくコンピュータが記憶媒体又は装置を読出す際にコンピュータを構成及び操作するために、このようなコンピュータプログラムの各々が、一般又は特別の目的のプログラム可能コンピュータによって読出し可能な記憶媒体又は装置（例えば、ROM又は磁気ディスケット）に記憶されることが好ましい。本発明のシステムはまた、コンピュータプログラムと共に構成されたコンピュータ読出し可能記憶媒体として実現するものと考えることもできる。ここでは、記憶媒体は、コンピュータに、特定の、また予め画定された方法において、ここで述べた機能を実行させるように構成されている。
本発明の多くの実施例について説明した。しかし、本発明の精神と範囲を逸脱しない限り、様々な変更を加えることができることが理解できるであろう。したがって、本発明は特定の例証的実施例によって限定されるのではなく、付属の請求の範囲によってのみ限定されるものであることを理解すべきである。
【図１】
0003754459.tif 000002
【図２】
0003754459.tif 000003
【図３】
0003754459.tif 000004
【図４】
0003754459.tif 000005
【図５】
0003754459.tif 000006
【図６】
0003754459.tif 000007
【図７】
0003754459.tif 000008