JP2006524392A - 一回書き込み複数回読み出し式ストレージ・システム及びその実施方法 - Google Patents

Abstract

大容量で比較的安価なディスクをファイルサーバ上のファイルシステムと組み合わせて使用する一回書き込み複数回読み出し式（ＷＯＲＭ）ストレージ・システムを提供する。ファイルシステムは必須ＷＯＲＭ機能のほとんど又は全部を有し、必要であれば最小限の足跡をクライアント・アプリケーション、クライアント・オペレーティング・システム、及びオープン・プロトコルに課す。システムはファイルを有するＷＯＲＭストレージ・ボリュームとして概ね編成され、ファイルはＷＯＲＭストレージに格納されると、削除も変更も出来なくなる。ＷＯＲＭボリューム内でファイルの識別に使用されるファイル・パスやディレクトリ・ツリー構造はいずれも変更が禁止され、削除することができない。一実施形態において、管理者は指定されたＷＯＲＭファイルを格納することが可能なＷＯＲＭボリュームを作成する。次にクライアントは、適当なプロトコル・セマンティックを使用して適当なＷＯＲＭファイルを作成する。このファイルは、ファイル属性を読み出し専用以外の状態から読み出し専用状態に変更することによってボリュームに書き込まれ、収容される。それ以後、クライアント、管理者、またはその他のエンティティによるファイル属性の変更や、そのファイルへの書き込み、あるいはそのファイルの削除などの試みはいずれも拒否され、それを試みた者に対し要求拒否メッセージが返送される。

Description

本発明は、データ完全性を向上させるための、一回書き込み複数回読み出し機能を有するデータ・ストレージ・システムに関する。

ファイル・サーバは、ディスク等のストレージ・デバイス上での情報の編成に関するファイル・サービスを提供するコンピュータである。ファイル・サーバまたはファイラは、ファイルシステムを実現するストレージ・オペレーティング・システムを有し、情報をディレクトリやファイルの階層構造としてディスク上に編成する。「ディスク上」の各ファイルは、情報を格納するように構成された例えばディスク・ブロックのような一連のデータ構造として実現される。一方、ディレクトリは特殊な形式のファイルとして実現され、その中に他のファイルやディレクトリに関する情報が格納される。

ファイラは情報のクライアント／サーバモデルに従って動作するように更に構成されるため、多数のクライアントが、サーバに格納されたファイルにアクセスすることが出来る。このモデルでは、クライアントは、データベース・アプリケーションのようなアプリケーションをコンピュータ上で実行し、直接接続、または、ポイント・ツー・ポイント接続、共有ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）若しくはインターネット等の公衆回線を介して実施される仮想私設ネットワーク（ＶＰＮ）のようなコンピュータネットワークを介してファイラに接続する。各クライアントは、ネットワークを介してファイルシステム・プロトコル・メッセージをファイラに送信することにより、ファイラ上のファイルシステムに関するサービスを要求することができる。

ファイルシステムの一般的な形は「その場書き込み式」ファイルシステムであり、その一例は従来のバークレイ・ファスト・ファイルシステムである。「ファイルシステム」という言葉は大抵、データの読み出しや書き込みが可能なディスク等のストレージ・デバイス上におけるデータやメタデータの構造を意味する。その場書き込み式ファイルシステムでは、ディスク上のｉｎｏｄｅやデータブロックなどのデータ構造の位置が、通常固定されている。ｉｎｏｄｅは、ファイルに関するメタデータなどの情報の格納に使用されるデータ構造であり、データブロックは、そのファイルの実際のデータの格納に使用される構造である。ｉｎｏｄｅに格納される情報には、例えば、そのファイルの所有者、そのファイルのアクセス権、そのファイルのサイズ、そのファイルの種類、及び、そのファイルのデータブロックのディスク上での位置の指示などがある。ファイルデータの位置の指示はポインタとしてｉｎｏｄｅに設けられ、ファイル内のデータ量によっては、ｉｎｏｄｅはデータブロックを参照する間接ブロックをさらに参照する場合がある。ｉｎｏｄｅやデータブロックに対する変更は、その場書き込み式ファイルシステムに従って「その場」で行われる。ファイルの更新によりそのファイルのデータ量が増えた場合、さらにデータブロックが割り当てられ、そのデータブロックを参照するように適当なｉｎｏｄｅが更新される。

他の種類のファイルシステムとしては、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムがある。ディスクからデータブロックをメモリに取り出し（読み出し）、そのデータブロックが新たなデータで「汚された」場合でも、そのデータブロックは、ディスク上の新たな位置に記憶されるため、書き込み性能を最適にすることが出来る。Ｗｒｉｔｅ ａｎｙｗｈｅｒｅファイルシステムは、まずディスク上にデータが連続的に配置されるような最適レイアウトを仮定する。この最適レイアウトにより、効率的なアクセス動作が可能になる。特に、ディスクに対するシーケンシャル読み出し動作が効率的になる。ファイラ上で動作するように構成されたｗｒｉｔｅ ａｎｙｗｈｅｒｅファイルシステムの一例には、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス社から市販されているＷｒｉｔｅ Ａｎｙｗｈｅｒｅファイルレイアウト（ＷＡＦＬ）がある。ＷＡＦＬファイルシステムはマイクロカーネルの中で実施され、ファイラ及び関連ディスク・ストレージのプロトコル・スタック全体の一部として実施される。このマイクロカーネルは、ネットワーク・アプライアンス社のＤａｔａ ＯＮＴＡＰソフトウェアの一部として提供され、ファイラに常駐し、ネットワーク接続されたクライアントからのファイルサービス要求を処理する。

本明細書で使用される場合、「ストレージ・オペレーティング・システム」という用語は一般に、データアクセスを管理するための、コンピュータ上で動作するコンピュータ実行可能コードを意味し、ファイラの場合、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス社から市販されている、マイクロカーネルとして実施されるＤａｔａ ＯＮＴＡＰストレージ・オペレーティング・システムのような、ファイルシステム・セマンティックを実施する場合がある。ＤＡＴＡ ＯＮＴＡＰストレージ・オペレーティングシステムは、Ｗｒｉｔｅ Ａｎｙｗｈｅｒｅファイルレイアウト（ＷＡＦＬ）ファイルシステムを実現する。このストレージ・オペレーティング・システムは、ＵＮＩＸやＷｉｎｄｏｗｓ ＮＴなどの汎用オペレーティング・システム、あるいは本明細書に記載するストレージ・アプリケーションに合わせて構成された機能を有する汎用オペレーティング・システム上で動作するアプリケーション・プログラムとして実施することも可能である。

データ・ストレージは通常１以上のストレージ「ボリューム」として実施され、ストレージ・ボリュームは、記憶空間の全体的論理配置を決める複数の物理ストレージ・ディスクからなる。現在市販されているファイラ実施形態は、多数（例えば１５０以上）の独立したボリュームを提供することが出来る。各ボリュームは独自のファイル・システムに関連しているので、本明細書では、ボリュームとファイルシステムは概ね同義語として使用される。ボリューム内のディスクは通常１以上のＲＡＩＤグループに編成される。ＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所定数の物理ディスクにわたってデータを「ストライプ」状に冗長書き込みし、そのストライプ状のデータに対するパリティ情報を適切にキャッシュすることにより、データ記憶の信頼性／完全性を向上させる。ＷＡＦＬファイルシステムの例の場合、ＲＡＩＤ４実施形態が有利に使用される。この実施形態は具体的には、１グループのディスクにわたってデータをストライピングし、そのＲＡＩＤグループ内の選択されたディスクにキャッシュされるパリティを分離しなければならない。本明細書に記載するように、ボリュームは通常、ＲＡＩＤ４またはそれと同等の高い信頼性の実施形態に従って構成された、少なくとも１つのデータ・ディスク及び１つの関連パリティ・ディスク（または、単一ディスク中のデータ区画／パリティ区画）から構成される。

データ・ストレージは益々重要性を増していて、金融取引の他、銀行、政府機関／請負業者、国防、健康管理施設、薬品会社、セキュリティ仲介業務などのような他の細心の注意を要する業務に関わる多くの業務の中心になっている。こうした環境の多くでは、特定のデータを不変かつ変更不可能に記憶しなければならない。一部の犯罪者は常に重要なデータを消したり変更したりする誘惑を受けているという、制度上の不正や運用の誤りを超えた現在の問題を考えれば、このような必要性は拡大し続けるであろう。変更不可の扱いを要するデータ形態には、電子メール、金融書類、及び取引記録の他、重要な行動や決定の証拠として使用される他のあらゆる記録が含まれうる。あまり重要でない環境や規制の無い環境であっても、安全で変更不可能なデータ・キャッシュを記憶する機能は、強く望まれている。例えば、技術、医療、法律その他の専門事務所は、重要データ（例えば、発明報告、設計ファイル、クライアントとのやりとり、医療画像など）のキャッシュを作成し、それを長い時間にわたって変更不可かつオンラインに保ちたいと望むことがある。このようなキャッシュによれば、クライアントその他の関係者は、信頼性の高い参照や、証拠の受け取りが可能になる。

例えば、規制の厳しい環境の例として、公共団体に関する証券取引や帳簿管理を全て統制する機関である米国の証券取引委員会（ＳＥＣ）は、文書の保存について規定するＳＥＣ Ｒｕｌｅ １７ａ−７を仲買人や投資機関に対して発布している。この規則によれば、それらの団体は、それらの団体のクライアントが行った様々な取引や売買に関連する電子メールその他の文書を数年にわたって変更することなく且つ変更不可能な状態で保管しておき、突然の依頼であっても、それらの記録をＳＥＣや他の取締り機関に提出出来なければならない。これらの規則に誤って違反すると、重大な制裁措置を取られることがある。

特定のデータを不変的に記録するための最も簡単な方法は、当該データをハードコピーの形で印刷し、それを決められた手順で紙の記録やマイクロフィッシュとして保管することである。この方法の欠点はたくさんある。プリントアウトやマイクロフィッシュへの転写は定期的に且つ継続的に行わなければならないので、莫大な労働時間を投入しなければならない可能性がある。物理的保管には広い空間が必要である。大抵の場合、入力データの量は、それを処理する物理的なストレージ・システムの能力を直ぐに上回ってしまう。こうしたデータの読み出しはもともと遅く、人間の手違いにより、少なくとも一部のデータが誤った場所にファイリングされたり、データが全くファイリングされなかったりすることがある。従ってこの方法は、不変記憶を必要とする、増大し続けるボリュームには適さない。それよりもかなり優れた方法には、非物理記憶媒体（例えば、光、テープ、ディスクなどを利用する記憶媒体）を使用する方法がある。

コンピュータを利用したストレージ・システムにおいて不変的データのキャッシュを作成する一般的方法の１つは、データを処理する１以上のファイル・サーバと通信する一連の一回書き込み多数回読み出し式（「ＷＯＲＭ」と呼ばれる）ストレージ・デバイスを設けることである。基本的なＷＯＲＭデバイスは、ファイル・サーバのメモリやディスクの内容を所定時刻にバックアップおよび保存する幾つかの着脱式テープドライブから構成される。このテープドライブに固有の機能は、記憶された特定データのＷＯＲＭコピーを作成する機能である。管理者がＷＯＲＭテープコピーの作成を命じると、テープドライブは、そのＷＯＲＭデータが格納されるテープのセグメントに１以上の索引タグを記録する。以後、テープドライブはこのタグをＷＯＲＭコピーとして認識し、タグの存在に応じてそのセグメントの上書きを禁止する。この方法は有効ではあるが、未だ欠点に満ちている。テープの記憶容量には比較的制限があるので、一杯になったらテープを物理的に取り外したり取り付けたりしなければならない。そのためには人が介入する必要があり、物理的テープを見つけ、取り付け、再生しなければならないので、テープの浪費や誤記録が発生し、情報の読み出し速度が低下する可能性がある。また、ＷＯＲＭ機能は、タグを認識し、上書きを防止するというドライブの機能に大きく依存している。ドライブが壊れたり、時間の経過によりドライブが時代遅れになれば、関連するＷＯＲＭタグも、新しいドライブにとって無意味になる可能性がある。

比較的最近のＷＯＲＭシステムは、電気光学ドライブを使用し、光記憶プラッタの内部スタックを有している（書き込み式コンパクトディスクのように）。この手のドライブは、プラッタを駆動レーザで化学的にエッチングすることによりデータパターンを形成していて、それらのデータパターンは所与の記憶位置に一回だけしかエッチングされないので、ＷＯＲＭコピーの作成に非常に有効である。光記憶装置の欠点は、従来のディスクやテープに比べてドライブが高価であることであり、もっと重大なのは、いまだに最大記憶サイズに大きな物理的制限があることである。言い換えれば、これらのドライブは数百ギガバイトのデータを容易に扱うことが可能であるが、流行は数テラバイトのデータの記憶装置に向かっている。このように、材料と労働力をかなり犠牲にして、新たなドライブやプラッタをシステムに追加し続けなけばならない。テープや他のディスク以外の媒体と同様に、書き込み速度も、従来のディスク記憶装置に比べていくらか遅い。

ＷＯＲＭストレージにとって本来望ましい方法は、従来のフォールト・トレラント（無停止型）なディスク記憶装置（または似たような書き替え可能媒体）をＷＯＲＭストレージ・システムのプラットフォームとして使用することであろう。こうしたディスクは比較的安価であり、既存のストレージ・システムに簡単に追加することが出来る。しかしながら、ディスクは本来書き替え可能および／または消去可能であり、既存のオペレーティング・システムおよびプロトコルは、取り付けたディスクの自由な書き替えおよび消去を可能にするセマンティックで設計されている。ディスクを使用してＷＯＲＭストレージを実現する解決法はいずれも、ＷＯＲＭ設計のデータの変更を完全に防止しなければならない。また、解決法の寿命を延ばし、出来る限り多数のクライアントがその解決法を利用できるようにするためには、ＷＯＲＭ実施形態は、ＣＩＦＳやＮＦＳ等のようなオープン・プロトコルを使用し、それらのプロトコルやそれらのプロトコルを使用するアプリケーションに対する変更を最小限にしなければならない。

本発明は、大容量かつ比較的安価なディスクを使用する一回書き込み複数回読み出し式（ＷＯＲＭ）ストレージシステムを、必須ＷＯＲＭ機能のほとんど又は全てを有するファイルサーバ上のファイルシステムとともに提供し、必要であれば、クライアント・アプリケーション、クライアント・オペレーティングシステム、およびオープン・プロトコルに最小限の足跡を課す。このシステムは、複数のＷＯＲＭストレージ・ボリュームに編成され、ファイルがこのＷＯＲＭストレージに収容されると、消去したり変更したりすることは出来ない。ＷＯＲＭボリューム内でファイルの識別に使用されるファイル・パスまたはディレクトリ・ツリー構造はいずれもロックされ、消去することは出来ない。

一実施形態において、管理者は指定されたＷＯＲＭファイルを格納することが可能なＷＯＲＭボリュームを作成する。次にクライアントは、適当なプロトコル・セマンティックを使用し、適当なＷＯＲＭファイルを作成する。ファイルの属性を非読み出し専用状態から読み出し専用状態に変更することにより、そのファイルはＷＯＲＭボリュームに書き込まれ、ＷＯＲＭ状態にされる。ファイルシステムは、ＷＯＲＭ状態のファイルをそのファイルの属性およびメタデータとともに持続的に記憶し、この持続的ＷＯＲＭ状態を使用してＷＯＲＭボリューム上のＷＯＲＭファイルを認識する。その後は、ファイル属性を変更したり、ファイルに書き込もうとしたり、ファイル消去したりしようとするクライアントの試みが全て拒否され、要求拒否メッセージが、その試みを行った者に返送される。従来のファイルシステム・セマンティックは、ファイルを消去することが出来ないので、ディレクトリ・パスの消去を防止している。同様に、本ファイルシステムは一実施形態において、ディレクトリの名前変更を許可しないことにより、ディレクトリ構造におけるＷＯＲＭファイルの信頼性の高い不変的な識別を確保している。

一実施形態において、クライアントによるＷＯＲＭファイルのＷＯＲＭストレージ・ボリュームへの収容は、コマンドライン・インタフェースにより対話的な態様で実施される。あるいは、ＷＯＲＭセマンティックに精通しているアプリケーションは、ファイルを適当なアプリケーション・プログラム・インタフェースまたは他のプログラムのようなコマンド構造を使用して格納するようにしてもよい。同様に、クライアントがファイルサーバ／ファイルシステムとの通信に使用するＮＦＳやＣＩＦＳなどのオープン・プロトコルは、ファイルを閉じる等のキー・イベントに応じて作成ファイルを自動的に収容するように変更することもできる。

他の実施形態において、プロトコルおよびファイルシステムは、ボリューム内に特殊なＷＯＲＭディレクトリを作成できるように構成される場合がある。適当なＷＯＲＭ拡張を行うことで、クライアントはボリューム内のＷＯＲＭファイルを容易に識別することが可能になる。また、選択されたミラーリング機能およびバックアップ機能を有効にすると同時に、早い時点でのボリュームの復旧や復元が可能な他のバックアップ機能を無効にする場合もある。

本発明の上記の利点およびその他の利点は、添付の図面とあわせて下記の説明を読むことでさらによく理解することができるであろう。図面において、同じ符号は同一の要素または機能的に類似の要素を示している。

Ａ． ネットワークおよびファイルサーバ環境
さらなる背景技術として、図１は、本発明とともに使用するのに都合がよいファイルサーバ１１２を含むストレージ・システム環境１００を示す略ブロック図である。説明の目的で、ソース・システムは、１以上のストレージ・ディスク１６０を管理するネットワーク・コンピュータであるものとする（図１では１６２が見付からない）。

ファイルサーバまたは「ファイラ」１１２は、ディスク・アレイ１６０を含むボリューム１１５および１１６を管理する。ファイラ１１２は、ローカルエリア・ネットワークまたは周知のインターネットのようなワイドエリア・ネットワークからなるネットワーク１１８に接続される。適当なネットワーク・アダプタ１１６により、ネットワーク１１８を介した通信を実現することができる。ファイラ１１２は通常、プロセッサ１２０、メモリ１２５、ネットワーク・アダプタ１３０、およびストレージ・アダプタ１４０を含み、それらがシステム・バス１４５によって相互接続される。ファイラ１１２は更に、ファイルシステムを実現するストレージ・オペレーティング・システム２００（図２）を有し、情報をディレクトリおよびファイルの階層構造に論理編成する。

当業者であれば、本発明の技術が、スタンドアロンのコンピュータを含めて、ストレージ・システムとして実施されるいかなる種類の特殊な目的のコンピュータ（例えばファイルサービス・アプライアンス）や汎用コンピュータにも適用できることが分かるであろう。この目的のために、ファイラ１１２は概して、また替わりにストレージ・システムと呼ばれることもある。また、本発明の教示は、ネットワーク取り付けストレージ環境、ストレージ・エリア・ネットワーク、および、クライアントコンピュータまたはホストコンピンータに直接取り付けられたディスク・アセンブリなどを含めて、様々なストレージ・システム・アーキテクチャに適合させることができる。従って、「ストレージ・システム」という用語は、そうした構成も含むものとして広い意味で解釈しなければならない。

一実施形態において、メモリ１２５は、プロセッサおよびアダプタがソフトウェア・プログラム・コードを格納するためのアドレス指定可能な複数の記憶位置を有する。メモリは一般に、電源再投入その他のリブート操作により消去されるランダム・アクセス・メモリ（ＲＡＭ）の形をとる（すなわち、「揮発」メモリである）。また、プロセッサおよびアダプタは、ソフトウェア・コードを実行し、データ構造を操作するように構成された処理要素および／または回路からなる。ストレージ・オペレーティング・システム２００の幾つかの部分は通常、メモリに常駐し、処理要素によって実行され、ファイラの機能を構成する。すなわち、ファイラによって実施されるファイル・サービスを支える記憶処理を実施する。当業者であれば、他の処理手段や、様々なコンピュータ読取可能媒体のような他の記憶手段を使用して、本明細書に記載する発明の技術に関するプログラム命令を記憶したり実行したりすることも可能であることは明らかであろう。

ネットワーク・アダプタ１３０は、ファイラ１１２をネットワーク１１８に接続するのに必要とされる機械的、電気的、および信号的回路を含む。ネットワーク１１８は、ポイント・ツー・ポイント接続であってもよいし、ローカル・エリア・ネットワークのような共有媒体であってもよい。クライアント（１７０、１７２）は、クライアント／サーバモデルの情報配送に従って、宛先ファイラ１１２と通信することが出来る。すなわち、クライアントがファイラにサービスを要求すると、そのファイラは、例えばＴＣＰ／ＩＰプロトコル・フォーマットや他のネットワーク・プロトコル・フォーマット（それぞれ、ＣＩＦＳ１７４およびＮＦＳ１７６）をカプセル化したパケット１１５をネットワーク１１８を介して交換することにより、クライアント１７０および１７２から要求されたサービスの結果を返す。

ストレージ・アダプタ１４０は、ファイラ１１２上で実行されているストレージ・オペレーティング・システム２００と協働し、クライアントから要求された情報を取得する。この情報は、ストレージ・アダプタ１４０を介してファイラ１１２に取り付けられたディスク１６０に格納されている場合もあれば、本明細書に記載されるようなストレージ・システムの他のノードに格納されている場合もある。ストレージ・アダプタ１４０は入出力（Ｉ／Ｏ）インタフェース回路を有し、Ｉ／Ｏインタフェース回路は従来の高性能ファイバ・チャネル・シリアル・リンク・トポロジのようなＩ／Ｏ相互接続構成でディスクに接続される。ストレージ・アダプタによって取得された情報は、後で説明するスナップショット手順の一部としてプロセッサによって処理され、システム・バス１４５を介してネットワーク・アダプタ１３０に転送され、同様に後で説明するように、そこでその情報がパケットに成形され、宛先サーバに送信される。

ファイラは更に、ネットワーク・アダプタ１３０を介して１以上のクライアント１７０にも相互接続することができる。各クライアントはそれぞれファイルサービス要求をファイラ１１２に送信し、ＬＡＮまたは他のネットワーク（１１８）を介してその要求の応答を受信する。クライアント１７０、１７２とファイラ１１２の間で転送されるデータはそれぞれ、コモン・インターネット・ファイル・システム（ＣＩＦＳ）プロトコル（１７４）またはＮＦＳ（１７６）のような他の適当なプロトコルのカプセル化として定義されるデータパケットを使用して転送される。

一実施形態においてファイラ１１２は、故障の影響を受けずにデータのバックアップが可能な不揮発性ランダム・アクセス・メモリ（ＮＶＲＡＭ）１３５を有し、それによってファイラ・トランザクションの完全性を確保し、電源故障や他の故障によるサービスの中断を免れることが出来る。ＮＶＲＡＭのサイズは、ＮＶＲＡＭの実施形態やファイルサーバの機能によって異なる場合がある。ＮＶＲＡＭのサイズは通常、特定時間（例えば、数秒間）内におけるトランザクションの集まりをログに記録するのに十分なサイズに設定される。各クライアント要求が完了した後、その要求の結果が要求元クライアントに返されるまでの間に、ＮＶＲＡＭはバッファ・キャッシュと平行して使用される。

図示の実施形態では、ファイルサーバの種々の機能及び動作を制御するために、管理者コンソール１９０が更に設けられている。コンソール１９０は、専用ポートを介してファイルサーバに接続されたクライアントや端末であってもよいし、ネットワーク１１８を介してファイルサーバにネットワーク接続された遠隔地のクライアントや端末であってもよく、ファイルサーバから長距離離れていてもよい。図示の実施形態では、後で説明する特定のコマンドが、コンソールから入力される。

図示の実施形態において、ディスク１６０は、複数のボリューム（例えばボリューム０（１１５）とボリューム１（１１６））に編成されている。各ボリュームは、そのボリュームに関連するファイルシステムを有する。ボリューム１１５及び１１６はそれぞれ１以上のディスク１６０を含む。一実施形態において、物理ディスク１６０は、複数のＲＡＩＤグループに編成される。この編成は、好ましくはＲＡＩＤ４構成に従って、一部のディスクにストライプ状にデータを記憶し、一部のディスクにそのデータのパリティを別個に記憶するように構成される。但し、他の構成（例えば、複数のストライプにわたってパリティを分散させるＲＡＩＤ５）も可能である。この実施形態では、最小で１台のパリティ・ディスクと１台のデータ・ディスクが使用される。しかしながら、典型的な実施形態では、１つのボリューム当たり複数のＲＡＩＤグループが使用され、１つのＲＡＩＤグループ当たり３台のデータ・ディスクと１台のパリティ・ディスクが使用される。後で説明するように、ボリューム０（１１５）は読み出しと書き込みの両方のアクセスが可能な通常のストレージ・ボリュームである一方、ボリューム１（１１６）は、特定ファイルがそのボリュームに格納された後、その特定ファイルを変更したり消去したりすることができない一回書き込み複数回読み出し式（ＷＯＲＭ）ボリュームである。

Ｂ． ストレージ・オペレーティング・システム
ディスク１６０に対するアクセスを一般化するために、ストレージ・オペレーティング・システム２００（図２）は、情報をディスク上にディレクトリやファイルの階層構造として論理編成するｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。「ディスク上」の各ファイルはデータなどの情報を格納するように構成された一連のディスク・ブロックとして実施される一方、ディレクトリは特殊な形式のファイルとして実施され、そこに他のファイルやディレクトリへの参照が格納される。上で説明・定義したように、本明細書に記載する一実施形態において、このストレージ・オペレーティング・システムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス社から市販されているＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰオペレーティングシステムであり、このオペレーティング・システムは、Ｗｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムを実現する。当然ながら適当なファイルシステムであればどのようなファイルシステムでも使用することが出来るので、「ＷＡＦＬ」という用語を使用した場合でも、この言葉は、本発明の教示に適合する任意のファイルシステムを指すものとして広い意味で解釈しなければならない。

次に、ファイラの各例について、好ましいストレージ・オペレーティング・システムの構成を簡単に説明する。但し、当然ながら、本発明の原理は、様々な代替のストレージ・オペレーティング・システム・アーキテクチャを使用して実施することも可能である。図２に示すように、図示のストレージ・オペレーティング・システム２００は、ネットワーク・ドライバ（例えば、イーサネット・ドライバ）からなる媒体アクセス層２０５を含む、一連のソフトウェア層を含む。ストレージ・オペレーティング・システムは更に、インターネット・プロトコル（ＩＰ）層２１０と、それに支援されるトランスポート手段であるトランスポート・コントロール・プロトコル（ＴＣＰ）層２１５及びユーザ・データグラム・プロトコル（ＵＤＰ）層２２０とを含む。ファイルシステム・プロトコル層は、マルチプロトコル・データアクセスを可能にし、その目的のために、ＣＩＦＳプロトコル２２５、ｉＳＣＳＩプロトコル２２４、ＮＦＳプロトコル２３０、ハイパー・テキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル２３５、および他のプロトコル（図示せず）を含む。それらのプロトコルはオープン形態であってもよいし、ＮＦＳバージョン４のように所有者が居るものであってもよい。また、ストレージ・オペレーティング・システム２００は更に、ＲＡＩＤプロトコルのようなディスク・ストレージ・プロトコルを実施するディスク・ストレージ・層２４０と、スモール・コンピュータ・システム・インタフェース（ＳＣＳＩ）のようなディスク制御プロトコルを実施するディスク・ドライバ層２４５とを含む。

ディスク・ソフトウェア層とファイルシステム・プロトコル層との間を橋渡しするのが、ストレージ・オペレーティング・システム２００のファイルシステム層２５０である。一般に、ファイルシステム層２５０は、例えば４キロバイト（ＫＢ）のデータブロックを使用したブロック単位のディスク上フォーマットを有するファイルシステムを実施し、ｉｎｏｄｅや他のデータ構造を使用してファイルを表現する。注意して欲しいのは、図示の実施形態ではファイルが実施されているが、「ファイル」という用語は、ＳＣＳＩのようなブロックレベルのプロトコルが使用される任意のタイプのデータ編成または「データ・コンテナ」を含むように、広い意味で解釈しなければならない点である。従って、「データ・コンテナ」という用語も、本明細書では同じ意味で使用される。

ファイルシステムは、トランザクション要求に応答し、要求されたデータが「コア」内に存在しなければ、すなわち、ファイラのメモリ２２５内に存在しなければ、その要求されたデータをボリュームからロード（取得）する処理を開始する。要求された情報がメモリ内に無い場合、ファイルシステム層２５０は、ｉｎｏｄｅ番号を用いてｉｎｏｄｅファイルを検索し、適当なエントリにアクセスし、ボリューム・ブロック番号を取得する。次に、ファイルシステム層２５０はそのボリューム・ブロック番号をディスク・ストレージ（ＲＡＩＤ）層２４０に渡し、ディスク・ストレージ層２４０はそのボリューム・ブロック番号をディスク・ブロック番号にマッピングし、そのディスク・ブロック番号をディスク・ドライバ層２４５の適当なドライバ（例えば、ファイバ・チャネル・ディスク相互接続上で実施されるＳＣＳＩのカプセル化）に送る。ディスク・ドライバは、複数のボリュームの中からそのディスク・ブロック番号にアクセスし、要求されたデータをメモリ１２５にロードし、ファイラ１１２（図１を参照）によって処理させる。要求の処理が完了すると、ファイラ（及びストレージ・オペレーティング・システム）は、対応するネットワーク接続１７２を介してクライアント１７０に返答を返す。この返答は、例えばＣＩＦＳ仕様に規定されている従来の受領応答パケットである。

注意して欲しいのは、ファイラで受信されたクライアント要求に対してデータ・ストレージ・アクセスを実施するのに必要とされる上記のようなストレージ・オペレーティング・システムの各層を通るソフトウェア「パス」２７０は、代替としてハードウェアで実施してもよいし、ハードウェアとソフトウェアの組み合わせで実施してもよい点である。すなわち、本発明の代替実施形態では、ストレージ・アクセス要求データパス２７０は、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の中に構成された論理回路として実施される場合がある。この手のハードウェア実施形態は、クライアント１７０から発行されたファイルシステム要求パケットに応答して、ファイラ１１２によって提供されるファイル・サービスの性能を向上させることが出来る。

図面に関する詳しい説明を続ける前に、バックアップに関する簡単な説明をした方が良いであろう。信頼性を向上させ、ファイラやファイラに接続されたディスク、若しくはストレージ・インフラの故障時に災害復旧を容易にするために、基本データ及び／又はデータを編成するためのファイルシステムの一部または全部は、「ミラーリング」または複製されるのが一般的である。一例において、ミラーは遠隔地に作成・保管されるため、メインの保管場所またはそのインフラが大災害（例えば、洪水、停電、戦争行為など）によって被害を受けたときでも、その復元可能性は高い。ファイルシステムに対する最新の変更を入手するために、ミラーは一定時間間隔で更新される。この時間間隔は一般に管理者によって設定される。

更新の１つの一般的な形として、「スナップショット」プロセスを利用したものがある。スナップショットプロセスでは、保管場所にあるアクティブ・ファイルシステム（ｉｎｏｄｅとブロックから構成される）をキャプチャし、そのスナップショットを全てネットワーク（例えば、周知のインターネットなど）を介して遠くの保管場所に送信する。通常、スナップショットは、ある時点におけるファイルシステムのイメージ（通常は読み出し専用）であり、アクティブ・ファイルシステムと同じ一次ストレージ・デバイスに格納され、アクティブ・ファイルシステムのユーザはそのスナップショットにアクセスすることができる。「アクティブ・ファイルシステム」とは、現在の入出力処理の対象となっている宛先のファイルシステムを意味する。一次ストレージ・デバイス（例えば、一連のディスク）は、アクティブ・ファイルシステムを格納する一方、２次ストレージ・デバイス（例えば、テープドライブ）は、アクティブ・ファイルシステムのバックアップに使用される。スナップショットをとった後（すなわち、イメージをキャプチャした後）、起こり得る災害に備えてそのスナップショットを適所に残したまま、そのアクティブ・ファイルシステムが復旧される。スナップショットをとるたびに、古いアクティブ・ファイルシステムが新たなスナップショットになり、新たなアクティブ・ファイルシステムは変更点の記録を継続する。時間またはその他の基準に基づいて、所定数のスナップショットが維持される。

「スナップショット」はネットワーク・アプライアンス社の登録商標である。この特許の目的では、スナップショットは不変的整合点（ＣＰ）イメージを意味している。不変的整合点イメージ（ＰＣＰＩ）は或る時点でのストレージシステムの表現である。詳しくは、不変的整合点イメージとは、ストレージ・デバイス（例えばディスク）または他の持続性メモリに格納されたアクティブ・ファイルシステムのイメージであり、別の時点で作成された他のＰＣＰＩからそのＰＣＰＩを区別するための名前または一意の識別子を有するイメージである。ＰＣＰＩは、そのイメージを作成した時点におけるそのアクティブ・ファイルシステムに関する他の情報（メタデータ）を更に有することも出来る。この特許全体を通して、「ＰＣＰＩ」という用語と「スナップショット」という用語は、ネットワーク・アプライアンス社の商標権を失墜させることなく、同じ意味で使用される。

スナップショット・プロセスの詳細については、Ｂｌａｋｅ Ｌｅｗｉｓ他による「ＩＮＳＴＡＮＴ ＳＮＡＰＳＨＯＴ」と題する米国特許出願第０９／９３２，５７８号に記載されており、この文献は参照によって本明細書で完全に説明したものとして取り込まれる。この他に、ＷＡＦＬファイルシステムの本来のスナップショット機能の詳細については、ネットワーク・アプライアンス社から出版されているＤａｖｉｄ Ｈｉｔｚ他によるＴＲ３００２、Ｆｉｌｅ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ ｆｏｒ ａｎ ＮＦＳ Ｆｉｌｅ Ｓｅｒｖｅｒ Ａｐｐｌｉａｎｃｅ、及びＤａｖｉｄ Ｈｉｔｚ他による「ＭＥＴＨＯＤ ＦＯＲ ＭＡＩＮＴＡＩＮＩＮＧ ＣＯＮＳＩＳＴＥＮＴ ＳＴＡＴＥＳ ＯＦ Ａ ＦＩＬＥ ＳＹＳＴＥＭ ＡＮＤ ＦＯＲ ＣＲＥＡＴＩＮＧ ＵＳＥＲ−ＡＣＣＥＳＳＩＢＬＥ ＲＥＡＤ−ＯＮＬＹ ＣＯＰＩＥＳ Ａ ＦＩＬＥ ＳＹＳＴＥＭ」と題する本件と同じ譲受人の米国特許第５，８１９，２９２号に記載があり、これらの文献も参照によって本明細書に取り込まれる。

図２をもう一度参照すると、フィルシステム層２５０の上には、管理者用のユーザ・インタフェース２８５がある。このユーザインタフェースは、上で説明した様々なプロトコル（ＣＩＦＳ、ＮＦＳなど）によってアクセスすることが出来る。

また、ファイルシステム層２５０の上には、アプリケーション２９０をミラーリング（すなわち複製）している特殊な非同期ボリューム及びサブボリューム（または「ｑｔｒｅｅ」）スナップショットもある。このアプリケーションは、ソースにおけるスナップショットの変更に応じて、遠くの宛先ストレージ・ボリュームにミラーを作成する機能を持つ。スナップショット・ミラーリング・アプリケーション２９０は、ＴＣＰ／ＩＰ層２１５、２１０及びファイルシステム・スナップショット手段（２８０）に対する直接接続２９２及び２９４で示されているように、ストレージアクセス要求パス２７０の外側で動作する。このアプリケーションは、対応するサブ・ボリュームにおける変更を「非同期」でミラーリングすることが出来る。すなわち、ミラーは徐々に（かつ、ソース・サブボリュームに発生した変更に対して非リアルタイムに）宛先記憶装置に書き込まれる。宛先記憶装置は離れた場所に配置され、ネットワークによって接続される。ボリューム・サブボリューム（またはｑｔｒｅｅ）レベルでの非同期ミラーリングに関する説明は、Ｍｉｃｈａｅｌ Ｌ．Ｆｅｄｅｒｗｉｓｃｈ他による「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＤＥＴＥＲＭＩＮＩＮＧ ＣＨＡＮＧＥＳ ＩＮ ＴＷＯ ＳＮＡＰＳＨＯＴＳ ＡＮＤ ＦＯＲ ＴＲＡＮＳＭＩＴＴＩＮＧ ＣＨＡＮＧＥＳ ＴＯ Ａ ＤＥＳＴＩＮＡＴＩＯＮ ＳＮＡＰＳＨＯＴ」と題する米国特許出願第１０／１００，９６７号に記載されており、この文献は参照により取り込まれる。

同様に、ＲＡＩＤ層で動作する非同期ボリューム・スナップショット・ミラーリング・アプリケーション２９８が設けられている。このアプリケーションは、管理者から与えられたミラーコマンドに応答して、ミラー記憶装置への非同期（リアルタイムの）ミラーリングを行う。このミラーリングは、ミラーコマンドが発行された時点でソースのイメージを作成する。ボリュームを利用したスナップショットの遠隔ミラーリングの方法については、Ｓｔｅｖｅｎ Ｋｌｅｉｍａｎ他による「ＦＩＬＥ ＳＹＳＴＥＭ ＩＭＡＧＥ ＴＲＡＮＳＦＥＲ」と題する米国特許出願第０９／１２７，４９７号、及びＳｔｅｖｅｎ Ｋｌｅｉｍａｎ他による「ＦＩＬＥ ＳＹＳＴＥＭ ＩＭＡＧＥ ＴＲＡＮＳＦＥＲ ＢＥＴＷＥＥＮ ＤＩＳＳＩＭＩＬＡＲ ＦＩＬＥ ＳＹＳＴＥＭＳ」と題する米国特許出願第０９／４２６，４０９号に記載があり、これらの文献はいずれも参照により本明細書に取り込まれる。

とりわけ、ストレージ・オペレーティング・システムはＷＯＲＭユーティリティ２９９を有し、ＷＯＲＭユーティリティは通常、ファイルシステム層２５０に存在する。後で詳細を説明するように、このＷＯＲＭユーティリティは、従来のファイルシステム・ボリューム２７６とは異なる特殊なＷＯＲＭボリューム２７５をファイルシステムに作成する機能を有する。これらのボリュームはそれぞれ、対応する分化ＷＯＲＭボリューム及び非ＷＯＲＭボリューム２７７及び２７８としてＲＡＩＤ層に運ばれる。また、このユーティリティは、書き替え不可能で消去／削除不可能なＷＯＲＭファイルまたは「ＷＯＲＭデータ・コンテナ」（例えばクロックなど）のようなものをＷＯＲＭボリュームの中に作成する機能を更に有する。ユーティリティ２９９の働きにより、ＷＯＲＭファイル／データ・コンテナに対応するディレクトリ・パスウェイ（または他の論理編成の識別）はいずれも、ＷＯＲＭファイルがそのパス／ツリーに存在している限り、同様に消去が禁止される。

図示の実施形態の説明に移る前に、次のような定義をする。上に記したような「データ・コンテナ」という用語は通常、ファイル、ＬＵＮ（論理ユニット番号）、または、単独で若しくは個別にアドレス指定可能なデータ構造を意味するものとする。「ボリューム」という用語は、データ・コンテナの論理グループを意味するものとする。「ディレクトリ」という用語は、ツリーその他の論理索引構造の検索により、所与のデータ・コンテナのアクセスを容易にする編成構造を意味する。同様に、「パスウェイ」または「パス」という用語は、ストレージ・オペレーティング・システムがデータ・コンテナをアドレス指定する際に使用する経路を意味するものとする。また、本発明の教示は、種々のストレージ環境に適用することができ、また、限定はしないがファイル・データ、データベース・データ、ブロックレベルのデータなどの種々のデータ・タイプに適用することが出来る。

Ｃ． ＷＯＲＭボリュームの作成
図３を参照し、ＷＯＲＭボリュームを作成する一般的手順３００、およびその作成結果について説明する。この手順は通常、管理者が管理コンソールをインタフェースとして使用し、適当なボリューム作成コマンドを入力することにより実施される。ファイルシステムに変更を加え、ＷＯＲＭボリュームを指定する従来のボリューム（事前ＷＯＲＭ）作成コマンドに対する新たなセマンティックを認識する。ステップ３０２で、管理者はまず、複数のディスクに関するサイズのような、幾つかの一般的パラメタを有するＷＯＲＭボリュームを作成する。一実施形態において、これは下記のようなボリューム名「ｖｏｌｎａｍｅ」、「−ｗ」、及びディスク数を有するコマンドをタイプすることにより実施される。
ｖｏｌ ｃｒｅａｔｅ ＜ｖｏｌｎａｍｅ＞ −ｗ ＜ディスク数＞

次にステップ３０４で、そのボリュームに、ファイルサーバ上での要求名（ｖｏｌｎａｍｅ）を割り当てる。従って、そのボリュームは／ｖｏｌ／ｖｏｌｎａｍｅで識別される。そのボリュームに関連するディスクには、不変的記憶におけるＲＡＩＤラベルに基づいてＷＯＲＭ属性がマークされ、それらがＷＯＲＭボリュームとして識別される。このラベルの追加のためには、従来のＲＡＩＤ層構造は変更しなければならない場合がある。ＷＯＲＭは基本的にファイルシステム層になければならないが、このタグは割り当てられたディスクをＷＯＲＭ記憶装置として識別する機能を持つ。このＷＯＲＭ指定は、ＷＯＲＭディスクの不変的ラベルの不揮発性メモリに記憶される。このラベルはストレージ・オペレーティング・システムがディスクを特定のボリュームにマッピングするための、ディスクに関する識別情報を有し、各ディスクの標準位置（例えば、最初）に格納される。このようにすると、ＷＯＲＭ指定が、ＷＯＲＭファイルを格納しているディスクそれ自体に保持される。また、ＷＯＲＭ指定は、ＮＶＲＡＭや、他の不変的／バッテリ・バックアップ式のメモリ構造に格納することもでき、後で詳しく説明するように、不注意または故意によるボリュームの破壊を防止することが出来る。注意して欲しいのは、ボリューム名はＷＯＭボリューム作成プロセスの一部で割り当てられるため、ステップ３０４は、ユーザとの対話を必要としない点である。ボリューム名の割り当ては、システム内部で処理することが出来る。

次にステップ３０６で、そのボリュームをエクスポート（ＮＦＳクライアントに対し）または共有（ＣＩＦＳクライアントに対し）等することにより、外部クライアントがそのボリュームを利用出来るようにする。このエクスポート／共有ステップは、適当な使用権をクライアントに与える従来のプロセスである。ＮＦＳクライアントの例の場合、適当なコマンドの簡単な文法は下記のようなものである。
ｅｘｐｏｒｔｓ ［−ｏ オプション（複数可）］ ／ｖｏｌ／ｖｏｌｎａｍｅ
同様に、ＣＩＦＳクライアントの例の場合の文法は、
ｃｉｆｓ ｓｈａｒｅｓ −ａｄｄ ＜共有名＞ ／ｖｏｌ／ｖｏｌｕｍｅ

エクスポート及び共有は、クライアントに対する適当なアクセス制御とアクセス許可を含み、特定ユーザしかそのボリュームにアクセスできないようにすることを含む場合がある。それらは通常、そのボリュームに対して実施することが可能な機能を制限する（ＷＯＲＭとは別に）。例えば、読み出し専用ボリュームを作成し、そのボリュームに対する後の書き込みを制限することが出来る。例えばマイクロソフト社のオフィス環境と対比すると、オフィス環境では、ユーザは読み出し専用状態を取り消しまたは解除することが出来るが、いかなる状況であっても、ユーザや管理者等がＷＯＲＭ状態を取り消すことは出来ず、それによってＷＯＲＭデータの完全性を維持している。

最後にステップ３０８で、そのＷＯＲＭボリュームをオンラインにし、クライアントからアクセス出来るようにする。ＷＯＲＭ機能を実施して有効にし、制限を課す。一実施形態において、こうした制限には次のようなものがある。
１．ＷＯＲＭは、ボリューム破壊コマンドを無効にする。すなわち、ＷＯＲＭボリュームの破壊を許可しないことで、ＷＯＲＭボリュームを不変に保つ。
２．ＷＯＲＭは、スナップショットからＷＯＲＭボリュームまたはその一部を復元する従来のような復元を無効にする。すなわち、古い時点におけるイメージからの不適切な復元を防止し、その時点よりも後に収容されたファイルやＷＯＲＭファイルに対するその後の変更を無効にする。
３．ボリューム内のファイル（またはデータ・コンテナ）はいずれも、それが初期の読み出し専用以外の状態から「読み出し専用」に設定された場合、使用許可（ＮＦＳの場合、属性設定コマンド「ＳＥＴＡＴＴＲ」）（ＣＩＦＳの場合、ファイル情報設定コマンド「ＴＲＡＮＳ２＿ＳＥＴ＿ＦＩＬＥ＿ＩＮＦＯＲＭＡＴＩＯＮ」）が必要とされる。すなわち、ファイルシステム層は、自身に対応するプロトコルの中から全ての使用許可を抽出し、変化を受けたファイルに割り当てられるべきＷＯＲＭ状態を読み出し専用以外の状態から読み出し専用状態に移行させる。
４．ボリューム内のＷＯＲＭファイルの変更（例えば、書き込み、リネーム、消去、ファイル属性の変更など）は、日付スタンプ、読み出し専用状態などを変更する試みを含めて、いずれも制限される。ファイルのアクセス／変更の要求があると、ファイルシステムはその変更を許可する前に、まず、そのボリュームのＷＯＲＭ状態をチェックし、目的ファイルの個々のＷＯＲＭ状態（後で説明する）をチェックする。目的ファイルがＷＯＲＭであれば、変更は禁止され、ファイルサーバは、その変更要求を拒否する「読み出し専用」または「アクセス拒否」などの適当なファイルエラー・メッセージを返す。

具体的には、ＣＩＦＳ環境の例の場合、従来のファイル属性には、隠しファイルフラグ、読み出し専用フラグ、アーカイブ・フラグ（バックアップを実施する前、ファイルに書き込みをした後にセットされる）、タイムスタンプ作成、タイムスタンプ変更、タイムスタンプの取得、アクセス制御リスト（ＡＣＬ）、及びＮＴストリームなどがある。属性の変更によってファイルが不適切に変更される可能性がある場合、そのような変更は通常禁止される。ファイルがＷＯＲＭ記憶装置に完全に格納された後は、タイムスタンプの変更はタイムスタンプの作成に設定されることに注意して欲しい。

ＮＦＳの例の場合、変更が禁止される従来のファイル属性には、ファイルの所有者やグループなどに関するアクセス制御及びその他のパーミッションがある。ＮＦＳバージョン４は、上で説明したＣＩＦＳにおいて変更が禁止される属性に似た多数の属性を有している。

５．一実施形態において、ＷＯＲＭボリュームにおけるディレクトリの名前変更は許可されない。これは、ディレクトリ名の変更によって、ＷＯＲＭファイルが誤った場所に置かれることを防止するためである。他の実施形態において、ディレクトリの名前変更は、その結果ＷＯＲＭファイルが誤った場所に置かれることがない場合に限り許可される。ただし多くの場合、ＷＯＲＭボリュームにおいてディレクトリの名前変更を禁止するという基本ルールは、ディレクトリ名変更コマンドを入力したとき常に、ディレクトリツリー内で何らかのＷＯＲＭファイルの移動があったかどうかのチェックを省略することにより、オーバヘッドを低減し、性能を向上させる。

６．ＷＯＲＭファイルがある場合、ディレクトリの削除は許可されない。図４に概ね示すように、ＷＯＲＭファイル４０２をＷＯＲＭボリュームのディレクトリ・ツリー４００に格納すると、そのＷＯＲＭファイル４０２は変更不可になり、削除されたり変更されたりすることがなくなる。従って、そのディレクトリ４０４及びルート（並びに、パス４１０上に存在するサブ・ディレクトリ全て）が、従来のファイルシステム・セマンティックにより削除されることはなくなる。言い換えれば、少なくとも１つのファイルが未削除のまま残っていれば、それに重なるディレクトリが、事実上全ファイルシステムにおいて認められたファイルシステム・ルールに従って削除されることはない。ファイルシステムがこのルールを明示的に要求しない場合、そのファイルシステムを明示的に変更し、ＷＯＲＭファイルパスの削除を禁止しなければならない。この実施形態の場合、非ＷＯＲＭディレクトリ４１２及び４１４、並びにそれらが有しているファイル４１４及び４１８は、普通に削除することが出来る。

Ｄ．ＷＯＲＭファイルの作成
上記のようにして管理者がＷＯＲＭボリュームを作成すると、許可されたクライアントだけが、そのＷＯＲＭボリュームを利用することができる。ＷＯＲＭボリュームでは、上記のような一般的制約を受けるＷＯＲＭ以外のファイルやディレクトリに対する従来のボリューム操作（例えば、ディレクトリやファイルの作成、ファイルへの書き込み、ディレクトリやファイルの削除など）が全て可能である。また、ＷＯＲＭボリュームでは、ＷＯＲＭファイルへの書き込みが一回だけ可能であり、ＷＯＲＭファイルの読み出しまたはコピーが可能である。ＷＯＲＭファイルは、ＷＯＲＭボリューム全体の中にある特殊なファイル（またはデータ・コンテナ）である。言い換えるなら、ボリューム内の全ファイルがＷＯＲＭファイルである必要はない。ＷＯＲＭファイルは、不変に保たなければならない情報を格納または保管しなければならないクライアント・アプリケーション及びファイルサーバ・アプリケーションによって作成される。この手のアプリケーションの１つは、定期的かつ継続的に所望の電子メール記録を収集し、それらの記録をアーカイブ・ファイルに格納する電子メール・アーカイブ・プログラムであろう。

図５は、周知のウィンドウズ・オペレーティング・システム（ワシントン州レドモンドにあるマイクロソフト・コーポレーションから市販されている）を実行するクライアントの例においてファイルを作成し、そのファイルをＷＯＲＭに収容する手順５００を示している。ステップ５０２で、まずクライアントは、ＷＯＲＭファイルを格納したいＷＯＲＭボリュームに対し、ネットワーク共有を追加する。例えば、このボリュームは「ドライブＷ」という名前であるかも知れない。すると、クライアントに見せる共有ドライブのリストの中に、このドライブの名が出現する。次にステップ５０４で、標準的ウィンドウズ・コマンドを使用して、このファイルをＷＯＲＭドライブＷに保存する。最後にステップ５０６で、クライアントは「ファイル属性」ダイアログを呼び出し、ドライブＷ上のそのＷＯＲＭファイルに読み出し専用属性を設定する。ファイルサーバのファイルシステムは、読み出し専用以外から読み出し専用へのファイルの変化を認識し、それ以後、そのファイルをＷＯＲＭに指定し、上記のような属性の制約または変更、変化などを全て実施する。重要なのは、そのファイルの読み出し専用状態を変更するクライアントによるその後の試みは全て拒否され、許可されていませんというメッセージがファイルサーバからクライアントに返される点である。このように、最後のステップ５０６は、ＷＯＲＭ状態へのファイルの「収容」と呼ばれる。どのようなプロトコルの場合でも、この収容ステップは、ＷＯＲＭ特性をファイルに与えるために必要とされる。

注意すべきなのは、図示の実施形態の場合、この収容ステップが、単にＷＯＲＭボリュームにおける読み出し専用ファイルの記憶装置によって決まるのではなく、ＷＯＲＭボリューム内のファイルの読み出し専用以外の状態から読み出し専用状態への変化によって決まる点である。ファイルを読み出し専用以外の状態から読み出し専用状態に変化させないコピー・ユーティリティやその他のファイル作成アプリケーションは、ファイルをＷＯＲＭにしない場合がある。

図示の実施形態による収容プロセスでは、ファイル属性を読み出し専用以外の状態から読み出し専用状態に変化させているが、他の従来の属性の他の変化（ファイル名をＷＯＲＭファイルタイプに変更するなど）や、他の特殊な属性またはメタデータの設定を利用して収容をトリガーすることも可能である。あるいは、データやファイルを記憶装置のＷＯＲＭ指定された部分または構造に格納することを、収容のトリガーとして使用してもよい。

図６の手順６００は、ＮＦＳによりファイルサーバに接続された、周知のＵＮＩＸオペレーティング・システムを実行するクライアントの例における、ＷＯＲＭファイル作成ステップ及び収容ステップの概略を示している。まずステップ６０２で、従来のボリューム・マウント手順を使用して、ＷＯＲＭボリュームをマウントする。これには例えば、「ｍｏｕｎｔ ｆｉｌｅｒ：／ｖｏｌ／ｖｏｌｎａｍｅ ／ｗｏｒｍ」というコマンドが使用される。次に、例えばＷＯＲＭ格納したい読み出し専用以外のファイルｆｉｌｅ．ｔｘｔがあった場合、そのファイルをコピーし（ステップ６０４）する。一般的なコマンドライン・シェル・コマンドは下記のようなものである。
ｃｐ ｆｉｌｅ．ｔｘｔ ／ｗｏｒｍ
このコマンドにより、そのファイルは指定されたＷＯＲＭファイルとしてそのボリュームにコピーされる。ファイルがコピーされた後、次にステップ６０６に従って、そのファイルをＷＯＲＭに収容しなければならない。これは、全ての所有者、グループ、及びユーザから書き込み権限を全て取り除き、そのファイルを読み出し専用以外の状態から読み出し専用状態、すなわちＷＯＲＭに変化させることにより行われる。書き込み権限を取り除くコマンドは例えば次のようなものである。
ｃｈｍｏｄ −ｗ ／ｗｏｒｍ／ｆｉｌｅ．ｔｘｔ
従来のＤＯＳシェルの場合、この収容は単に次のように表現される。
ＡＴＴＲＩＢ ＋Ｒ ＜ファイル名＞

具体的には、上記のようなコマンドライン表現はそれぞれ、クライアントにおける対話型セッションに使用される。すなわち、クライアント・ユーザは、コマンドを物理的に入力し、ファイルサーバからの適当な応答を待つ。こうした作成及び収容プロセスは、プログラム・アプリケーションの内部で実行することも可能である。周知のオペレーティング・システム（ウィンドウズやＵＮＩＸなど）は、アプリケーションベースの収容機能や属性変更機能を有している。ＷＯＲＭを実施するためには、下記のようなファンクション・コールをアプリケーション・プログラムに内蔵させることが望ましい。完全なＷＯＲＭ機能を実施するためには、アプリケーションに対して他にも変更を施し（アプリケーションのグラフィカル・ユーザ・インタフェースに変更を加えるなど）、ＷＯＲＭの存在を認識できるようにしなければならない場合があることに注意して欲しい。また、ＷＯＲＭボリュームは、ＷＯＲＭボリュームの特別な性質と変更されたセマンティックを認識し、それを使用することが可能なアプリケーションでしか使用されないものと考えられる。例えば下記は、ＷＯＲＭに収容（例えば、「読み出し専用」に設定）するための、ウィンドウズ系Ｃ＋＋（Ｗｉｎ３２）アプリケーション・プログラム・インタフェース・ファンクション・コールである。
ＳｅｔＦｉｌｅＡｔｔｒｉｂｕｔｅｓ（＜ファイル＞，ＦＩＬＥ＿ＡＴＲＲＩＢＵＴＥ＿ＲＥＡＤＯＮＬＹ）
同様に、ＵＮＩＸ系システムの場合、アプリケーション・ファンクション・コールは次のようなものである。
ｆｃｈｍｏｄ（＜ファイル＞，０４４４）

上記の説明から明らかなように、この実施形態によるＷＯＲＭボリュームの作成およびＷＯＲＭファイルの格納は、オープン・プロトコル（ＣＩＦＳ、ＮＦＳなど）に対する変更が最小限で済み、同様に、ＷＯＲＭ機能を使用するアプリケーションに対する変更も最小限で済む。その理由は、新たな機能の大半がファイルシステム層に含まれ、ファイルシステム層は、ファイルシステム層の中にＷＯＲＭを実現するためのボリューム作成コマンドの単純な変更や、既存のファイル属性変化（すなわち、読み出し専用以外から読み出し専用への変化）を認識するように構成されているからである。また、ファイルシステム層は、種々のオープン・プロトコルとはほとんど無関係に、情報を均一なＷＯＲＭ特性でストレージ層に渡すため、ストーレージ・オペレーティング・システム内のストレージ層や他の層に施さなければならない変更は最小限で済む。

代替実施形態によれば、オープン・プロトコルに自動収容機能を組み込むことも可能である。ＣＩＦＳの処理状態を把握する性質によれば、作成したＷＯＲＭファイルを閉じるときにＷＯＲＭに対する収容を実施する手順を実施することが出来る。すなわち、このプロトコルは、ＷＯＲＭ作成ダイアログを認識し、そのファイルが閉じられたときに、収容（例えば、読み出し専用以外から読み出し専用属性への変更）を開始する。これは、ＮＦＳのように処理状態を把握しないプロトコルにおいて、わりと試みられている。しかしながら、ＮＦＳバージョン４は、多数の状態把握処理をサポートしているので、ＣＩＦＳのような自動収容のための出来合いのプラットフォームを提供しない場合がある。他のプロトコルを更に使用して、ファイルを閉じたときの自動収容機能を提供することも出来る。

更に他の実施形態では、オープン・プロトコルに更に変更を加え、ＷＯＲＭディレクトリを可能にする場合がある。一実施形態では、ＷＯＲＭファイルだけがＷＯＲＭディレクトリへのアクセス権を有する場合がある。この目的のために、ファイル拡張子「．ｗｏｒｍ」を与え、ＷＯＲＭ収容された全ファイルをユーザが見れるようにする。一回のトランザクションでディレクトリ全体を自動的に収容する利点は、一部のファイルが収容された後、残りのファイルが収容される前にクラッシュその他の中断が起きることにより発生する問題を抑えることが出来る点にある。このような部分的収容は、残りのファイルが最終的に収容されたときに、不整合問題を引き起こすことがある。

また、管理者は、シンプル・ネットワーク・マネージメント・プロトコル（ＳＮＭＰ）を使用して、ボリューム作成、ボリューム破壊（許可されていれば）、ＷＯＲＭファイル書き込み等のＷＯＲＭボリューム行為を検出し、ログに記録することも出来る。ファイラはログファイルまたは管理ファイルを有することができ、ＳＮＭＰは、トラップを使用して、こうした行為を検出することが出来る。このようにすると、全てのＷＯＲＭ行為のログを管理することができ、例えば法的処置または内部セキュリティの目的で、データ完全性、並びにデータアクセスの管理や監査をさらに容易にすることが出来る。

Ｅ． ミラーリングと複製の考察
上で簡単に説明したように、特定のスナップショット復元機能は無効にしなければならない。背景として、図７は、同期ミラーリング手順７００の詳細を示している。同期ミラーリング手順では、ＷＯＲＭボリュームデータ７０２がソースＷＯＲＭボリューム７０４で作成・格納されたときに、そのＷＯＲＭボリュームデータ７０２がリアルタイムに宛先ボリューム７０６に転送される。この転送は通常、ソースから宛先への高速でリアルタイムなデータ転送が可能なトランスポート・プロトコル（ファイバチャネルやｉＳＣＳＩなど）を使用して行われる。ミラーとは基本的に、ソースと同時に満たされるもう１つのディスク・アレイである。従って、ソース・ボリュームに何を入れても、それはミラー宛先ボリュームにも入れられる。ストレージ（ＲＡＩＤ）層は大量のミラー機能を処理するので、ソース上の上位ファイルシステムからの介入が幾らか必要となる。

宛先ボリュームを使用する前には、まず、そのボリュームを宛先ストレージ・システム上に作成する。宛先ボリュームの作成は、管理者が適当なボリューム作成コマンドを使用することにより行われる。通常、宛先ボリュームは、バックアップ・ストレージ・システムを必要とするＷＯＲＭボリュームとして作成され、その上に、ＷＯＲＭ機能を有するファイルシステムを含む宛先ボリュームが置かれる。ＷＯＲＭミラー・ボリュームを使用することにより、格納されたデータの完全性は更に保護され、その完全性が、安全なバックアップ記憶装置の一般的要件に準拠する。ＷＯＲＭ以外のボリュームを作成することも可能であり、また、それが望ましい場合もあるが、そのようなボリュームは安全なバックアップ記憶装置のルールに違反することがある。

宛先ボリュームはＷＯＲＭボリュームであるから、ミラーリング・プロセスにおける中断はいずれも、取り返しがつかない。中断が起きると、システムは全ての格納レコードの転送、すなわち、新たに作成された宛先ボリュームに対するレベル０の転送を含む、ミラーの再初期化を行わなければならない。

本明細書に記載される他のミラー・プロセスと同様に、ソースのＷＯＲＭ性は、災害が起きたときの宛先からのソースの復元（例えば、復元プロセス）にとって制限となる場合がある。ソースＷＯＲＭボリュームにおけるＷＯＲＭファイルは、定義によれば、書き替え不可能であるため、ソース・ボリュームを修復する好ましい手順は、そのソース・ボリュームをミラーリングされた宛先ボリュームで置き換えることである。宛先ボリュームを使用したソース・ボリュームの部分的復元は禁止される場合がある。しかしながら、これは一般に、同期ミラーリング法における最小の欠点でしかない。なぜなら、宛先はソースの最も新しいバージョンを常に保持していて、必要であればその全部をソースと簡単に交換することが出来るからである。

図８は、非同期ミラーリング手順８００を示す簡略図である。この方法の詳細については、上で取り込まれたＭｉｃｈａｅｌ Ｌ．Ｆｅｄｅｒｗｉｓｃｈ他による「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＤＥＴＥＲＭＩＮＩＮＧ ＣＨＡＮＧＥＳ ＩＮ ＴＷＯ ＳＮＡＰＳＨＯＴＳ ＡＮＤ ＦＯＲ ＴＲＡＮＳＭＩＴＴＩＮＧ ＣＨＡＮＧＥＳ ＴＯ Ａ ＤＥＳＴＩＮＡＴＩＯＮ ＳＮＡＰＳＨＯＴ」と題する米国特許出願第１０／１００，９６７号に記載されており、この文献を下記の説明とあわせて参照すべきである。

ソース・ボリューム８０２のファイルシステムは、ソース・ボリューム・データ構造または特定サブボリュームのデータ構造（ｑｔｒｅｅの場合）の時間的に分離された或る時点でのイメージ、すなわち「スナップショット」（図２に２８０で示す）を生成するように構成される。こうしたサブボリュームの１つは、後で説明するようなＷＯＲＭディレクトリ構造であってもよい（例えば「ＷＯＲＭ」拡張）。これらのスナップショットを非同期スナップショット・ミラーリング・アプリケーションでスキャンすることで、様々な時点で作成されたスナップショット間に現れる差異に基づいてファイルの変化を検出することができる。宛先８０４に適当なＷＯＲＭボリュームを作成した後、それらの変化を従来の（通常は低速の）ネットワーク接続８１０（周知のインターネットなど）を介して成形済みデータストリーム８０６に送信する。接続が低速であるため、これらの変化は通常、リアルタイムには変化せず、一定時間間隔で「非同期に」または遅延書き込み方式で宛先に書き込まれる。

ソースＷＯＲＭボリューム８０２から宛先ＷＯＲＭボリュームへの非同期のデータ転送を容易にするために、データは、一連のメタデータ（一実施形態においてｉｎｏｄｅの形をとる）及び関連ファイルデータに成形される。このデータを宛先ファイルシステムにとって意味のあるものにするために、データは認識可能なヘッダを使用して成形される。このヘッダは、データ転送を種々の部分に分離するとともに、どのタイプのデータ転送が行われるを伝えるためのものである。さらに、削除ファイルのリストなどの情報を含む幾つかの特定のヘッダが単独で設けられる。図９は、上記のＦｅｄｅｒｗｉｓｃｈ他による特許出願に詳細が記載されているヘッダを簡略化したものである。このヘッダは、１ＫＢの汎用部９０２、２ＫＢの非汎用部９０４、及び１ＫＢの拡張部を有する。汎用部９０２には、ＷＯＲＭボリューム転送フラグ９０８が付加されている。このフラグは、その後に続くデータストリームでＷＯＲＭボリューム情報が転送されることを宛先ファイルシステムに伝えるためのものである。このフラグはヘッダの「共通」部に配置され、オープン・プロトコルによって認識される。

図１０に示すように、データストリーム中の各データファイル１０００は同様に、ＷＯＲＭフラグビット１００２を有する。このビットはヘッダ情報と一緒に使用され、ｉｎｏｄｅまたはメタデータが指し示すファイル（または他のデータ・コンテナ）に関する適当なＷＯＲＭ状態情報を有する宛先ＷＯＲＭボリュームに、新たなｉｎｏｄｅを再構築するのに使用される。宛先ファイルシステムのミラーリング・アプリケーションは、エンコードされたフラグを適切に解釈するように構成される。ｉｎｏｄｅを宛先ボリュームに作成する手順の詳細については、上で参照した特許出願に記載されている。

さらに他の実施形態として、従来の暗号化技術、及び／又は、認証技術、あるいは他のセキュリティ拡張手段を使用し、ソース・ファイルサーバと宛先ファイルサーバの間のセキュリティを向上させることも可能である。このような実施形態では、通常なら望ましくないと考えられる特定の復元機能を安全に使用できる場合がある。

上に記載したのは、本発明の実施例に関する詳細な説明である。本発明の思想と範囲を外れることなく、様々な変形及び追加を行うことが可能である。同様に、サーバまたはそれに対応するストレージ・アレイの内部構造、並びに、そのネットワーク接続やプロトコルも全て、大きく変形可能である。種々のソースサーバや宛先サーバで使用されるオペレーティング・システムは異なるものであってもよい。また、本明細書に記載した処理及び手順はいずれも、ハードウェアで実施してもよいし、コンピュータ上で実行されるプログラム命令を有するコンピュータ読取可能媒体を含むソフトウェアで実施してもよいし、あるいは、ハードウェアとソフトウェアの組み合わせで実施してもよい。

ファイルサーバと関連クライアントを含む例示的ネットワーク・ファイルサーバ環境を規定する略ブロック図であり、この環境で本発明の原理が実施される。 本発明の一実施形態によるストレージ・オペレーティング・システムの例を示す略ブロック図である。 本発明の一実施形態によるＷＯＲＭボリューム作成手順を示すフロー図である。 ＷＯＲＭファイル・パスウェイの例を示すディレクトリ・ツリーの略ブロック図である。 本発明の一実施形態による、ウィンドウズ・クライアント用のＷＯＲＭファイル作成・格納手順を示すフロー図である。 本発明の一実施形態による、ＵＮＩＸクライアント用のＷＯＲＭファイル作成・格納手順を示すフロー図である。 本発明の一実施形態による同期ミラーリング手順を示す略ブロック図である。 本発明の一実施形態による非同期ミラーリング手順を示す略ブロック図である。 図８の非同期ミラーリング手順で使用されるデータ・フォーマットに関する一般的ヘッダを示す概略図である。 図９の非同期ミラーリング手順に従って転送されるデータ・ファイルのＷＯＲＭフラグを示す概略図である。

Claims (39)

1. ファイルシステムを有する一回書き込み複数回読み出し式（ＷＯＲＭ）ストレージ・システムを実施する方法であって、
   ＷＯＲＭボリューム作成コマンドを発行し、一連のディスク中に指定されたＷＯＲＭボリュームを作成するステップと、
   ＷＯＲＭファイルを作成し、ＷＯＲＭファイルを該ＷＯＲＭボリュームに保存するステップと、
   ＷＯＲＭファイル属性を変更し、前記ＷＯＲＭファイルを読み出し専用以外の状態から読み出し専用状態に変更することにより、該ＷＯＲＭファイルを前記ＷＯＲＭボリュームに収容し、該読み出し専用ファイル属性が、前記ファイルシステムによって前記ＷＯＲＭボリュームにおけるＷＯＲＭファイルの指定として認識されるようにするステップと
   からなる方法。
2. 前記ファイルシステムは、前記ＷＯＲＭボリュームにおけるＷＯＲＭファイルを含むディレクトリパスの名前変更を防止するように構成される、請求項１に記載の方法。
3. 前記収容するステップは、前記ファイルサーバに相互接続されたクライアント上のアプリケーションによって実施される、請求項１に記載の方法。
4. 前記発行するステップは、前記作成するステップの前に管理者によって実施される、請求項１に記載の方法。
5. ＷＯＲＭボリュームをミラー宛先に作成し、作成したＷＯＲＭファイルを宛先ＷＯＲＭボリュームへ送信し、収容するステップを更に含む、請求項１に記載の方法。
6. 前記送信するステップは、前記ＷＯＲＭファイルを含むイメージの２つの時点間の変化をデータ・フォーマットを使用してネットワークを介して送信することを含む、請求項５に記載の方法。
7. ファイルシステムを有する一回書き込み複数回読み出し（ＷＯＲＭ）式ストレージ・システムであって、
   ファイルを指定されたボリュームに収容した後、前記ファイルシステムに与えられたオープン・プロトコル・ファイル属性に基づいて、該ファイルを指定されたボリュームに収容するためのＷＯＲＭユーティリティを前記ファイルシステム上に有する、ＷＯＲＭストレージ・システム。
8. 前記オープン・プロトコル・ファイル属性は読み出し専用ファイル属性を含む、請求項７に記載のＷＯＲＭストレージ・システム。
9. 前記オープン・プロトコルは、ファイルを閉じたときに前記読み出し専用属性を前記ファイルシステムに自動的に提供するように構成される、請求項８に記載のＷＯＲＭストレージ・システム。
10. 前記ファイルシステムは、前記ファイルを有するディレクトリの削除を防止するように構成される、請求項７に記載のＷＯＲＭストレージ・システム。
11. ＷＯＲＭボリューム作成コマンドを発行し、一連のディスク中に指定されたＷＯＲＭボリュームを作成するステップと、
    ＷＯＲＭファイルを作成し、該ＷＯＲＭファイルを前記ＷＯＲＭボリュームに保存するステップと、
    ＷＯＲＭファイル属性を変更し、前記ＷＯＲＭファイルを読み出し専用以外の状態から読み出し専用状態に変更することにより、該ＷＯＲＭファイルを前記ＷＯＲＭボリュームに収容し、該属性変更が、前記ファイルシステムによって前記ＷＯＲＭボリュームにおけるＷＯＲＭファイルの指定として認識されるようにするステップと
    を実施するプログラム命令を含むファイルシステムを有する一回書き込み複数回読み出し（ＷＯＲＭ）式ストレージ・システムを実施するためのコンピュータ読取可能媒体。
12. 前記ファイルシステムは、前記ＷＯＲＭボリュームにおけるＷＯＲＭファイルを含むディレクトリパスの名前変更を防止するように構成される、請求項１１に記載のコンピュータ読取可能媒体。
13. 前記収容するステップは、前記ファイルサーバに相互接続されたクライアント上のアプリケーションによって実施される、請求項１１に記載のコンピュータ読取可能媒体。
14. 前記発行するステップは、前記作成するステップの前に管理者によって実施される、請求項１１に記載のコンピュータ読取可能媒体。
15. ＷＯＲＭボリュームをミラー宛先に作成し、作成したＷＯＲＭファイルを宛先ＷＯＲＭボリュームへ送信し、格納するステップを更に含む、請求項１１に記載のコンピュータ読取可能媒体。
16. 前記送信するステップは、前記ＷＯＲＭファイルを含むイメージの２つの時点間の変化をデータ・フォーマットを使用してネットワークを介して送信することを含む、請求項１５に記載のコンピュータ読取可能媒体。
17. ストレージ・ボリュームとして編成され、一回書き込み複数回読み出し（ＷＯＲＭ）機能を有するストレージ・システムであって、
    ＷＯＲＭストレージ・ボリュームを作成し、書き替えも削除も出来ないＷＯＲＭデータ・コンテナと、書き替え及び削除が可能な非ＷＯＲＭデータ・コンテナとの両方を有する前記ＷＯＲＭストレージ・ボリュームにおける組織構造中のデータ・コンテナを管理する、ストレージ・オペレーティングシステムを含む、ストレージ・システム。
18. 前記ＷＯＲＭデータ・コンテナのそれぞれをＷＯＲＭ関連を有する前記組織構造の所定の部分に送信することにより、該ＷＯＲＭデータ・コンテナのそれぞれをＷＯＲＭストレージに収容するＷＯＲＭユーティリティを更に含む、請求項１７に記載のストレージ・システム。
19. 前記データ・コンテナはファイルであり、前記所定の部分はＷＯＲＭディレクトリである、請求項１８に記載のストレージ・システム。
20. オープン・プロトコル属性の入力に基づいてデータ・コンテナをＷＯＲＭストレージに収容するＷＯＲＭユーティリティを更に含む、請求項１７に記載のストレージ・システム。
21. 前記オープン・プロトコル属性は読み出し専用属性からなる、請求項２０に記載のストレージ・システム。
22. 前記オープン・プロトコルは、前記データ・コンテナを閉じたときに前記読み出し専用属性を自動的に提供するように構成される、請求項２１に記載のストレージ・システム。
23. 前記ストレージ・オペレーティング・システムは、前記データ・コンテナを含む組織構造の削除を防止するように構成される、請求項１７に記載のストレージ・システム。
24. 前記ストレージ・オペレーティング・システムは、ファイルシステム、ファイルからなるデータ・コンテナ、及び、ディレクトリ・ツリー構造からなる組織構造を含む、請求項１７に記載のストレージ・システム。
25. 一回書き込み複数回読み出し（ＷＯＲＭ）式ストレージ・システムを実施する方法であって、
    ＷＯＲＭボリューム作成コマンドを発行し、一連のディスク中に指定されたＷＯＲＭボリュームを作成するステップであって、該ＷＯＲＭボリュームが組織構造に基づいてデータ・コンテナを収容するものである、ＷＯＲＭボリュームを作成するステップと、
    ＷＯＲＭデータ・コンテナを作成し、ＷＯＲＭデータを前記ＷＯＲＭボリュームに保存するステップと、
    データ・コンテナ属性を変更し、前記データ・コンテナを第１の状態から第２の状態に変更するステップであって、前記属性が前記ＷＯＲＭボリュームにおけるＷＯＲＭファイルの指定として認識されることを含む、データ・コンテナ属性を変更するステップと
    からなる方法。
26. 前記第１の状態が、読み出し専用以外の状態であり、前記第２の状態が、読み出し専用状態である、請求項２５に記載の方法。
27. 前記ＷＯＲＭボリュームにおけるＷＯＲＭデータを含む前記組織構造の一部の識別の変更を防止するステップを更に含む、請求項２５に記載の方法。
28. 前記収容するステップは、前記ストレージ・システムと通信するクライアント上のアプリケーションによって実施される、請求項２７に記載の方法。
29. 前記発行するステップは、前記作成するステップの前に管理者によって実施される、請求項２８に記載の方法。
30. ＷＯＲＭボリュームをミラー宛先に作成し、作成したＷＯＲＭデータ・コンテナを前記宛先ＷＯＲＭボリュームに送信し、収容するステップを更に含む、請求項２５に記載の方法。
31. 前記送信するステップは、前記ＷＯＲＭデータ・コンテナを含むイメージの２つの時点間の変化をデータ・フォーマットを使用してネットワークを介して送信することを含む、請求項３０に記載の方法。
32. 前記データ・コンテナはファイルであり、前記組織構造はディレクトリ・ツリー構造であり、前記データコンテナ属性はファイル属性である、請求項２５に記載の方法。
33. 前記ＷＯＲＭボリュームの作成に応じて、該ＷＯＲＭボリュームの或る古い時点におけるイメージまたはその一部を利用した、古い時点におけるＷＯＲＭボリュームの再構築を無効にすることを更に含む、請求項２５に記載の方法。
34. 前記或る古い時点でのイメージは、前記ＷＯＲＭボリュームのミラー若しくはスナップショット、又はその一部からなる、請求項３３に記載の方法。
35. 一回書き込み複数回読み出し（ＷＯＲＭ）式ストレージ・システムを実施する方法であって、
    ＷＯＲＭボリューム作成コマンドを発行し、一連のディスク中に指定されたＷＯＲＭボリュームを作成するステップであって、該ＷＯＲＭボリュームが組織構造に基づいてデータ・コンテナを格納するものである、ＷＯＲＭボリューム作成コマンドを発行するステップと、
    ＷＯＲＭデータ・コンテナを作成し、ＷＯＲＭデータを該ＷＯＲＭボリュームに保存するステップと、
    前記ＷＯＲＭデータ・コンテナのそれぞれをＷＯＲＭ関連を有する前記組織構造の所定の部分に送信して格納することにより、前記ＷＯＲＭデータ・コンテナを前記ＷＯＲＭボリュームに収容するステップと
    からなる方法。
36. 前記データ・コンテナはファイルであり、前記所定の部分はＷＯＲＭディレクトリである、請求項３５に記載の方法。
37. 一回書き込み複数回読み出し機能を有するストレージ・システムであって、
    媒体アレイ上のデータ記憶を管理するストレージ・オペレーティング・システムであって、
    Ａ）書き替えも削除も出来ないＷＯＲＭデータ・コンテナを有するＷＯＲＭストレージ・ボリューム内においてデータ・コンテナを組織構造で管理するためのＷＯＲＭストレージ・ボリュームと、
    Ｂ）書き替え及び削除が可能なデータ・コンテナを有するＷＯＲＭストレージ・ボリューム内においてデータ・コンテナを組織構造で管理するための非ＷＯＲＭストレージ・ボリュームとの両方を作成して有するストレージ・オペレーティング・システムを含む、ストレージ・システム。
38. 前記媒体アレイは、ディスクドライブのアレイである、請求項３７に記載のストレージ・システム。
39. 前記データ・コンテナはファイルであり、前記組織構造はディレクトリ・ツリー構造であり、前記ＷＯＲＭボリュームにおける前記ディレクトリ・ツリー構造の名前変更は禁止されている、請求項３８に記載のストレージ・システム。

Images