JP2005512171A - 大きいファイルの効率的な管理 - Google Patents

Abstract

【課題】
【解決手段】 オブジェクト管理システムであって、オブジェクト（７２）を格納するよう構成されたコンピュータシステムを備えており、オブジェクト（７２）は、ファイルであってよい。そのコンピュータシステムは、オブジェクト（７２）を複数のパーティション（７０）に分割し、各パーティションを選択して、選択されたパーティションを、格納用にストレージデバイス（１４）に提供するよう構成されている。パーティションの選択は、パーティションが変更されたか否かに基づいて、ストレージデバイスに移動する必要のあるパーティションを決定することにより実行される。システムは、オブジェクトに関連付けられたデータオブジェクトを調べることにより、この決定を行う。コンピュータシステムは、選択されたパーティションをストレージデバイスから読み出すよう構成されてもよい。

Description

本発明は、一般に、オブジェクト管理システムにおいて大きいファイルを効率的に管理するための方法、製品、および装置に関する。より詳細には、本発明は、速度、コスト、サイズ、利用可能性、アクセス可能性、および遠隔性などの様々な特徴を有するストレージを様々な組み合わせで備えることができるオブジェクト管理システムにおいて、大きいファイルの効率的な格納および読み出しを行う技術に関する。

本発明は、オブジェクト管理システムにおける大きいファイルの管理に関する。Ｏｒａｃｌｅ（商標）データベースと共に用いられるような既存のシステムは、極めて大きいテーブルスペースを扱うよう設計されている。表領域（テーブルスペース）は、複数のデータファイルから成り立っていてよく、それら複数のデータファイルは、オペレーティングシステムによってアクセスおよび操作可能なファイルである。「データファイル」とは、データがストレージ媒体に連続的な形で物理的に格納されているか否かに関係なく、連続的な情報として、コピー、移動、または、その他の処理を実行できるファイルのことを意味する。

ローカルストレージの容量は、１以上のデータベースに関連付けられた表領域全体を格納するのに十分でないことがある。データベース全体を格納するのに十分な容量を準備するために、十分な高速アクセスストレージ（ハードディスクまたは光媒体など）を購入することは、特に、すべてのデータに対して比較的高速なアクセスが必要なわけではない場合には、不経済である。従来のデータベースシステムでは、比較的安価な媒体にデータを「移動」し、必要な時にだけ媒体から読み出すことが行なわれている。しかしながら、既存のシステムおよび方法は、移動すべきデータ、移動後のデータ、および読み出し後のデータを効率的に管理していない。これらのシステムでは、待ち時間が長く、データ転送速度の要求が高く、長いバックアップ時間が必要であり、コストが高く、ある時刻の記録を作成することができない。

これらの問題は、データベースや表領域に限られたことではない。むしろ、マルチメディアのような大きいファイルを格納するシステムで起こりうる問題である。

本明細書で開示するように、より効率的な方法を用いると、待ち時間、帯域幅の要求、およびコストが低減され、必要なバックアップウィンドウが小さくなるため、より効率的にデータを管理することができる。本明細書の開示では、データベースおよび表領域に関して、問題および発明の説明を行っているが、本発明は、移動を用いる任意のデータ管理システム、特に、システムが、音声や映像などの大きいデータファイルを管理する場合、に適用可能である。

したがって、簡潔に述べると、本発明は、オブジェクト管理システムにおいて大きいファイルを効率的に管理するための方法、製品、および装置を提供する。本発明の一実施形態では、オブジェクト管理システムは、オブジェクトを格納するよう構成されたコンピュータシステムを備えており、オブジェクトは、ファイルであってよい。そのコンピュータシステムは、オブジェクトを複数の区画（以下、この明細書ではパーティションと言う）に分割し、パーティションを選択して、選択されたパーティションを格納のためのストレージデバイスに提供するよう構成されている。

パーティションの選択は、パーティションが変更されたか否かに基づいて、ストレージデバイスに移動する必要のあるパーティションを決定することによって実行される。システムは、オブジェクトに関連付けられたデータオブジェクトを調べることにより、この決定を行う。

コンピュータシステムは、選択されたパーティションをストレージデバイスから読み出すよう構成されてもよい。システムは、データアクセス要求を受信し、そのデータアクセス要求を用いてパーティションを選択し、データオブジェクトを用いて、選択されたパーティションがコンピュータシステムに存在するか否かを決定し、選択されたパーティションがコンピュータシステムに存在しない場合には、選択されたパーティションをストレージデバイスから読み出す。

本発明の利点および詳細は、添付の図面と併せて行う以下の詳細な説明により、当業者にとって明らかとなる。

以下では、一実施形態の詳細な説明を行う。本発明は、本実施形態を用いて説明されているが、本発明は、どの実施形態にも限定されないことを理解されたい。逆に、本発明の範囲は、添付の請求項によってのみ限定されるものであり、本発明は、数々の代替物、変形物、および均等物を含む。以下の説明では、本発明の十分な理解を促すために、数多くの具体的な詳細を例示の目的で記載している。本発明は、これら具体的な詳細の一部または全部がなくとも、請求項に従って実施することができる。説明を明確にするために、本発明に関連する技術分野において周知の技術事項については、本発明が不必要に不明瞭となることを避けるため詳細には説明していない。

本発明は、処理、装置、システム、デバイス、方法、コンピュータ読み取り可能なストレージ媒体のようなコンピュータ読み取り可能な媒体、および、光学または電子通信回線を介してプログラム命令が送信されるコンピュータネットワークなど、数々の方法で実施可能であることを理解されたい。

概要
一実施形態では、図１に示すように、オブジェクト管理システム１０は、第１の（すなわち、ローカル）コンピュータシステム１２と、ストレージシステム１４とを備えており、ストレージシステム１４は、第２の（すなわち、リモート）コンピュータシステムであってよい。第１のコンピュータシステム１２は、フロントエンド１２と呼んでもよく、ユーザ（図示せず）に主要なアプリケーションとデータ格納サービスとを提供する。通常の動作時には、第１のコンピュータシステム１２は、ＣＰＵ２０によってアプリケーションを実行し、ローカルファイルシステム１６によってローカルデータへのアクセスを可能としている。ローカルファイルシステム１６は、一般に、ハードディスクドライブ１８のような高速のデバイスを、単独またはＲＡＩＤ配列などの構成で備えている。ストレージシステム１４は、バックエンド１４とも呼ばれ、ファイルシステム２６内に構成可能な様々な大容量ストレージデバイスに接続された汎用のＣＰＵ２２であってもよいし、専門のストレージ装置であってもよい。バックエンド１４で用いられる大容量ストレージデバイスは、ハードディスクドライブ２４であってもよいし、比較的安いデバイス、低速のデバイス、または保管を目的としたデバイスなど、他のデバイスであってもよい。例えば、光学ディスク２８、テープドライブ３０、光磁気ドライブが用いられてよい。バックエンド１４は、ほとんどアクセスされないデータの安価なニアラインストレージとして用いられてもよいし、フロントエンド１２のデータをバックアップするために用いられてもよい。

バックエンド１４は、フロントエンド１２と同じ場所に配置されてもよいし、リモートに配置されてもよい。データの転送は、ＮＦＳ、ＡＦＳ、ＦＴＰ、またはその他の方法によって実現される。フロントエンド１２とバックエンド１４は、１対１、多対１、または多対多の関係で接続可能である。フロントエンド１２上のファイルシステム１６は、一般に、バックエンド１４と１対１の関係であるが、異なるバックエンド１４にそれぞれ対応するいくつかのファイルシステム１６が、フロントエンド１２上に存在してもよい。この構成は、例えば、各ファイルシステム１６が、１つの会社内の異なるグループに属する様々なアプリケーションのために用いられる場合に利用可能である。したがって、経理部のデータが、あるバックエンド１４のシステムに転送され、給料課のデータが、他のバックエンド１４に転送されてもよい。これらのバックエンドシステム１４は、異なるリモートな位置に配置されてよい。

動作中、移動デーモンは、フロントエンド１２からバックエンド１４にデータを移動（コピー）、すなわち、フロントエンド１２からバックエンド１４にデータをコピーする。データは、パーティションに分割されて、バックエンド１４に書き込まれる。ファイルの移動が済むと、そのファイルは、フロントエンド１２において移動済みとしてマークされる。これは、ファイルが移動済みであることを示すビットまたはその他のフラグを設定することにより実行される。消去デーモンは、フロントエンド１２において不必要となったデータを有する移動済みファイルを探して、不必要なデータを消去する。イベントデーモンは、データアクセスイベントをトラップし、データがフロントエンド１２において必要とされる場合には、バックエンド１４からフロントエンド１２にデータを再現する。イベントデーモンは、必要とされるファイルの部分を移動するよう構成されており、そのため、ファイルの一部のみが再現されてもよい。これにより、転送されるデータの量を低減して、帯域幅の要求および待ち時間を低減できるという利点がある。

定期的に、移動デーモンは、移動を必要とするファイル（または、ファイルの一部）の有無を調べる。移動デーモンは、ダーティとしてマークされた（すなわち、バックエンド１４への最後の移動の後に書き込みされた）再現ファイルを見つけた場合、そのファイルをバックエンド１４に移動する。移動デーモンは、変更されたパーティションのみを書き込むよう構成されている。変更されていないパーティションを書き込む必要がないため、転送されるデータの量が低減される。バックエンド１４において、変更されたパーティションは、バージョニングされ、大容量ストレージデバイスに書き込まれる。それらのパーティションは、既存のパーティションに上書きされてもよいが、以前のバージョンを保持するようにすれば、その時点の記録（ポイントインタイム・スナップショット）の作成が可能となり、任意の時点のシステムの状態を保持できるようになる。パーティションおよびその他のメタデータの位置に関する情報は、コンテナファイルに書き込まれる。なお、コンテナファイルは、バックエンド１４内の高速ストレージに配置されてよい。この構成では、システムの動作によってバックアップが作成され、コンテナファイルが、フロントエンド１２へのデータの復元に必要な情報すべてを収納しているため、別個のバックアップは必要ない。

これらの動作は、パーティションのサイズや他の構成および環境の情報を設定する作業を除いて、アプリケーションのユーザに特別な干渉をすることなく透過的に実行される。

かかるシステムは、すべてのデータをコピーすることなく、あるコンピュータシステムのデータを他のコンピュータシステムが利用できるようにするために用いてよい。これを実現するために、第２のコンピュータシステムは、バックエンド１４に存在する第１のコンピュータのコンテナファイルを用いて、自分用のファイルをローカルファイルシステム上に作成するよう構成される。第２のコンピュータシステムは、自分のデータをバックエンド１４に書き込む場合には、セットアップ時または必要とされた時に、自分用のコンテナファイルを作成する。第２のコンピュータの動作中に、データアクセスを行うと、必要なファイルのパーティションがフロントエンド１２に存在しない場合には、バックエンド１４から再現されることになる。いずれかのコンピュータがデータを変更すると、そのコンピュータは、データを移動する際に、自分のパーティションをバックエンド１４に書き込み、自分のコンテナファイルを更新する。したがって、各コンピュータシステムは、自分用のバージョンのファイルを有する。

システムは、さらに、ファイル名、ｉノード番号、および拡張属性を１つのファイルに格納することにより、移動および消去の候補を効率よく検索するよう構成されてもよい。システムは、このファイルを検索することにより、ネームスペース内のすべてのファイルのｉノードおよび拡張ブロックを調べることなく、移動または消去の候補を迅速に特定することができる。パス名を決定するためには、ｉノード番号を用いる逆検索が用いられる。この方法によれば、システムは、移動および消去の候補に対するｉノードのみを検索ことができるので、所要時間が短縮される。

このシステムは、データベースによって用いられる大きい表領域を管理するために用いられてよいが、特に、データアクセスがファイルの一部に対してのみ行われる場合の大きいファイルの管理に適用可能である。

詳細な説明
一実施形態では、第１および第２のコンピュータシステムはそれぞれ、Ｕｎｉｘ（商標）を実行するワークステーションなどの汎用コンピュータ上で実行されるソフトウェアプログラムを備えるが、Ｗｉｎｄｏｗｓ（商標）またはＬｉｎｕｘ（商標）オペレーティングシステムを実行するＩｎｔｅｌ Ｐｅｎｔｉｕｍ（商標）搭載のＰＣなど、他のコンピュータシステムを用いてもよい。コンピュータシステムは、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブル・ゲートアレイ（ＦＰＧＡ）などのチップに命令を組み込んだ専用のハードワイヤードシステムなど、他の手段で実現されてもよい。第２のコンピュータシステムは、ストレージシステムとして用いられるものであり、ＥＭＣ、Ｎｅｔｗｏｒｋ Ａｐｐｌｉａｎｃｅ、Ｓｔｏｒａｇｅ Ｔｅｋ、およびＡＤＩＣによって製造され、ネットワーク接続型ストレージ（ＮＡＳ）またはストレージ領域ネットワーク（ＳＡＮ）構成で接続されたものなど、専門のストレージ装置の形態で実現されてよい。コンピュータシステム４０は、以下に示す要素を任意の数だけ備えてよい：すなわち、図２に示すように、演算処理装置４１、メモリ４２、ディスプレイ４４、キーボード４６、大容量ストレージデバイス４８、ネットワークインターフェース５０、および、その他の入出力デバイス５２である。一般に、メモリ４２および大容量ストレージデバイス４８は、プログラム命令およびデータを格納するために用いることができる。コンピュータシステム４０は、さらに、ＰｅｎｔｉｕｍベースのマルチプロセッサシステムやＳｕｎのＳＰＡＲＣステーションなど、２以上の中央演算処理装置４１を備えてもよい。大容量ストレージデバイス４８は、１以上のハードディスクドライブ、光学ドライブ、テープドライブ、光磁気ドライブ、ＤＡＴ、ＣＤドライブ、ＤＶＤドライブ、または、その他のデバイスを備え、ＲＡＩＤ、ファイバチャネル、または、その他のインターフェースを用いてデータを格納してよい。大容量ストレージデバイス１８は、ファイルシステム内に構成されてよく、２組以上の大容量ストレージデバイス１８が用いられてもよい。

ファイルシステムは、一種のオブジェクトストアであり、ファイル（オブジェクトのＩＤが、そのパス名である場合）またはオブジェクト（オブジェクトが、ファイルシステム名以外のＩＤによって参照される場合）を格納してよい。オブジェクトストアは、
オブジェクトを特定する方法、
オブジェクトの操作を可能にするインターフェース（ＡＰＩ、ファイルシステム要素など）、および
オブジェクトのためのストレージ、
といった要素を備える。ファイルは、一種のオブジェクトであると見なしてよい。本明細書に開示する原理は、ファイルおよびファイルシステムだけでなく、オブジェクトおよびオブジェクトストアにも同様に適用される。オブジェクトストアに対しては、バックエンド内でオブジェクトを探す場所を記述する拡張属性は、ファイル名ではなく、オブジェクトＩＤである。

第１のコンピュータシステムは、フロントエンド１２として機能するものであり、一般に、高速なデータアクセスのために、ハードディスクドライブ１８の形態で高速ストレージを備える。ストレージシステムは、バックエンド１４として機能するものであり、いくつかの高速なストレージと、テープバックアップ３０や光学ドライブ２８など、比較的低速であるが経済的なデバイスとを備える。ストレージシステム１４には、他の保管デバイスが取り付けられてもよい。バックエンド１４は、アクセス頻度の低いデータを格納するために用いられ、それにより、高価な高速ストレージスペースの必要性が低減される。

バックエンド１４は、さらに、第１のコンピュータシステム１２の一部として実現されてもよく、その場合には、バックエンド１４のストレージデバイスは、第１のコンピュータシステム１２に取り付けられる。開示された実施形態では、フロントエンド１２およびバックエンド１４をそれぞれ独立した第１および第２のコンピュータシステムとして説明しているが、独立した第２のコンピュータシステムは、本発明の実施に必須のものではない。

図に示した第１のコンピュータシステムは、以下に示すシステム管理の仕様に従う：Ｔｈｅ Ｏｐｅｎ Ｇｒｏｕｐ（元のＸ／Ｏｐｅｎ）によって刊行された「Ｄａｔａ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ（ＸＤＳＭ）API」、文書番号Ｃ４２９、ＵＫ ＩＳＢＮ １−８５９１２−１９０−Ｘ。なお、この文書に開示された内容は、本明細書で適宜参照される。この文書は、http://www.opengroup.orgから入手可能であり、データ管理ＡＰＩ（ＤＭＡＰＩ）対応のアプリケーションの仕様を示している。本明細書に記載されたデータ管理機能をサポートするものであれば、他のオペレーティングシステムを用いてもよい。

ＵｎｉｘまたはＬｉｎｕｘシステムでは、オペレーティングシステムは、ｉノードを用いて、サイズ、所有者、日付、権限などの標準的なファイルシステム情報を格納する。ｉノードは、さらに、ＤＭＡＰＩ拡張データへのリンクを格納するために用いられてもよい。ＤＭＡＰＩ拡張データは、ＸＤＳＭ仕様書によって定められているように、拡張属性／メタデータおよび領域情報を含む。ＤＭＡＰＩ拡張データは、ＤＭＡＰＩ拡張データファイル６０に格納されることが好ましく、そのファイルは、一実施形態においては、．ＤＭＡＴＴＲと呼ばれる。ＤＭＡＰＩ拡張データファイル６０は、単一のファイルでもよいし、いくつかのファイルにわたってもよい。ファイルは、フロントエンド１２に格納されるが、バックエンド１４にも格納されることがある。フロントエンド１２内のストレージは、メモリ内にキャッシュがあれば、より高速なアクセスを提供する。図３は、ファイルシステム１６内でのｉノード６２およびＤＭＡＰＩ拡張データファイル６０の論理的な関係を示す。構成要素がグループでまとめて図示されているが、この図は、ディスク上での物理的な位置を反映するとは限らないことを理解されたい。ＤＭＡＰＩ拡張データファイル６０は、図３に示すように、ｉノード番号によって索引を付された拡張属性および領域のテーブルとして実現されてよい。別の構成では、図４に示すように、各ｉノード６２が、それぞれの拡張ブロック６４を指し示す。．ＤＭＡＴＴＲファイル６０にＤＭＡＰＩ情報を格納することにより、ｉノード６２およびＤＭＡＰＩ拡張ブロック６４を読み取ることなしに、ファイルに対するＤＭＡＰＩ情報を読み取ることができる。これは、多くのファイルが調べられている場合に有利である。この情報は、ｉノード情報と同様に、ファイルシステム１６の一部として格納されてよい。

拡張属性は、ファイルが移動されたか否かの情報、消去されたか否かの情報、ディレクトリパスの形態のバックエンド１４上のコンテナファイル７６へのリンク、およびオブジェクトＩＤなどの情報のトラックを保持するために用いられる。領域情報は、パーティション内のデータがローカルに存在するか否かの情報、データがダーティであって移動を必要とするか否かの情報、対応するローカルファイルのデータの位置など、ファイルのパーティションに関する情報を含む。フラグが用いられてもよく、ローカルファイル内のデータの位置は、オフセットおよび長さの情報によって示されてもよい。領域情報は、ファイルのマップ領域においてデータがアクセスまたは変更される場合に生成される１組のイベントを指定するフィールドを含んでもよい。１組のイベントとは、例えば、ｄｍ＿ｒｅｇｉｏｎ＿ｒｅａｄ、ｄｍ＿ｒｅｇｉｏｎ＿ｗｒｉｔｅ、ｄｍ＿ｒｅｇｉｏｎ＿ｔｒｕｎｃａｔｅである。フラグは、データが存在するか否か、または、ダーティであって移動を必要としているか否かを示すよう示すよう設定されてよい。パーティションのサイズが、動的に決定される場合には、パーティションのサイズに関する情報も同じように保持されてよい。ファイルをマップする領域の数は、データの位置のトラックを保持するために領域情報が用いられるため、データがアクセスされる際に増加してよい。

図５に示すように、ファイル７２は、バックエンド１４に移動される際には、パーティション７０に分割される。パーティション７０のサイズは、固定されていてもよいし、動的に変更可能であってもよい。固定パーティションは、システムファイル内に格納された構成または環境変数によって規定されるパーティションサイズを有してよい。パーティションサイズは、ファイルシステムの特性、ファイルのサイズ、およびデータアクセスのパターンに従って選択することができる。パーティションのサイズが大きくなるほど、待ち時間や帯域幅の利用、バージョニングのためにバックエンド１４において用いられるスペースが増大しうるため、パーティションのサイズは、大きすぎないことが好ましい。逆に、パーティションのサイズが小さすぎると、管理すべきパーティションの数が増えるため、パーティション管理の要求が増大する。大きなデータベースでは、１００メガバイト（ＭＢ）のパーティションサイズを用いてもよい。したがって、例えば、２ＧＢのファイルは、１００ＭＢパーティション２０個に分割されて、バックエンド１４に格納される。一実施例では、システムは、バックエンド１４用の９８４０のテープと、サイズ１２８ＭＢの１６のパーティションとを備えるＯｒａｃｌｅデータベースに用いられる。パーティションのサイズに影響するいくつかの要因は、データを必要とするアプリケーションのアクセスパターン、バックエンド１４とフロントエンド１２との間のデータ転送の速度、バックエンド１４の保管媒体のデータ転送速度、および、バックエンド１４の媒体の待ち時間である。位置決め時間が比較的長いバックエンド媒体（例えば、テープ３０）は、大きなパーティションサイズにとって有利に働く。

ファイル７２をパーティションに分割することにより、システムは、比較的小さい部分７０としてデータを移動することができるようになる。アプリケーションが、２ＧＢのファイルに由来するデータのごく一部のみに対して、データアクセスを要求する場合、そのデータがローカルファイルシステムに存在しなくても、そのデータを含む特定の１００ＭＢパーティションのみをアクセスするために読み出せばよい。そのデータを移動する所要時間は大幅に短いため、待ち時間が短縮され、移動するデータの量が小さくなることから、帯域幅の利用が低減される。同様に、データファイル７２のごく一部のみが、後に変更された場合には、データの変更部分を含むパーティション７０のみを、バックエンド１４に移動すればよい。

図６に示すように、第１のコンピュータシステムは、動作の際に、以下の３つのデーモンが存在するよう構成されている。
・イベントデーモンｄｖｄｂｍｉｇｄ８０、
・移動デーモンｄｘｄｂｍｉｇｗａｔｃｈ８２、
・消去デーモンｄｘｄｂｐｕｒｇｅｗａｔｃｈ８４。
１つのデーモンとしてスレッド化されたデーモンを含めて、任意の数のデーモンが用いられてよく、デーモン以外の方法が用いられてもよい。例えば、Ｗｉｎｄｏｗｓシステムが、複数のシステムエージェントおよびサービスを用いてもよい。イベントデーモン８０は、ファイルデータがアクセスされた際にトラップを行う。要求されたデータが、フロントエンド１２のローカルファイルシステム１６に存在しない場合には、イベントデーモン８０が、バックエンド１４からローカルファイルシステム１６にデータをコピーした後に、データアクセスが行われる。移動デーモン８２は、フロントエンド１２からバックエンド１４に移動する必要のあるデータを有するファイルを探す。移動を必要とするデータを有するファイルが確認されると、移動デーモン８２は、フロントエンド１２からバックエンド１４にデータをコピーする。消去デーモン８４は、ローカルファイルシステム１６において不必要となったデータを有するファイルを探して、不必要なデータを削除する。本明細書に記載されたように、移動および消去の候補の効率的な検索を用いれば、少ないコストで移動および消去の候補を探すことができるため、移動および消去デーモン８２および８４は、定期的に、例えば、５分間隔で稼働するよう構成されてよい。

図８の工程１００によると、移動デーモン８２（または、スレッド化された単一のデーモン）は、．ＤＭＡＴＴＲファイル６０に格納された属性情報を用いて、ファイルが移動を必要とするか否かを判断する。また、本明細書に記載したように、拡張ブロック６４に格納された属性情報を用いてもよい。ファイル７２が以前に移動されていない場合には、そのファイルは、固定サイズもしくは動的に決定されるサイズのパーティション７０に分割される。パーティションのサイズは、データアクセスの頻度、アクセス毎に読み出される連続的なデータの量、および、その他のアクセスパターン情報に基づいて動的に決定されてよい。移動デーモン８２は、他の処理をフォークして、様々なタスクを行ってよい。移動の前処理中、データの移動中、または、移動の際にファイルが変化したか否か（変化した場合には、現行の移動を失敗とし、次回に移動を試みる）を確認する際に、ファイルを保護するために、セマフォ、ファイルロック、および、その他のメソッドを用いてよい。

移動処理は、ファイルを排他的にロックし（工程１０２）、属性および領域情報を読み取り（工程１０４）、ファイルが移動を必要とするか否かを判断する（工程１０６）。移動の必要がない場合には、ロックは解除される（工程１０８）。移動が必要な場合には、領域情報、ファイルのサイズ、およびパーティションのサイズに基づいて、ファイルのどの部分が移動を必要とするのか判断される（工程１１０）。ファイルが、以前に移動されていた場合には（工程１１２）、以前の移動を記述する情報を含むコンテナファイル７６が存在するため、このファイルが読み出されて、そのファイルの新しいバージョン番号が決定される。ファイルが以前に移動されていない場合には、バージョン番号は１に設定される。新規のデータと最後の移動の後に変更されたデータのみが、バックエンド１４に移動される。データは、パーティションのサイズに従ってパーティションに分割される（工程１１４）。なお、パーティションサイズは、固定されていてもよいし、動的であってもよい。ロックが解除されることで、移動の実行中に、そのファイルを用いる他の処理を進行できるようになる。

工程１２０において、移動を必要とするパーティション７０は、フロントエンド１２におけるファイルアクセス時刻を変更することなく、バックエンド１４にコピーされる。移動の際にエラーが起きた場合には、その移動は、次の移動の実行時に再び試みられることになる（工程１２４）。移動が成功した場合には、そのファイルは、工程１２６において再びロックされ、そのファイルの属性および領域情報が再び読み出されて、データの移動中にファイルが変更されたか否かを判断するために用いられる（工程１２８）。ファイルが変更された場合には、ロックは解除され（工程１３２）、データが不整合である可能性があるため、移動は失敗となり、後に再試行される（工程１２４）。データの移動中に、ファイルに変更が加えられていない場合には、そのファイルの情報が更新され、ファイルの移動に成功したことが示される（工程１３４）。拡張属性（ＤＭＡＰＩ／ＸＤＳＭなど）および領域情報が更新され、パス名、サイズ、所有者、権限、およびその他のファイル属性を含むファイルに関する情報が、「＊．ｃｏｎｔファイル」という名前のコンテナファイル７６に書き込まれる。なお、コンテナファイル７６はデータファイルと関連付けられている。コンテナファイル７６には、バージョニング情報を含めて、バックエンド１４に格納されたパーティションに関する情報も書き込まれる。

ファイルの状態は、整合性を保証するために、特定の順序で更新される必要がある。図９の工程１４０において、属性は、ファイルが消去されていないことを示すように設定され、ファイルのパーティションサイズが設定され（必要な場合）、バックエンド１４のファイルの位置が設定され、工程１４２において、ファイルシステム１６に情報が書き込まれる。これにより、クラッシュした場合に、新しい状態にロールフォワードするか以前の状態にロールバックすることで、ファイルへのアクセスを実現するのに十分な情報が、ファイル内に存在するよう保証される。新しいバージョンの＊．ｃｏｎｔファイル７６が、そのファイルの古い状態または新しい状態を含むことを保証する方法で書き込まれる（工程１４４）。工程１４６において、領域情報は、すべてのファイルデータのバックエンド１４への移動が成功したことを示すよう、ＤＭＡＰＩ／ＸＤＳＭインターフェースを通して書き込まれ、次いで、工程１４８において、．ＤＭＡＴＴＲファイル６０が同期化される（まだ書き込まれていない情報がディスクに書き込まれる）。これが失敗しても、古い領域情報がまだ有効であるため、将来の移動は、将来に移動が試みられた際に進行可能である。ＤＭＡＰＩ／ＸＤＳＭ属性は、ファイルを移動中としてマークするよう更新される（工程１５０）。この工程は、バックエンド１４内に格納されているデータの位置、移動の時間、および、ファイルを移動中としてマークしていることを示すようにメタデータを設定する工程を含む。メタデータは、いつ障害が起きても、常にファイルが整合性を保った状態で維持されるように書き込まれる。

これにより、障害発生時のデータの破壊が防止されると共に、ファイルは、無効なファイルデータへのアクセスを許す状態に陥ることを防止される。領域情報に格納された状態、ファイルのメタデータ、バックエンドのバージョンファイル（＊．ｃｏｎｔファイル）は、消去後に必要であればファイルを復元するのに十分、または、ローカルに管理されているディスクが失われたりファイルが不注意で削除されたりした際にファイルを回復するのに十分なものである。

各データファイル７２は、自身に関連付けられた＊．ｃｏｎｔファイル７６を有してよいが、複数のデータファイルの＊．ｃｏｎｔ情報を単一のコンテナファイルに格納することも可能であり、その場合、それらの情報は、データファイルの名前、またはオブジェクトＩＤのような他の識別子によって索引を付されてよい。ファイルが以前に移動されたことがある場合には、．ＤＭＡＴＴＲファイル６０内の領域情報は、パーティションがダーティであるか否か、すなわち、最後の移動の後に変更されているか否かを判断するために調べられる。変更されたパーティションは、バックエンド１４にコピーされ、バージョニングされてよい。その際、パーティションの既存のコピーは上書きされない。＊．ｃｏｎｔファイル７６は、図７に示すようにバージョンのトラックを保持する。

例えば、＊．ｃｏｎｔファイル７６が、パーティションのバージョン５４がバックエンド１４にすでに存在することを示す場合には、変更されたパーティションは、バージョン５４を変更も上書きもせずにバージョン５５として書き込まれ、＊．ｃｏｎｔファイル７６は、この動作を反映するよう更新される。実際的には、＊．ｃｏｎｔファイルは、ファイルの差分のトラックを保持する。＊．ｃｏｎｔファイルは、スナップショットを有効に保持するため、すなわち、任意の特定の日時に、データファイル７２がどのような状態であったのかを決定できるため、関連するファイルを任意の時点の状態に回復するのに必要な情報を有する。移動の終了後（例えば、移動されるデータのテープへの書き込みが成功した場合）、新しく移動されたパーティションに関する情報が、コンテナファイル７６に格納される。．ＤＭＡＴＴＲファイル６０は、そのファイルが初めて移動された場合にはバックエンド１４のコンテナファイルへのリンクと共に、そのファイルが移動されたことを示すよう更新される。変更されたパーティションが移動されると、領域情報は、パーティションが、もはやダーティではなく、移動を必要としないことを示すよう更新される。このように、フロントエンド１２のファイルとバックエンド１４のパーティションとの間のリンクが、．ＤＭＡＴＴＲファイル６０および＊．ｃｏｎｔファイル７６に格納されている。

移動の例として、フロントエンド１２上に、以前に移動されていないＡＢＣというデータファイルが存在する場合には、バックエンド１４のデータファイルに対して、例えば１２３という固有のパス名が選択される。ＡＢＣファイルは、オブジェクト管理システムの構成によって決定されたパーティションのサイズに従ってパーティションに分割される。これらのパーティションは、固有のパス名、パーティション番号、およびバージョン番号、例えば、１２３．ｐａｒｔｉｔｉｏｎ１．ｖｅｒｓｉｏｎ１、１２３．ｐａｒｔｉｔｉｏｎ２．ｖｅｒｓｉｏｎ１ないし１２３．ｐａｒｔｉｔｉｏｎＮ．ｖｅｒｓｉｏｎ１、を示す個々のファイルとして、バックエンド１４にコピーされる。次いで、１２３．ｃｏｎｔファイルが書き込まれる。１２３．ｃｏｎｔファイルは、ローカルファイルシステム１６上のファイル名、パーティションの名前、およびパーティションのバージョンを含めて、移動の際に実行されたことを記述する。さらなる情報が、．ＤＭＡＴＴＲファイル６０内のローカルファイルシステム１６またはファイルシステム内の他の場所に書き込まれる。その情報は、他の場所に配置することも可能であるが、ローカルファイルシステム１６に配置することで、アクセスの速度が増大する。．ＤＭＡＴＴＲファイル６０は、さらに、フロントエンド１２のメモリにキャッシュされてもよいが、この場合、クラッシュが起きた際に整合性を保証するために、キャッシュされたファイルとディスク上のファイルとの同期化を頻繁に行う必要がある。書き込まれる属性は、ファイルＡＢＣがファイル１２３に移動された旨の情報と、移動が発生した時を示すタイムスタンプと、ファイルの移動された場所と、ファイルのバックエンド１４への移動が成功した旨を示す情報とを含む。

図１０によると、消去デーモン８４（またはスレッド化されたデーモン）は、．ＤＭＡＴＴＲファイル６０に格納された属性情報を用いて、すでに移動されている（すなわち、移動の必要がない）が消去されていないファイルを特定する（工程２００）。消去デーモン８４は、ローカルファイルシステム１６上に空きスペースが必要であると判断した後に上記の工程を実行してもよく、この場合、十分な空きスペースが存在する場合には消去を中止する。工程２０２において、消去の候補は、実施されている消去ポリシーに従ってソートされる。なお、消去ポリシーは、ユーザによって構成可能であってよい。ＬＲＵ（最低使用頻度）が、消去ポリシーとして用いられてよいが、ファイルシステム１６に格納されたデータの特徴、ファイルシステム１６のデータを用いるアプリケーション、およびデータアクセスのパターンに基づいて、他のポリシーが選択されてもよい。ポリシーは、ファイルレベルで適用されてもよいし、パーティションレベルで適用されてもよい。消去デーモン８４は、拡張属性内の情報を用いて、ファイル内のパーティションの最終アクセス時刻、アクセス頻度などを決定してもよい。消去ポリシーに基づいて、消去デーモン８４は、消去されるべきパーティションを特定する。例えば、消去デーモン８４は、ＬＲＵアルゴリズムを用いてファイルをソートし、次いで、消去の対象として選択されたファイルの範囲内で、特定の日付よりも古い最終アクセス日を有するパーティションを選択する。

ファイルのロック、セマフォ、およびその他のメソッドを用いて、データの損失や破壊が防止される。消去処理が、消去候補のリストをコンパイルして、消去の対象となるファイルが選択された後に、そのファイルはロックされる（工程２０４）。属性および領域情報が、読み出され（工程２０６）、リストがコンパイルされるまでにファイルがアクセスされたか否か、すなわち、そのファイルがまだ消去候補であるか否かを確認するために調べられる（工程２０８）。ファイルが消去候補ではない場合、そのファイルは消去されず、ロックは解除される（工程２１０）。ファイルがまだ消去候補である場合には、ファイルの領域情報は、そのファイル全体が消去されたことを示すように設定される（工程２１２）。消去デーモン８４は、選択されたパーティションに対応するローカルデータを、そのファイルから削除する。ＤＭＡＰＩ対応のシステムでは、消去デーモン８４は、ｄｍ＿ｐｕｎｃｈ＿ｈｏｌｅ（）を用いて、ローカルデータを削除する。オペレーティングシステムの能力に応じて、ローカルファイル７２は、ほとんどのオペレーティングシステムで一般に行われているように、ファイルのオフセットから末尾まで切り捨てられてもよいし、ＡＩＸによって実行されるように、ファイルの中央部に穴が開けられてもよい。削除されるデータは、ファイルの先頭部分であってもよく、この場合には、スタブ７４が残される（図５）。

ローカルデータが削除されると、属性および領域情報は、データの消去を反映するよう更新される（工程２１６）。領域情報は、実際に消去されたデータが、もはやローカルファイルシステム１６に存在しないことを示し、ファイル全体が消去された（スタブ７４を除く）場合には、属性は、ファイルが消去されたことを示す。ファイルの一部が残っている場合には、そのファイルは、引き続き消去候補となる。ファイルのメタデータが更新された後、ファイルからロックが除去される（工程２１８）。これにより、システムクラッシュなどの障害が起きた際にファイルが保護される。ファイルは、消去済みとしてマークされていないため、まだ消去候補と見なされるが、ファイル内のすべてのパーティションは、消去動作の前に消去済みとしてマークされるため、アクセスされた際には、再現されることになる。一部のデータがローカルのまま残ってもよいが、消去動作中にエラーが起こった際には、消去された部分を示すことが不可能な場合もある。そのため、消去処理は、すべてのパーティションを消去済みとしてマークし、消去の完了後に、領域情報を更新して、どのパーティションが存在しているのかを示す。メタデータの更新が失敗した場合には、ファイルは、まだ消去候補であるように見えるが、そのファイルのデータの一部または全部が、ローカルファイルからすでに消去されていることもある。上述の手順は、データの破壊を防止するよう意図されたものであるが、領域情報、ファイルデータの削除、およびファイルメタデータの更新が、整合性を保証するように同期化される限りは、他の方法を用いてもよい。これにより、ファイルを、古いデータへのアクセスが実行されうる不整合な状態にして置かずに済む。

ファイル７２は、通例、アプリケーションによって走査されるファイルの先頭部分にヘッダとその他の頻繁に用いられる情報とを含み、ファイルの消去の際には、スタブ７４を残すことにより、データアクセス時間が高速化されうる。ユーザは、頻繁にアクセスされるファイル７２の先頭部分に情報が存在するか否か、ファイル７２の先頭部分においてアクセスされるデータの量などの情報に基づいて、スタブ７４の長さを規定してよい。例えば、Ｏｒａｃｌｅデータベースは、始動時や、ＯｒａｃｌｅがすべてのＯｒａｃｌｅデータファイルにアクセスする時などに、Ｏｒａｃｌｅがデータファイル内のスタブに頻繁にアクセスするため、少なくとも１２８ＫＢのスタブサイズを必要とすることがある。スタブデータが存在しない場合には、Ｏｒａｃｌｅは、そのデータがバックエンド１４から回復されるまで停止する。これは、多くのテープのマウント（または、ＣＤなど、その他のストレージ媒体のマウント）を意味する。スタブ７４は、バージョニングされ、ファイルまたはオブジェクトとしてバックエンド１４に格納されてよい。

図１１の工程３００において、イベントデーモン８０またはスレッド化されたデーモンは、データアクセスイベントをトラップし、データアクセス活動をトラックする。データアクセス要求が発行されると、処理は、データアクセスが読み出しであるかアクセスであるかに従って、ファイルの変更（書き込みや切り捨てなど）を行う（工程３０２）。データアクセスが読み出しの場合（工程３０４）、．ＤＭＡＴＴＲファイル６０が調べられ、要求されたデータがローカルファイルシステム１６に存在するか否か、すなわち、アクセスされるファイルの部分に対応するパーティションが存在するとしてマークされていることを、領域情報が示しているか否か判断される。要求されたデータが存在する場合（工程３０６）、アクセス要求は、ファイルシステムに受け渡され（工程３０８）、ファイル属性および領域情報は、そのアクセスを反映するように更新されてよい（工程３２４）。要求されたデータが存在しない場合には、イベントデーモン８０またはイベントデーモン８０からイベントを受信する他の処理が、そのファイルをロックして、領域および属性情報を調べ（工程３１０）、処理が必要か否かを判断する（工程３１２）。以前にイベントの処理が実行されたために処理が必要とならない場合、工程３１４において、ロックが解除され、イベントに対して応答が生成され、入出力処理の完了を待っている処理が始動される。処理が必要な場合には、ファイルは消去可能としてマークされ、メタデータが同期化され、イベント処理を完了するために必要なファイルデータが判断され、バックエンド１４のファイルの位置が決定され、＊．ｃｏｎｔファイルが読み出され、ファイルのロックが解除される（工程３１６）。

ファイルは、データの移動中にはロックされないため、ローカルファイルシステム１６にすでに存在するデータを処理することが可能である。必要なパーティションが、バックエンド１４から読み出され、フロントエンド１２のローカルファイルシステム１６に書き込まれる（工程３１８）。そのファイルは、再び排他的にロックされ（工程３２０）、領域および属性情報が、整合性を保って更新されて（工程３２２）、ロックが解除される。待機状態の処理に応答が送信され、その処理を始動して、読み出し要求を完了させる（工程３１４）。以後、このデータへのアクセスが生じても、そのデータが再び消去されない限りは、復元イベントは生成されない。

データアクセスのパターンに基づいて、予測的なパーティション読み出しが、同様に実行されてもよい。すなわち、データアクセスのパターンに関する情報を記録することが可能であり、特定のパーティションへのアクセスに伴って他のパーティションへのアクセスも頻繁に生じた場合に、後者のパーティションが、事前に読み出されてもよい。

工程３２４においては、イベントデーモン８０がデータアクセスイベントを処理した後に、．ＤＭＡＴＴＲファイル６０は、消去ポリシーがパーティションレベルでデータアクセス情報を用いる場合などに、アクセスされるファイルの部分に対応するパーティションのアクセス時刻を示すように更新されてよい。システムは、ファイルアクセス時刻を示すためのファイル属性を更新する。

アクセス要求が書き込みであった場合には、領域は、アクセス時刻を更新するために変更され、データに対応するパーティションは、ダーティ（そのため、移動を必要とする）としてマークされる（工程３２６）。この場合、ファイルは、排他的にロックされ、イベントは、処理が必要か否かを判断するために調べられる（工程３２８）。処理が必要ない場合、ロックは解除され、イベントに対して応答がなされ、処理が終了する（工程３３０）。処理が必要な場合には（工程３３２）、メタデータは、ファイルが消去候補であって、さらに、データが間もなく変更されることから移動候補であることを示すよう更新される。ファイルの状態を判断するために、ファイルのメタデータ、領域情報、および＊．ｃｏｎｔファイルが読み出される。イベントを生成したファイルの領域が決定され、データがローカルに存在しないことを領域情報が示す場合には、ロックは解除され、上述の読み出し処理と同じようにデータが移動される（工程３３８）。データがすでに存在する場合には、バックエンド１４から移動されるべきデータはない。工程３４０においては、データが再現された後に、ファイルは再びロックされ、ファイルのメタデータおよび領域情報は、ファイル内の一部のデータが移動を必要としていることと、ファイルのどの部分が変更されたかを示すよう更新される。排他ロックは解除され、待ち状態の処理に応答が送信される（工程３４２）。

イベント処理においては、例えば、構成で規定された長さを有するスタブ７４を除いて、すべてが移動および消去されるＮのパーティションを有するファイルＡＢＣについて、パーティション７７内のデータへのデータアクセス要求が、イベントデーモン８０によってトラップされる。これは、図１２に示されている。デーモンは、パーティション７７のデータがローカルファイルシステム１６に存在しないと判断し、．ＤＭＡＴＴＲファイル６０を調べて、対応するコンテナファイルは、バックエンド１４の１２３．ｃｏｎｔであると判断する。対応するバックエンドのファイル１２３のパーティション７７に対する要求が発行される。１２３．ｃｏｎｔは、バージョン５５がファイル１２３のパーティション７７の最新のバージョンであることを示している可能性があり、その場合、１２３．パーティション７７．バージョン５５がフロントエンド１２に読み出される。パーティションをディスクに復元した後、属性および領域情報が更新される。

ファイル全体ではなくファイルのセグメントに対して移動および読み出しを行うことにより、システムは、大きくて時間の掛かるファイルの移動を回避する。例えば、データベースファイルは、非常に大きく、ギガバイト単位になる傾向にある。特に、Ｏｒａｃｌｅなどのデータベースアプリケーションが、テーブルのごく一部のみにアクセスしている可能性がある場合、移動および読み取りの際にファイル全体をやり取りすることは実際的ではない。Ｏｒａｃｌｅは、例えば、ファイル全体を一度で走査しない。すなわち、１つのデータベースファイルを部分的に走査して他のファイルへと進み、これを繰り返して、最後に第１のファイルに戻って、さらなるデータを走査する。ファイル全体を読み出すと、システムがスラッシングを起こし、読み出しに時間が掛かる。

システムは、さらに、移動および消去の候補を効率的に検索するよう構成されるが、この構成は、本明細書に記載されたファイルのパーティション化およびパーティションの管理を実施するために必要なものではない。図１４に示すように、１つの方法は、ネームスペースでファイル名を検索し、各ファイルのｉノードと拡張属性とを見つける方法である。一部の構成では、ｉノードは、拡張属性を含む拡張ブロックへのポインタを含み、第２の検索と、それに応じたディスクへのアクセスを必要とする。より効率的な方法では、図１３および１４に示すように、システムは、ＤＭＡＰＩ拡張データファイル６０（．ＤＭＡＴＴＲファイル）から、ファイル名、ｉノード番号、および拡張属性を検索する（工程３５０）。システムは、他の単一のファイルまたは複数のファイルを用いるよう構成されてもよい。このように、システムは、ネームスペース内のすべてのファイルのｉノードおよび拡張ブロックを検索することなく、どのファイルが移動または消去の候補であるのかを迅速に判断することができる（工程３５２）。候補のパス名を生成するために、その候補のｉノード番号を用いて、パス名が検索される（工程３５４）。これは、ｉノードおよびパス名のリストにおいて逆検索を行うことにより実行できる。リストは、同じファイルすなわち．ＤＭＡＴＴＲ、または別個のファイルやファイル群に、テーブルとして格納されてよい。この構成によれば、システムは、移動および消去の候補として特定されたファイルのｉノードのみを調べればよく、移動および消去されたファイルを含むすべてのファイルの情報を調べる必要がない。これにより、移動および消去に必要な実行時間とシステム負荷が大幅に低減される。例えば、どのファイルが移動を必要とするのかを判断する際に、本明細書に記載された効率的な検索を用いるシステムは、移動および消去の候補のための１００万のファイルを含むファイルシステムを１分未満で調べることができる。Ｓｏｌａｒｉｓマシンは、１００万のファイルを含み、ただ１つの移動候補を有する場合に、ネームスペースの検索に従来は２０分掛かっていたのに対し、そのファイルを１０秒で見つけられるようになる。この方法は、ＬｉｎｕｘやＳｏｌａｒｉｓなどＵｎｉｘ風のオペレーティングシステムを用いるＮＦＳ型ファイルシステム、ＸＦＳ、ＵＦＳ、Ｖｅｒｉｔａｓ、および、同様のファイルシステムで用いてよく、さらに、その他のオペレーティングとファイルシステムに適用してもよい。

本明細書に記載されたコンテナファイル７６を用いることにより、図１５および１６に示すように、最初にデータすべてをコピーすることなく（１つのファイルシステムの内容を他のファイルシステムに複製するのは、非常に時間の掛かる処理であることが多い）、１つのコンピュータシステム（マシンＡ）のデータを、他のコンピュータシステム（マシンＢ）にとって利用可能にすることができる。マシンＢは、バックエンド１４に存在するマシンＡのコンテナファイルを用いるよう構成可能である（工程４００）。各コンテナファイル７６は、サイズ、所有者、権限、およびパスなどのファイル属性に関する情報を含み、マシンＢは、それを用いて、自身のローカルファイルシステム上に新しいファイルを作成してもよい。マシンＢが＊．ｃｏｎｔファイルを読み出すと（工程４０２）、新しいファイルが作成され（工程４０４）、新しいファイルのサイズは、＊．ｃｏｎｔファイル７６で指定されたサイズに設定され（工程４０６）、工程４０８において、（ファイルが消去されたかのように）割り当てスペースが開放されて、マシンＢのファイルシステム上にスタブファイルが作成される。．ＤＭＡＴＴＲファイル６０、またはその他の拡張データブロックもしくはファイルが作成され、属性および領域が設定される（工程４１０）。マシンＢに固有のコンテナ（＊．ｃｏｎｔ）ファイルがバックエンド１４に書き込まれる（工程４１２）。ただし、その工程は、マシンＢがデータを変更してバックエンド１４に移動する際に、必要に応じて実行できる。マシンＢが作動すると、データアクセス要求の結果、概して、要求されたデータがマシンＢのローカルファイルシステムに存在しないと判断され、必要なパーティションが、バックエンド１４からマシンＢのローカルファイルシステムにコピーされる（工程４１４）。ファイルの属性および領域情報は、上述した方法と同じように、マシンＢにおいて更新される。マシンＢがデータを変更すると、変更されたパーティション（図１６に示すＢの変更データ）は、バックエンド１４に書き込まれ、その変更に関する情報が、マシンＢのコンテナファイル（＊．ｃｏｎｔ）に格納される（工程４１６）。マシンＡは、自身のパーティションの書き込みを継続し、その変更に関する情報を自身のコンテナファイル７６に格納する（工程４１８）。各コンピュータシステムは、自身の変更パーティションをバックエンド１４に書き込む。各コンピュータシステムは、自身のコンテナファイルを用いるため、独自のバージョンのデータを有する。

以上の開示および実施形態は、コンピュータシステムにおいてオブジェクト管理の効率を向上させる際の本発明の有用性を示すものであるが、本発明が、その他の多くの利用法において役立つことは明らかである。本発明は、ファイルの一部がアクセスされ、ファイル内のデータすべてにアクセスすることなく該当しうるデータベース、ビデオ、オーディオなどの用途で特に有用である。

明確にするために、本明細書では、具体的な流れに沿って処理および方法を説明したが、本発明の趣旨から逸脱することなく、他の手順も可能であり、その一部は並行して実行してよいことを理解されたい。さらに、工程は、さらに分割してもよいし組み合わせてもよい。本明細書に開示するように、本発明に従って書かれたソフトウェアは、メモリやＣＤ−ＲＯＭなど、各種のコンピュータ読み取り可能な媒体に格納され、またはネットワークを介して転送されて、プロセッサによって実行されてよい。

本明細書にて引用されたすべての参照は、参考のために組み入れられたものである。本発明は、特定の実施形態に基づいて説明されたが、本発明の変更および変形は、当業者にとって自明のものであり、添付の請求項の範囲および等価物の範囲内で実施可能である。複数のコンピュータが、全体として、オブジェクト管理システムの機能を実行するように、すなわち、それらが単一のコンピュータの役割を果たすように、それら複数のコンピュータを、並列または負荷分散構成で用いたり、複数のコンピュータにタスクを分配したりすることにより、２以上のコンピュータを用いてもよい。上述の様々な機能は、単一の処理または複数の処理のグループによって、単一のコンピュータで実行されてもよいし、いくつかのコンピュータに分配されてもよい。処理は、ある特定のタスクを処理するために、他の処理を呼び出してもよい。開示された原理は、ファイルおよびファイルシステムだけでなく、オブジェクトおよびオブジェクトストアに適用される。上述の実施形態は、例示であって、限定を意図したものではないため、本発明は、本明細書に記載された詳細に限定されない。したがって、本開示と以下の請求項は、本発明の真の趣旨および範囲に含まれる変更および変形をすべて網羅するものと見なされる。

フロントエンドとバックエンドとを備えるオブジェクト管理システムを示す説明図。 大容量ストレージが取り付けられたコンピュータシステムを示す説明図。 ｉノードと、ＤＭＡＰＩ情報が格納されたファイルとの論理的な関係を示すブロック図。 ｉノードと、ＤＭＡＰＩ情報が格納された拡張ブロックとの論理的な関係を示すブロック図。 ファイルと、ＤＭＡＰＩ拡張データファイルと、コンテナファイルと、バックエンドに格納されたパーティションとを示すブロック図。 オブジェクト管理システムで用いられるデーモンを示すブロック図。 パーティションのバージョニングを示すブロック図。 移動処理を示すフローチャート。 整合性を保証するためのファイル状態の更新を示すフローチャート。 消去処理を示すフローチャート。 データのイベント処理および再現する処理を示すフローチャート。 パーティションを再現する処理を示すブロック図。 移動または消去の候補の効率的な検索と、候補のパス名の取得とを示すフローチャート。 移動または消去の候補を検索するためのいくつかの方法を示すブロック図。 あるコンピュータのデータを他のコンピュータで利用可能にするためのコンテナファイルの利用を示すフローチャート。 図１５に示した処理を行なうコンピュータを示すブロック図。

符号の説明

１０…オブジェクト管理システム
１２…コンピュータシステム
１４…ストレージシステム
１６…ファイルシステム
１８…ハードディスクドライブ
２２…ＣＰＵ
２４…ハードディスクドライブ
２６…ファイルシステム
２８…光学ディスク
３０…テープドライブ
４０…コンピュータシステム
４１…演算処理装置
４２…メモリ
４４…ディスプレイ
４６…キーボード
４８…大容量ストレージデバイス
５０…ネットワークインターフェース
５２…入出力デバイス
５４…バージョン
５５…バージョン
６０…ＤＭＡＰＩ拡張データファイル
６２…ｉノード
６４…拡張ブロック
７０…パーティション
７２…ファイル
７４…スタブ
７６…コンテナファイル
８０…イベントデーモン
８２…移動デーモン
８４…消去デーモン

Claims (13)

1. コンピュータシステムを備えるオブジェクト管理システムであって、
   当該コンピュータシステムは、
   オブジェクトを格納し、
   前記オブジェクトを複数の区画に分割し、
   各区画を選択し、
   該選択された区画を、個別に格納されたオブジェクトとしての格納のために、ストレージデバイスに提供する
   よう構成されたオブジェクト管理システム。
2. 請求項１に記載のオブジェクト管理システムであって、
   前記コンピュータシステムは、前記複数の区画の一部のみを選択するよう構成されたオブジェクト管理システム。
3. 請求項２に記載のオブジェクト管理システムであって、
   前記コンピュータシステムは、どの区画が前記ストレージデバイスへの移動を必要とするかを判断することにより、前記区画を選択するよう構成されているオブジェクト管理システム。
4. 請求項３に記載のオブジェクト管理システムであって、
   前記コンピュータシステムは、区画が変更されたか否かを判断することにより、どの区画が移動を必要とするかを判断するよう構成されているオブジェクト管理システム。
5. 請求項４に記載のオブジェクト管理システムであって、
   さらに、前記オブジェクトに関連付けられたデータオブジェクトを備え、前記データオブジェクトは、区画が変更されたか否かに関する情報を含むオブジェクト管理システム。
6. 請求項１に記載のオブジェクト管理システムであって、
   前記オブジェクトはファイルであるオブジェクト管理システム。
7. 請求項１に記載のオブジェクト管理システムであって、
   前記コンピュータシステムは、さらに、選択された区画を前記ストレージデバイスから読み出すよう構成されているオブジェクト管理システム。
8. 請求項７に記載のオブジェクト管理システムであって、
   前記コンピュータシステムは、さらに、データアクセス要求を受信し、前記データアクセス要求を用いて、前記ストレージデバイスから読み出される前記区画を選択するよう構成されているオブジェクト管理システム。
9. 請求項８に記載のオブジェクト管理システムであって、
   さらに、前記オブジェクトに関連付けられたデータオブジェクトを備え、前記データオブジェクトは、前記区画が前記コンピュータシステムに存在するか否かに関する情報を含むオブジェクト管理システム。
10. 請求項９に記載のオブジェクト管理システムであって、
    前記コンピュータシステムは、前記区画が前記コンピュータシステムに存在しないことを前記データオブジェクトが示す場合に、前記ストレージデバイスから読み出される区画を選択するオブジェクト管理システム。
11. ストレージデバイスと、オブジェクトを格納するよう構成されたコンピュータシステムとを備えるシステムにおいてオブジェクトを管理するための方法であって、
    前記オブジェクトを複数の区画に分割する工程と、
    各区画を選択する工程と、
    前記選択された区画を、格納のために前記ストレージデバイスに提供する工程と
    を備える方法。
12. 請求項１１に記載の方法であって、
    さらに、データアクセス要求を受信する工程を備え、前記ストレージデバイスから読み出される区画を選択する工程は、前記データアクセス要求を用いて、どの区画を選択するかを決定する工程を備える方法。
13. ストレージデバイスと、オブジェクトを格納するよう構成されたコンピュータシステムとを備えるシステムにおいてオブジェクトを管理するためのコンピュータプログラムであって、
    コンピュータにより利用可能な媒体に、
    前記オブジェクトを複数の区画に分割するコード、
    各区画を選択するコード、
    前記選択された区画を、前記ストレージデバイスに提供するコード
    が、コンピュータにより読み取り可能に記録されたコンピュータプログラム。

Images