JP3754459B2 - 並列仮想ファイルシステム - Google Patents
並列仮想ファイルシステム Download PDFInfo
- Publication number
- JP3754459B2 JP3754459B2 JP50468599A JP50468599A JP3754459B2 JP 3754459 B2 JP3754459 B2 JP 3754459B2 JP 50468599 A JP50468599 A JP 50468599A JP 50468599 A JP50468599 A JP 50468599A JP 3754459 B2 JP3754459 B2 JP 3754459B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- data
- directory
- native
- control
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000012545 processing Methods 0.000 claims description 60
- 238000000034 method Methods 0.000 claims description 36
- 230000008859 change Effects 0.000 claims description 13
- 238000005192 partition Methods 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 claims description 3
- 238000000638 solvent extraction Methods 0.000 claims description 3
- 238000011084 recovery Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 12
- 238000007726 management method Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000006378 damage Effects 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 239000000523 sample Substances 0.000 description 3
- 230000010354 integration Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003278 mimic effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000004366 reverse phase liquid chromatography Methods 0.000 description 2
- 241000182341 Cubitermes group Species 0.000 description 1
- 208000027418 Wounds and injury Diseases 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 210000001357 hemopoietic progenitor cell Anatomy 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 208000014674 injury Diseases 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000001167 microscope projection photolithography Methods 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1858—Parallel file systems, i.e. file systems supporting multiple processors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
- G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
- G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
１． 発明の分野
本発明は、コンピュータ処理システムに関するものであり、特に、複数記憶装置を備えた単一プロセッサシステムを装備した並列処理システム用の並列仮想ファイルシステムに関するものである。
２． 関連技術の説明
単一プロセッサコンピュータの計算速度は、過去３０年間の間に凄まじい進歩を遂げた。しかし、多くの分野では、最速の単一プロセッサコンピュータさえも超える速度の計算能力が要求されている。この１例は、トランザクション処理である。トランザクション処理は、複数のユーザがコンピュータ資源に同時にアクセスし、また、商用的に許容可能なシステムとしては応答時間が短くなければならない。別の例は、データベースマイニングである。ここでは、数百ギガバイトの情報を処理しなければならず、シリアルコンピュータ上のデータ処理が数日又は数週間かかってしまう。そのため、このような問題を扱う様々な「並列処理」システムが開発された。説明の目的で、並列処理システムには、ローカルの（例えば、ＳＭＰコンピュータのようなマルチプロセッサシステム）、又はローカル的に分散した（例えば、クラスタ又はＭＰＰのような複数プロセッサシステム）、又は遠隔の、或いは遠隔的に分散した（例えば、ＬＡＮ又はＷＡＮネットワークを介して結合した複数のプロセッサ）、又はこれらのあらゆる組合せである複数の中央処理ユニット（ＣＰＵ）を利用したコンピュータのあらゆる構成が含まれる。さらに、本発明の内容において、複数の記憶装置を備えた並列処理システムは単一プロセッサシステムを含んでいる。
以下の手段により並列処理システムのハイパフォーマンスを達成することは慣用手段である。
● コンピュータがアクセスするデータセットが、いくつかのばらばらな記録のセットに分割（「区分」）され、記憶装置のコレクション上に記憶される。この方法で分割されたデータセットは、「区分編成ファイル」と呼ばれ、各サブ分割は「区分」と呼ばれる。
● アプリケーションを備え、データを処理するプログラムのいくつかのインスタンスは、プロセッサのコレクション上で実行されるか、又は１つのプロセッサ上で独立したタスクとして実行される。
●各プログラムインスタンスは、処理中の各区分編成ファイルの１つの区分にアクセスする。
この実行の利点は、複数の記憶装置を同時に使用できることにより、高い総合データ転送レートが得られ、また、複数のプロセッサを同時に使用できることにより、高い総合処理レートを得ることができることである。
このようなアプリケーションの開発者は、次に区分編成ファイルの管理及び使用の問題に直面する。その問題の内、直視すべきものは以下の通りである。
● 各区分編成ファイルは、作成され、最終的には削除されなければならない。
● 各区分編成ファイルは、アプリケーションによってアクセスされなければならない。
● 区分編成ファイルは、例えばファイルシステム内に組織されなければならない。
● 区分編成ファイルは、例えば損傷した際には修理するというように管理されなければならない。
これらの問題を解決するための従来技術における１つの方法は、以下の構成における特別なバリアントを用意することである。
● システム内の各プロセッサが独自の記憶装置のセットを備える。
● 各記憶装置が、「同型」ファイルシステムすなわちファイルとディレクトリの同一配列を備え、ファイルの内容のみがシステム毎に異なるファイルシステムと共にセットアップされている。
● アプリケーションが区分編成ファイルにおける何らかの変更を行いたい場合（例えば、ファイル作成）、アプリケーションはシステム内の全てのプロセッサのプログラムインスタンスを呼出す。各プログラムには同じパラメータ（例えばファイル名）が与えられている。
● プログラムの各インスタンスが、ファイルシステムへの構造変更の観点から見て同一に動作することが必要である。例えば、あるプログラムインスタンスがファイルを作成すると、全てのプログラムインスタンスが同じファイルを作成しなければならない（すなわち、同じ名称を持つが、異なるファイルシステム内にあるファイル）。
これらの原理を固守する限り、ファイルシステムは同型である。
この従来技術アプローチはいくつかの有益な特徴を持つ。
● プログラムが区分内でデータにアクセスする際、標準のファイルシステムインターフェースを使用することができる。
● 全てのファイルシステムが同型構造を有するため、単一ファイルシステム並みの管理で済む。これは、ファイルシステム管理が、主にシステム内のディレクトリとファイルの確立、監視、構造の変更の問題であるためである。同型ファイルシステムのコレクションの構造が単一ファイルシステムのものと同じ位に単純であるので、同型ファイルシステムの管理は、一般的に単一ファイルシステムのものと同じ位に単純である。
しかし、このアプローチにはいくつかの問題が伴う。
● このような方策を使用したい全てのアプリケーションは、このアプローチの「手仕事による」実行を含まなければならない。
● ユーザ又はアプリケーションが上述した従来技術からそれた場合には、様々なファイルシステムは徐々に異なる構造を入手する。現在では、管理者は様々な構成ファイルシステムに見られる異なる構造を理解及び管理する必要があるため、一旦同型性が失われると、システム管理がより複雑になってしまう。
● 不注意な時間にシステムがクラッシュした場合、ファイルシステムのみに特定の構造変更が行われた可能性がある。同型性を復旧するために、管理者は各ファイルシステム内を、不一致を探して調査し、意図したファイルシステム構造についての管理者の最上の理解に従って修理する必要がある。さらに、同型性が厳密に強制されていない場合、管理者はどの同型性からの逸脱が意図されたものであり、どれが人為的なものであるかを知る手立てがなくなってしまう。
● ２つのアプリケーションが同時に「同型」ファイルシステムにアクセスする場合、互いに干渉し合う可能性がある。例えば、アプリケーションプログラムＡがファイルの名称変更を行い、アプリケーションプログラムＢがその同じファイルを削除しようとしたとすると、あるプロセッサではアプリケーションプログラＡが最初に実行されるが（ファイルの名称が変更される）、別のプロセッサではアプリケーションプログラムＢが最初に実行される（ファイルが削除される）。これにより同型性が喪失し、重大な管理問題を引起こしてしまう（恐らく、２つのアプリケーションは同時には実行されていないが、このようなエラーは一般的であり、このような一般的なエラーにとって同型性の喪失は許容できないものである）。
従って、並列処理システムにおける区分編成ファイルの管理方法が必要である。本発明はこのような方法を提供するものである。
発明の概要
本発明は、区分編成ファイルを管理するための並列仮想ファイルシステムであり、その幅広い概要は以下の通りである。
● 区分編成ファイルのパーティションは、１セットの同型の「データツリー」内に記憶される。
● 意図する構成のデータツリーのモデルを構築するために、「コントロールツリー」と呼ばれる追加のディレクトリツリーが使用される。コントロールツリーは、コンピュータシステムがデータツリー内でデータを「探す」（そのパス名を生成する）ことを許容する。
● コントロールツリーとデータツリーのコレクションとの組合せは、「マルチファイルシステム」と呼ばれる。マルチファイルシステム内のファイルは、「マルチファイル」と呼ばれる。マルチファイルシステム内のディレクトリは「マルチディレクトリ」と呼ばれる。マルチファイル又はマルチディレクトリのデータ要素は「データ層」と呼ばれる。マルチファイル又はマルチディレクトリの制御要素は「コントロール層」と呼ばれる。
● 例えば、データツリーの構造を変更する場合又はマルチファイル又はマルチディレクトリのデータ層用の識別子を入手するといったように、マルチファイルシステムへのアクセス、又はこれを変更するために、１セットのマルチファイルサブルーチンが供給される。実用的には、マルチファイルサブルーチンはネイティブファイルシステムのインターフェース模造を備えている。
● マルチファイルシステムのへの構造変更の原子性を確実にするために、遠隔手続きコール（ＲＰＣ）を供給し、また、本発明の実施例の１つにおいては分散トランザクション処理プロトコル（例えば、２位相コミット）を供給するマルチファイルサブルーチンが、分散計算環境を使用する。分散計算環境はまた、「分散ファイルオペレーション」（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又は磁気ディスケット）に記憶されることが好ましい。本発明のシステムはまた、コンピュータプログラムと共に構成されたコンピュータ読出し可能記憶媒体として実現するものと考えることもできる。ここでは、記憶媒体は、コンピュータに、特定の、また予め画定された方法において、ここで述べた機能を実行させるように構成されている。
本発明の多くの実施例について説明した。しかし、本発明の精神と範囲を逸脱しない限り、様々な変更を加えることができることが理解できるであろう。したがって、本発明は特定の例証的実施例によって限定されるのではなく、付属の請求の範囲によってのみ限定されるものであることを理解すべきである。
本発明は、コンピュータ処理システムに関するものであり、特に、複数記憶装置を備えた単一プロセッサシステムを装備した並列処理システム用の並列仮想ファイルシステムに関するものである。
２． 関連技術の説明
単一プロセッサコンピュータの計算速度は、過去３０年間の間に凄まじい進歩を遂げた。しかし、多くの分野では、最速の単一プロセッサコンピュータさえも超える速度の計算能力が要求されている。この１例は、トランザクション処理である。トランザクション処理は、複数のユーザがコンピュータ資源に同時にアクセスし、また、商用的に許容可能なシステムとしては応答時間が短くなければならない。別の例は、データベースマイニングである。ここでは、数百ギガバイトの情報を処理しなければならず、シリアルコンピュータ上のデータ処理が数日又は数週間かかってしまう。そのため、このような問題を扱う様々な「並列処理」システムが開発された。説明の目的で、並列処理システムには、ローカルの（例えば、ＳＭＰコンピュータのようなマルチプロセッサシステム）、又はローカル的に分散した（例えば、クラスタ又はＭＰＰのような複数プロセッサシステム）、又は遠隔の、或いは遠隔的に分散した（例えば、ＬＡＮ又はＷＡＮネットワークを介して結合した複数のプロセッサ）、又はこれらのあらゆる組合せである複数の中央処理ユニット（ＣＰＵ）を利用したコンピュータのあらゆる構成が含まれる。さらに、本発明の内容において、複数の記憶装置を備えた並列処理システムは単一プロセッサシステムを含んでいる。
以下の手段により並列処理システムのハイパフォーマンスを達成することは慣用手段である。
● コンピュータがアクセスするデータセットが、いくつかのばらばらな記録のセットに分割（「区分」）され、記憶装置のコレクション上に記憶される。この方法で分割されたデータセットは、「区分編成ファイル」と呼ばれ、各サブ分割は「区分」と呼ばれる。
● アプリケーションを備え、データを処理するプログラムのいくつかのインスタンスは、プロセッサのコレクション上で実行されるか、又は１つのプロセッサ上で独立したタスクとして実行される。
●各プログラムインスタンスは、処理中の各区分編成ファイルの１つの区分にアクセスする。
この実行の利点は、複数の記憶装置を同時に使用できることにより、高い総合データ転送レートが得られ、また、複数のプロセッサを同時に使用できることにより、高い総合処理レートを得ることができることである。
このようなアプリケーションの開発者は、次に区分編成ファイルの管理及び使用の問題に直面する。その問題の内、直視すべきものは以下の通りである。
● 各区分編成ファイルは、作成され、最終的には削除されなければならない。
● 各区分編成ファイルは、アプリケーションによってアクセスされなければならない。
● 区分編成ファイルは、例えばファイルシステム内に組織されなければならない。
● 区分編成ファイルは、例えば損傷した際には修理するというように管理されなければならない。
これらの問題を解決するための従来技術における１つの方法は、以下の構成における特別なバリアントを用意することである。
● システム内の各プロセッサが独自の記憶装置のセットを備える。
● 各記憶装置が、「同型」ファイルシステムすなわちファイルとディレクトリの同一配列を備え、ファイルの内容のみがシステム毎に異なるファイルシステムと共にセットアップされている。
● アプリケーションが区分編成ファイルにおける何らかの変更を行いたい場合（例えば、ファイル作成）、アプリケーションはシステム内の全てのプロセッサのプログラムインスタンスを呼出す。各プログラムには同じパラメータ（例えばファイル名）が与えられている。
● プログラムの各インスタンスが、ファイルシステムへの構造変更の観点から見て同一に動作することが必要である。例えば、あるプログラムインスタンスがファイルを作成すると、全てのプログラムインスタンスが同じファイルを作成しなければならない（すなわち、同じ名称を持つが、異なるファイルシステム内にあるファイル）。
これらの原理を固守する限り、ファイルシステムは同型である。
この従来技術アプローチはいくつかの有益な特徴を持つ。
● プログラムが区分内でデータにアクセスする際、標準のファイルシステムインターフェースを使用することができる。
● 全てのファイルシステムが同型構造を有するため、単一ファイルシステム並みの管理で済む。これは、ファイルシステム管理が、主にシステム内のディレクトリとファイルの確立、監視、構造の変更の問題であるためである。同型ファイルシステムのコレクションの構造が単一ファイルシステムのものと同じ位に単純であるので、同型ファイルシステムの管理は、一般的に単一ファイルシステムのものと同じ位に単純である。
しかし、このアプローチにはいくつかの問題が伴う。
● このような方策を使用したい全てのアプリケーションは、このアプローチの「手仕事による」実行を含まなければならない。
● ユーザ又はアプリケーションが上述した従来技術からそれた場合には、様々なファイルシステムは徐々に異なる構造を入手する。現在では、管理者は様々な構成ファイルシステムに見られる異なる構造を理解及び管理する必要があるため、一旦同型性が失われると、システム管理がより複雑になってしまう。
● 不注意な時間にシステムがクラッシュした場合、ファイルシステムのみに特定の構造変更が行われた可能性がある。同型性を復旧するために、管理者は各ファイルシステム内を、不一致を探して調査し、意図したファイルシステム構造についての管理者の最上の理解に従って修理する必要がある。さらに、同型性が厳密に強制されていない場合、管理者はどの同型性からの逸脱が意図されたものであり、どれが人為的なものであるかを知る手立てがなくなってしまう。
● ２つのアプリケーションが同時に「同型」ファイルシステムにアクセスする場合、互いに干渉し合う可能性がある。例えば、アプリケーションプログラムＡがファイルの名称変更を行い、アプリケーションプログラムＢがその同じファイルを削除しようとしたとすると、あるプロセッサではアプリケーションプログラＡが最初に実行されるが（ファイルの名称が変更される）、別のプロセッサではアプリケーションプログラムＢが最初に実行される（ファイルが削除される）。これにより同型性が喪失し、重大な管理問題を引起こしてしまう（恐らく、２つのアプリケーションは同時には実行されていないが、このようなエラーは一般的であり、このような一般的なエラーにとって同型性の喪失は許容できないものである）。
従って、並列処理システムにおける区分編成ファイルの管理方法が必要である。本発明はこのような方法を提供するものである。
発明の概要
本発明は、区分編成ファイルを管理するための並列仮想ファイルシステムであり、その幅広い概要は以下の通りである。
● 区分編成ファイルのパーティションは、１セットの同型の「データツリー」内に記憶される。
● 意図する構成のデータツリーのモデルを構築するために、「コントロールツリー」と呼ばれる追加のディレクトリツリーが使用される。コントロールツリーは、コンピュータシステムがデータツリー内でデータを「探す」（そのパス名を生成する）ことを許容する。
● コントロールツリーとデータツリーのコレクションとの組合せは、「マルチファイルシステム」と呼ばれる。マルチファイルシステム内のファイルは、「マルチファイル」と呼ばれる。マルチファイルシステム内のディレクトリは「マルチディレクトリ」と呼ばれる。マルチファイル又はマルチディレクトリのデータ要素は「データ層」と呼ばれる。マルチファイル又はマルチディレクトリの制御要素は「コントロール層」と呼ばれる。
● 例えば、データツリーの構造を変更する場合又はマルチファイル又はマルチディレクトリのデータ層用の識別子を入手するといったように、マルチファイルシステムへのアクセス、又はこれを変更するために、１セットのマルチファイルサブルーチンが供給される。実用的には、マルチファイルサブルーチンはネイティブファイルシステムのインターフェース模造を備えている。
● マルチファイルシステムのへの構造変更の原子性を確実にするために、遠隔手続きコール（ＲＰＣ）を供給し、また、本発明の実施例の１つにおいては分散トランザクション処理プロトコル（例えば、２位相コミット）を供給するマルチファイルサブルーチンが、分散計算環境を使用する。分散計算環境はまた、「分散ファイルオペレーション」（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又は磁気ディスケット）に記憶されることが好ましい。本発明のシステムはまた、コンピュータプログラムと共に構成されたコンピュータ読出し可能記憶媒体として実現するものと考えることもできる。ここでは、記憶媒体は、コンピュータに、特定の、また予め画定された方法において、ここで述べた機能を実行させるように構成されている。
本発明の多くの実施例について説明した。しかし、本発明の精神と範囲を逸脱しない限り、様々な変更を加えることができることが理解できるであろう。したがって、本発明は特定の例証的実施例によって限定されるのではなく、付属の請求の範囲によってのみ限定されるものであることを理解すべきである。
Claims (20)
- 並列処理システム用の並列仮想ファイルシステムを作成及び使用する方法であって、
ａ． 前記並列処理システムにおいて処理されるデータファイルを区分する段階と、
ｂ． 前記区分を、データファイルとディレクトリを有する１セットの同型データツリーとして前記並列処理システムの記憶装置に記憶する段階を有し、
ｃ． 前記データファイルのファイル構造のモデルを記憶するために、前記並列処理システムの記憶装置上にコントロールツリーを供給する段階を有し、前記コントロールツリーとデータツリーのセットの組合せが、マルチファイルを画定する前記マルチファイルシステム内の同型データファイルのセットと、マルチディレクトリを画定する前記マルチファイルシステム内の同型ディレクトリのセットと共に、前記マルチファイルシステムを画定し、
ｄ． 前記マルチファイルシステムにアクセスする又はこれを変更するための１セットのマルチファイルサブルーチンを供給する段階を有し、前記マルチファイルサブルーチンが、
(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に記載の装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/876,734 | 1997-06-16 | ||
| US08/876,734 US5897638A (en) | 1997-06-16 | 1997-06-16 | Parallel virtual file system |
| PCT/US1998/012522 WO1998058331A1 (en) | 1997-06-16 | 1998-06-16 | A parallel virtual file system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000513857A JP2000513857A (ja) | 2000-10-17 |
| JP3754459B2 true JP3754459B2 (ja) | 2006-03-15 |
Family
ID=25368457
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP50468599A Expired - Lifetime JP3754459B2 (ja) | 1997-06-16 | 1998-06-16 | 並列仮想ファイルシステム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5897638A (ja) |
| EP (1) | EP0996900A4 (ja) |
| JP (1) | JP3754459B2 (ja) |
| AU (1) | AU7970798A (ja) |
| CA (1) | CA2294397C (ja) |
| WO (1) | WO1998058331A1 (ja) |
Families Citing this family (122)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5909681A (en) | 1996-03-25 | 1999-06-01 | Torrent Systems, Inc. | Computer system and computerized method for partitioning data for parallel processing |
| EP1010076A1 (en) | 1996-11-27 | 2000-06-21 | 1Vision Software, L.L.C. | File directory and file navigation system |
| US6105026A (en) | 1997-07-03 | 2000-08-15 | Oracle Corporation | Multi-phase locking for partition maintenance operations |
| US5895471A (en) * | 1997-07-11 | 1999-04-20 | Unwired Planet, Inc. | Providing a directory of frequently used hyperlinks on a remote server |
| US20040107208A1 (en) * | 1997-12-09 | 2004-06-03 | Seet Siew Shon | Method and apparatus for bookmarking telephone numbers for efficient access by wireless phone devices |
| AU3304699A (en) * | 1998-02-20 | 1999-09-06 | Storm Systems Llc | File system performance enhancement |
| US6366910B1 (en) | 1998-12-07 | 2002-04-02 | Amazon.Com, Inc. | Method and system for generation of hierarchical search results |
| US6922708B1 (en) * | 1999-02-18 | 2005-07-26 | Oracle International Corporation | File system that supports transactions |
| US7620620B1 (en) * | 1999-08-05 | 2009-11-17 | Oracle International Corporation | Basing directory contents on a query that is associated with a file identifier |
| US6795833B1 (en) * | 1999-09-22 | 2004-09-21 | Alsoft, Inc. | Method for allowing verification of alterations to the cataloging structure on a computer storage device |
| AU2336901A (en) * | 1999-12-27 | 2001-07-09 | Texar Software Corp. | Virtual resource attribute directory |
| US6856993B1 (en) * | 2000-03-30 | 2005-02-15 | Microsoft Corporation | Transactional file system |
| US7657887B2 (en) * | 2000-05-17 | 2010-02-02 | Interwoven, Inc. | System for transactionally deploying content across multiple machines |
| CA2413434A1 (en) * | 2000-06-26 | 2002-01-03 | International Business Machines Corporation | Data management application programming interface for a parallel file system |
| US6751635B1 (en) * | 2000-08-18 | 2004-06-15 | Network Appliance, Inc. | File deletion and truncation using a zombie file space |
| KR100343231B1 (ko) * | 2000-08-28 | 2002-07-10 | 전창오 | 클러스터 파일 시스템 및 시스템내의 매핑 방법 |
| US6915515B2 (en) | 2000-12-21 | 2005-07-05 | International Business Machines Corporation | Method for creating path-sensitive branch registry for cyclic distributed transactions |
| US20040133606A1 (en) * | 2003-01-02 | 2004-07-08 | Z-Force Communications, Inc. | Directory aggregation for files distributed over a plurality of servers in a switched file system |
| TW561358B (en) * | 2001-01-11 | 2003-11-11 | Force Corp Z | File switch and switched file system |
| US8239354B2 (en) | 2005-03-03 | 2012-08-07 | F5 Networks, Inc. | System and method for managing small-size files in an aggregated file system |
| US7509322B2 (en) | 2001-01-11 | 2009-03-24 | F5 Networks, Inc. | Aggregated lock management for locking aggregated files in a switched file system |
| US7512673B2 (en) | 2001-01-11 | 2009-03-31 | Attune Systems, Inc. | Rule based aggregation of files and transactions in a switched file system |
| US7788335B2 (en) * | 2001-01-11 | 2010-08-31 | F5 Networks, Inc. | Aggregated opportunistic lock and aggregated implicit lock management for locking aggregated files in a switched file system |
| US8195760B2 (en) * | 2001-01-11 | 2012-06-05 | F5 Networks, Inc. | File aggregation in a switched file system |
| US7383288B2 (en) * | 2001-01-11 | 2008-06-03 | Attune Systems, Inc. | Metadata based file switch and switched file system |
| US20050160088A1 (en) * | 2001-05-17 | 2005-07-21 | Todd Scallan | System and method for metadata-based distribution of content |
| US7499924B2 (en) * | 2001-06-28 | 2009-03-03 | International Business Machines Corporation | Method for releasing update locks on rollback to savepoint |
| US20030004970A1 (en) * | 2001-06-28 | 2003-01-02 | Watts Julie Ann | Method for releasing update locks on rollback to savepoint |
| US7203670B2 (en) * | 2002-04-04 | 2007-04-10 | First Data Corporation | Method and system for maintaining enhanced file availability |
| WO2004008310A2 (en) * | 2002-07-11 | 2004-01-22 | International Business Machines Corporation | A method and system for extending the file system api |
| US11533365B2 (en) * | 2002-08-06 | 2022-12-20 | Stt Webos, Inc. | System and method for displaying and operating multi-layered item list in web browser with supporting of concurrent users |
| US20120079389A1 (en) * | 2002-08-06 | 2012-03-29 | Tsao Sheng Tai Ted | Method and Apparatus For Information Exchange Over a Web Based Environment |
| US8676843B2 (en) * | 2002-11-14 | 2014-03-18 | LexiNexis Risk Data Management Inc. | Failure recovery in a parallel-processing database system |
| US7240059B2 (en) * | 2002-11-14 | 2007-07-03 | Seisint, Inc. | System and method for configuring a parallel-processing database system |
| US7293024B2 (en) * | 2002-11-14 | 2007-11-06 | Seisint, Inc. | Method for sorting and distributing data among a plurality of nodes |
| US7945581B2 (en) * | 2002-11-14 | 2011-05-17 | Lexisnexis Risk Data Management, Inc. | Global-results processing matrix for processing queries |
| US6968335B2 (en) | 2002-11-14 | 2005-11-22 | Sesint, Inc. | Method and system for parallel processing of database queries |
| US7185003B2 (en) * | 2002-11-14 | 2007-02-27 | Seisint, Inc. | Query scheduling in a parallel-processing database system |
| US7877511B1 (en) | 2003-01-13 | 2011-01-25 | F5 Networks, Inc. | Method and apparatus for adaptive services networking |
| US7720846B1 (en) | 2003-02-04 | 2010-05-18 | Lexisnexis Risk Data Management, Inc. | System and method of using ghost identifiers in a database |
| US7657540B1 (en) | 2003-02-04 | 2010-02-02 | Seisint, Inc. | Method and system for linking and delinking data records |
| US7912842B1 (en) | 2003-02-04 | 2011-03-22 | Lexisnexis Risk Data Management Inc. | Method and system for processing and linking data records |
| US7403942B1 (en) | 2003-02-04 | 2008-07-22 | Seisint, Inc. | Method and system for processing data records |
| US7222119B1 (en) * | 2003-02-14 | 2007-05-22 | Google Inc. | Namespace locking scheme |
| US7343391B2 (en) * | 2003-03-05 | 2008-03-11 | Sun Microsystems, Inc. | System and method for interprocess services client artifact download |
| US8238696B2 (en) | 2003-08-21 | 2012-08-07 | Microsoft Corporation | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| US8166101B2 (en) | 2003-08-21 | 2012-04-24 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| WO2005050437A2 (de) * | 2003-11-21 | 2005-06-02 | Peter Neswal | Verfahren zur installation und konfiguration von softwarekomponenten |
| EP1591915A1 (en) | 2004-04-26 | 2005-11-02 | Sap Ag | Method, computer program product and computer device for processing data |
| US7143120B2 (en) * | 2004-05-03 | 2006-11-28 | Microsoft Corporation | Systems and methods for automated maintenance and repair of database and file systems |
| US7644239B2 (en) | 2004-05-03 | 2010-01-05 | Microsoft Corporation | Non-volatile memory cache performance improvement |
| US20060020760A1 (en) * | 2004-07-22 | 2006-01-26 | International Business Machines Corporation | Method, system, and program for storing sensor data in autonomic systems |
| US7490197B2 (en) | 2004-10-21 | 2009-02-10 | Microsoft Corporation | Using external memory devices to improve system performance |
| US7921076B2 (en) | 2004-12-15 | 2011-04-05 | Oracle International Corporation | Performing an action in response to a file system event |
| US7885970B2 (en) * | 2005-01-20 | 2011-02-08 | F5 Networks, Inc. | Scalable system for partitioning and accessing metadata over multiple servers |
| US20060167838A1 (en) * | 2005-01-21 | 2006-07-27 | Z-Force Communications, Inc. | File-based hybrid file storage scheme supporting multiple file switches |
| US7958347B1 (en) | 2005-02-04 | 2011-06-07 | F5 Networks, Inc. | Methods and apparatus for implementing authentication |
| CN1331038C (zh) * | 2005-07-21 | 2007-08-08 | 华中科技大学 | 基于对象的存储控制器及其使用的调度方法 |
| US7516422B2 (en) * | 2005-07-21 | 2009-04-07 | International Business Machines Corporation | Graphical display of hierarchical hardlinks to files in a file system |
| US8799680B2 (en) | 2005-09-15 | 2014-08-05 | Microsoft Corporation | Transactional sealed storage |
| US8949455B2 (en) | 2005-11-21 | 2015-02-03 | Oracle International Corporation | Path-caching mechanism to improve performance of path-related operations in a repository |
| US8914557B2 (en) | 2005-12-16 | 2014-12-16 | Microsoft Corporation | Optimizing write and wear performance for a memory |
| US10303783B2 (en) * | 2006-02-16 | 2019-05-28 | Callplex, Inc. | Distributed virtual storage of portable media files |
| US8996586B2 (en) * | 2006-02-16 | 2015-03-31 | Callplex, Inc. | Virtual storage of portable media files |
| US8417746B1 (en) | 2006-04-03 | 2013-04-09 | F5 Networks, Inc. | File system management with enhanced searchability |
| CN101427248B (zh) * | 2006-04-27 | 2013-05-22 | 英特尔公司 | 用于基于内容的分割与挖掘的基于系统的方法 |
| US7603388B2 (en) * | 2006-09-26 | 2009-10-13 | Microsoft Corporation | Representing file data using virtual hierarchy |
| US7840590B2 (en) * | 2006-12-18 | 2010-11-23 | Oracle International Corporation | Querying and fragment extraction within resources in a hierarchical repository |
| US20090077097A1 (en) * | 2007-04-16 | 2009-03-19 | Attune Systems, Inc. | File Aggregation in a Switched File System |
| WO2008147973A2 (en) * | 2007-05-25 | 2008-12-04 | Attune Systems, Inc. | Remote file virtualization in a switched file system |
| US8140474B2 (en) * | 2007-09-13 | 2012-03-20 | Intel Corporation | Aggregation of file/directory structures |
| US8117244B2 (en) | 2007-11-12 | 2012-02-14 | F5 Networks, Inc. | Non-disruptive file migration |
| US8180747B2 (en) | 2007-11-12 | 2012-05-15 | F5 Networks, Inc. | Load sharing cluster file systems |
| US20090204705A1 (en) * | 2007-11-12 | 2009-08-13 | Attune Systems, Inc. | On Demand File Virtualization for Server Configuration Management with Limited Interruption |
| US8548953B2 (en) * | 2007-11-12 | 2013-10-01 | F5 Networks, Inc. | File deduplication using storage tiers |
| US20090204650A1 (en) * | 2007-11-15 | 2009-08-13 | Attune Systems, Inc. | File Deduplication using Copy-on-Write Storage Tiers |
| US8631203B2 (en) * | 2007-12-10 | 2014-01-14 | Microsoft Corporation | Management of external memory functioning as virtual cache |
| US8352785B1 (en) | 2007-12-13 | 2013-01-08 | F5 Networks, Inc. | Methods for generating a unified virtual snapshot and systems thereof |
| US8266168B2 (en) * | 2008-04-24 | 2012-09-11 | Lexisnexis Risk & Information Analytics Group Inc. | Database systems and methods for linking records and entity representations with sufficiently high confidence |
| US8141029B2 (en) * | 2008-05-12 | 2012-03-20 | Expressor Software | Method and system for executing a data integration application using executable units that operate independently of each other |
| US8639705B2 (en) * | 2008-07-02 | 2014-01-28 | Lexisnexis Risk Solutions Fl Inc. | Technique for recycling match weight calculations |
| US8549582B1 (en) | 2008-07-11 | 2013-10-01 | F5 Networks, Inc. | Methods for handling a multi-protocol content name and systems thereof |
| DE202008016709U1 (de) | 2008-07-30 | 2009-04-30 | Friedrich, Georg | Flexibler Flaschenhalter, insbesondere für PET-Flaschen |
| US9032151B2 (en) | 2008-09-15 | 2015-05-12 | Microsoft Technology Licensing, Llc | Method and system for ensuring reliability of cache data and metadata subsequent to a reboot |
| US8032707B2 (en) | 2008-09-15 | 2011-10-04 | Microsoft Corporation | Managing cache data and metadata |
| US7953774B2 (en) | 2008-09-19 | 2011-05-31 | Microsoft Corporation | Aggregation of write traffic to a data store |
| US20110010690A1 (en) * | 2009-07-07 | 2011-01-13 | Howard Robert S | System and Method of Automatically Transforming Serial Streaming Programs Into Parallel Streaming Programs |
| US10721269B1 (en) | 2009-11-06 | 2020-07-21 | F5 Networks, Inc. | Methods and system for returning requests with javascript for clients before passing a request to a server |
| US9411859B2 (en) | 2009-12-14 | 2016-08-09 | Lexisnexis Risk Solutions Fl Inc | External linking based on hierarchical level weightings |
| US8204860B1 (en) | 2010-02-09 | 2012-06-19 | F5 Networks, Inc. | Methods and systems for snapshot reconstitution |
| US9195500B1 (en) | 2010-02-09 | 2015-11-24 | F5 Networks, Inc. | Methods for seamless storage importing and devices thereof |
| US8347100B1 (en) | 2010-07-14 | 2013-01-01 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
| US9189505B2 (en) | 2010-08-09 | 2015-11-17 | Lexisnexis Risk Data Management, Inc. | System of and method for entity representation splitting without the need for human interaction |
| US9286298B1 (en) | 2010-10-14 | 2016-03-15 | F5 Networks, Inc. | Methods for enhancing management of backup data sets and devices thereof |
| US8396836B1 (en) | 2011-06-30 | 2013-03-12 | F5 Networks, Inc. | System for mitigating file virtualization storage import latency |
| US8463850B1 (en) | 2011-10-26 | 2013-06-11 | F5 Networks, Inc. | System and method of algorithmically generating a server side transaction identifier |
| US9020912B1 (en) | 2012-02-20 | 2015-04-28 | F5 Networks, Inc. | Methods for accessing data in a compressed file system and devices thereof |
| US9519501B1 (en) | 2012-09-30 | 2016-12-13 | F5 Networks, Inc. | Hardware assisted flow acceleration and L2 SMAC management in a heterogeneous distributed multi-tenant virtualized clustered system |
| US20140136578A1 (en) * | 2012-11-15 | 2014-05-15 | Microsoft Corporation | Techniques to manage virtual files |
| US10375155B1 (en) | 2013-02-19 | 2019-08-06 | F5 Networks, Inc. | System and method for achieving hardware acceleration for asymmetric flow connections |
| US9554418B1 (en) | 2013-02-28 | 2017-01-24 | F5 Networks, Inc. | Device for topology hiding of a visited network |
| US10776325B2 (en) | 2013-11-26 | 2020-09-15 | Ab Initio Technology Llc | Parallel access to data in a distributed file system |
| US9607073B2 (en) | 2014-04-17 | 2017-03-28 | Ab Initio Technology Llc | Processing data from multiple sources |
| US11838851B1 (en) | 2014-07-15 | 2023-12-05 | F5, Inc. | Methods for managing L7 traffic classification and devices thereof |
| US10182013B1 (en) | 2014-12-01 | 2019-01-15 | F5 Networks, Inc. | Methods for managing progressive image delivery and devices thereof |
| US11895138B1 (en) | 2015-02-02 | 2024-02-06 | F5, Inc. | Methods for improving web scanner accuracy and devices thereof |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| DE112016003598T5 (de) * | 2015-10-20 | 2018-05-30 | International Business Machines Corporation | Gleichzeitige Massenverarbeitung von baumbasierten Datenstrukturen |
| US10223409B2 (en) * | 2015-10-20 | 2019-03-05 | International Business Machines Corporation | Concurrent bulk processing of tree-based data structures |
| US10133763B2 (en) | 2015-10-20 | 2018-11-20 | International Business Machines Corporation | Isolation of concurrent operations on tree-based data structures |
| US10102231B2 (en) | 2015-10-20 | 2018-10-16 | International Business Machines Corporation | Ordering heterogeneous operations in bulk processing of tree-based data structures |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
| US10321167B1 (en) | 2016-01-21 | 2019-06-11 | GrayMeta, Inc. | Method and system for determining media file identifiers and likelihood of media file relationships |
| US10412198B1 (en) | 2016-10-27 | 2019-09-10 | F5 Networks, Inc. | Methods for improved transmission control protocol (TCP) performance visibility and devices thereof |
| US10474668B2 (en) * | 2016-11-17 | 2019-11-12 | Sap Se | Database systems architecture incorporating distributed log |
| US10719492B1 (en) | 2016-12-07 | 2020-07-21 | GrayMeta, Inc. | Automatic reconciliation and consolidation of disparate repositories |
| US10567492B1 (en) | 2017-05-11 | 2020-02-18 | F5 Networks, Inc. | Methods for load balancing in a federated identity environment and devices thereof |
| US9934287B1 (en) * | 2017-07-25 | 2018-04-03 | Capital One Services, Llc | Systems and methods for expedited large file processing |
| US11223689B1 (en) | 2018-01-05 | 2022-01-11 | F5 Networks, Inc. | Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof |
| US10833943B1 (en) | 2018-03-01 | 2020-11-10 | F5 Networks, Inc. | Methods for service chaining and devices thereof |
| US12003422B1 (en) | 2018-09-28 | 2024-06-04 | F5, Inc. | Methods for switching network packets based on packet data and devices |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5202971A (en) * | 1987-02-13 | 1993-04-13 | International Business Machines Corporation | System for file and record locking between nodes in a distributed data processing environment maintaining one copy of each file lock |
| WO1994018634A1 (en) * | 1993-02-01 | 1994-08-18 | Lsc, Inc. | Archiving file system for data servers in a distributed network environment |
| US5446915A (en) * | 1993-05-25 | 1995-08-29 | Intel Corporation | Parallel processing system virtual connection method and apparatus with protection and flow control |
| US5603019A (en) * | 1994-07-25 | 1997-02-11 | International Business Machines Corporation | Takeover technique for networked virtual filesystems |
| US5682537A (en) * | 1995-08-31 | 1997-10-28 | Unisys Corporation | Object lock management system with improved local lock management and global deadlock detection in a parallel data processing system |
-
1997
- 1997-06-16 US US08/876,734 patent/US5897638A/en not_active Expired - Lifetime
-
1998
- 1998-06-16 WO PCT/US1998/012522 patent/WO1998058331A1/en active Application Filing
- 1998-06-16 JP JP50468599A patent/JP3754459B2/ja not_active Expired - Lifetime
- 1998-06-16 CA CA002294397A patent/CA2294397C/en not_active Expired - Lifetime
- 1998-06-16 AU AU79707/98A patent/AU7970798A/en not_active Abandoned
- 1998-06-16 EP EP98930283A patent/EP0996900A4/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000513857A (ja) | 2000-10-17 |
| EP0996900A4 (en) | 2005-03-30 |
| US5897638A (en) | 1999-04-27 |
| AU7970798A (en) | 1999-01-04 |
| WO1998058331A1 (en) | 1998-12-23 |
| CA2294397C (en) | 2003-10-21 |
| CA2294397A1 (en) | 1998-12-23 |
| EP0996900A1 (en) | 2000-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3754459B2 (ja) | 並列仮想ファイルシステム | |
| KR101117208B1 (ko) | 트랜잭션 시스템에서의 보안 데이터 삭제 | |
| US5857204A (en) | Restoring the state of a set of files | |
| US9442952B2 (en) | Metadata structures and related locking techniques to improve performance and scalability in a cluster file system | |
| US6928444B2 (en) | Automatic backup/recovery process | |
| US6857053B2 (en) | Method, system, and program for backing up objects by creating groups of objects | |
| US5812130A (en) | Data management system and method for concurrent engineering | |
| US7680836B2 (en) | Systems and methods for a snapshot of data | |
| KR101573965B1 (ko) | 분산형 저장 시스템 내의 데이터의 원자 다중 변경 | |
| US7680842B2 (en) | Systems and methods for a snapshot of data | |
| US20080027998A1 (en) | Method and apparatus of continuous data protection for NAS | |
| CA2326152C (en) | Indication of failure in a transaction processing system | |
| US7325017B2 (en) | Method of implementation of data storage quota | |
| US7958097B1 (en) | Method and system for implementation of data storage quota | |
| EP0097239A2 (en) | Method and apparatus for restoring data in a computing system | |
| Shaik et al. | PostgreSQL architecture | |
| Holyer et al. | A recovery mechanism for shells | |
| Greenwald et al. | Oracle in a Nutshell: A Desktop Quick Reference | |
| Malcher et al. | Data Pump | |
| CN116467280A (zh) | 基于对象存储和细粒度访问控制的分布式版本控制方法 | |
| Curtis et al. | Basic Replication Configuration | |
| JP2002049519A (ja) | 情報処理装置およびその方法 | |
| Kreines | Oracle DBA pocket guide |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040302 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040928 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041105 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051122 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051216 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091222 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091222 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111222 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121222 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121222 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131222 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |