JP2012526332A - 光ディスク記憶システムに格納されたメディアへのアクセス，圧縮及び追跡 - Google Patents

Abstract

【課題】メディアライブラリに記憶されたデータへのアクセス，圧縮，及びライブラリ内の光メディアを追跡する方法，システム及びコンピュータ可読媒体を提供すること。
【解決手段】ハイブリッド記憶機器のシミュレーション層が，追記特性を有する光メディアのライブラリを，非追記特徴を有する論理ブロック装置のように認識させる。また，ユーザファイルのデータが一つに圧縮されて，圧縮されたユーザファイル内で粗粒度探索が可能である。さらに，メディアクラウドを用いて，データの生成，復元，分散の際に，光メディアと，ライブラリロボットと，光ドライブと，ネットワーク接続との故障を一貫して回復させる。またさらに，カートリッジリスト及びメディアタグが，ライブラリ内で光メディアを追跡するために使用される。
【選択図】図１

Description

本発明は，光ディスク記憶システムに格納されたメディアへのアクセスに関し，更に詳細には，記憶機器のメディアライブラリに関する。

本願は，２００９年５月８日出願の"Accessing, Compressing, And Tracking Media Stored in An Optical Disc Storage System"と題する米国仮特許出願第６１／１７６，６９７号に基づく優先権を主張するものである。
データ損失の結果は悲惨な場合もあるため，長期記憶用のデータアーカイブ方法が発展しつつある。伝統的に，永続記憶のためには二つの選択がある。すなわちデータがオンラインで維持されるか，又はアーカイブされるかである。オンラインデータは，探索可能なフォーマットで迅速なアクセスが可能であるという長所がある。アーカイブされたデータは取り外し可能であるという長所があり，長期記憶を提供し，ハードドライブのような高コストのオンライン記憶サブシステムのスペースを空けることができる。

データを記憶するための別の方法は，アーカイブのためにテープにデータをコピーすることである。テープは迅速かつ即時のアクセスを提供しない。テープは通常，独自のバックアップフォーマットで書き込まれ，順次に検索され得るだけである。テープは，主記憶装置が故障したとき，まれで，起こりそうもないバックアップデータの取得用に設計されている。テープの非アクセス性だけでなく，永続性を意図していないメディアに重要なアーカイブを記憶するという危険性もある。テープはファイルを周期的かつ反復的に記録するために使用され，永続的に変わらない形式で価値のある固定された内容を維持するためのものではない。ある種の光メディアとは異なり，テープは，本来，追記型（ＷＯＲＭ）ではなく，磁気干渉のような周辺の影響に敏感である。したがって，テープは価値の高い内容のアーカイブに適していない。

本発明の実施形態は，光メディアライブラリに記憶されたデータへのアクセス及び圧縮の方法，システム及びコンピュータ可読媒体を含む。

一実施形態において，ハイブリッド記憶機器のシミュレーション層が，追記特性の光メディアの一つ以上のライブラリを，非追記特徴を有する一つ以上の論理ブロック装置のように認識されるようにする。別の実施形態において，メディアライブラリ機器によってユーザファイルからデータがチャンクに圧縮され，圧縮されたユーザファイル内で粗粒度探索（ｃｏａｒｓｅ ｇｒａｎｕｌａｒｉｔｙ ｓｅｅｋｉｎｇ）が可能である。別の実施形態において，ハイブリッド記憶機器によって，メディアクラウド（ｃｌｏｕｄ）が使用され，データの生成，復元，分散の際の光メディア，ライブラリロボット，光ドライブ及びネットワーク接続の故障を一貫して回復させる。

別の実施形態は，ライブラリ内でメディアタグ及びカートリッジリスト（ｍａｎｉｆｅｓｔｓ）によって光メディアを追跡するための方法，システム及びコンピュータ可読媒体を提供する。メディアカートリッジに付加されたリストは，カートリッジに含まれるメディアそれぞれについての具体的な情報を含む。また，メディアはそれぞれ連携するメディアタグを有し，該メディアタグはライブラリ内の当該メディアに付いて廻る。メディアタグは，例えば，メディアがある装置（例えばカートリッジ，ロボットスレッド又は光ディスクドライブ）のフラッシュに記憶される。

添付の図面は，本発明の実施形態を説明するためのものに過ぎない。当業者であれば，後述する原理から逸脱せず，下記で例示される構造及び方法の別の実施形態を容易に理解することができるであろう。

本発明の一実施形態によるハイブリッド記憶機器のソフトウェアの構造を示す図である。 本発明の一実施形態によって，論理ユニット番号（ＬＵＮ）レイヤを有するハイブリッド記憶機器を使用してデータを記録する動作を示す図である。 本発明の一実施形態によって，ＬＵＮレイヤを有するハイブリッド記憶機器を使用してデータを読み取る動作を示す図である。 本発明の一実施形態によるＬＵＮブロックマッピングを示す図である。 従来の汎用ディスクフォーマット（ＵＤＦ）配置の例を示す図である。 本発明の一実施形態によって変形されたＵＤＦ配置を示す図である。 本発明の一実施形態によって圧縮されたファイルを有するインクリメントを生成する方法を示す図である。 本発明の一実施形態によって，アーカイブされたファイル内の圧縮されたデータにアクセスする方法を示す図である。 本発明の一実施形態による光メディアのクラウドを示す図である。 本発明の一実施形態によるメディアタグ及び複数のカートリッジリストを示す図である。 本発明の一実施形態によってリストを生成する方法を示す図である。

＜論理ブロック装置のシミュレーション＞
ハイブリッド記憶機器（ＨＳＡ）のシミュレーション層は，追記（ＷＯＲＭ）特性を有する光メディアの一つ以上のライブラリを，非追記特性を有する一つ以上の論理ブロック装置のように見せることができる。一実施形態において，直接付加された論理ユニット番号記憶インタフェースがＨＡＳ上の論理データユニットにアクセスするために提供される。図１は，ＨＳＡのソフトウェア構造１０００の実施形態を示す。

ＨＡＳは，データパイプラインとして働く。パイプラインの一端はクライアントコンピュータがアクセスし，他端は光メディアである。一実施形態において，クライアントは，ネットワークファイルサーバ（ＮＦＳ）又は共用インタフェースファイルサーバ（ＣＩＦＳ）ファイル共有プロトコルを利用してパイプラインにデータを記録する。ネットワークファイルサーバデーモン（ＮＦＳＤ）及びサーバメッセージブロックデーモン（ＳＭＢＤ）ブロックは，キャッシュファイルシステム（ＸＦＳ）で表現されたキャッシュしたファイルシステムからデータを読み取り，又はデータを書き込み，ファイル提供プロトコルを処理する。キャッシュしたデータはハードディスクに記憶される。ファイルの生成時に変更されたＸＦＳがデータ移行アプリケーションプログラムインタフェース（ＤＭＡＰＩ）を介してコマンドコントロールデーモン（ＣＣＤ）にこのような試みを知らせる。ＣＣＤは，アクセスを許容若しくは拒否するか，又は必要なデータが利用できるまでアクセスを遅延するかを決定することができる。ＸＦＳでのファイルの生成中に，ＣＣＤはファイルがこれ以上変更されないまでファイルを監視する。このとき，ＣＣＤはファイルを変更できないことを表示する。次いで，ＣＣＤは，汎用ディスクフォーマット（ＵＤＦ）イメージクリエータであって，不変のファイルを，ＵＤＦクリエータによって進行中のＵＤＦファイルシステムインスタンスに追加する。ＵＤＦイメージクリエータは，不変のファイルをステージング領域に記憶されたＵＤＦファイルシステムイメージに書き込む。ＵＤＦファイルシステムイメージが満杯になると，ＵＤＦイメージクリエータは，シングルボードコンピュータデーモン（ＳＢＣＤ）に，ＵＤＦファイルシステムイメージを光ディスクにコピーすることを指示する。ＳＢＣＤは，ロボットを利用して適当な光ディスクをドライブに移動させ，コピー動作を行う。データが光ディスクに記憶されると，ＸＦＳに記憶されたデータのコピーは削除することができ，キャッシュに自由スペースが発生する。

将来，ＮＦＳ又はＣＩＦＳクライアントは，ＸＦＳから削除されたデータへのアクセスを所望するかもしれない。この場合，ＤＭＡＰＩは，ＸＦＳにないデータを光ディスクから取得する必要があることをＣＣＤに知らせる。ＣＣＤは，ＳＢＣＤに適当な光ディスクをドライブにロードし，必要なデータを読み取ってＣＣＤに送信することを指示する。ＣＣＤは，ＸＦＳにデータを記録し，必要なデータが再利用可能であることをＸＦＳに知らせる。ＸＦＳは，ＮＦＳＤ又はＳＭＢＤが要求したクライアントにデータのコピーを返す。

図１は，光ディスク記憶システム（ＯＤＳＳ）が外部世界，すなわち，ネットワーク共有，永続記憶スペース（ＰＳＳ），及びモニタリングによってアクセスされる３つの方法を例示している。多様な実施形態において，データを記憶及び取得するクライアントはネットワーク共有を使用し，ＯＤＳＳを構成するマネージャがＰＳＳを利用し，マネージャがモニタリングモジュールを介してＯＤＳＳを監視する。

ジュークボックスマネージャ（ＪＢＭ）は，光ディスクの位置及び光ディスクが使用状態にあるか，又は待機（ｉｄｌｅ）状態にあるかを追跡する。ＣＣＤが光ディスクにデータを書き込み，又は光ディスクからデータを読み取るとき，光ディスクへのアクセスのスケジュールをＪＢＭに相談する。ＪＢＭがアクセスを許容すると，ＣＣＤは，ＳＢＣＤが必要なアクセスを行うように指示する。アクセスが終了すると，ＪＢＭは関連した光ディスクを待機として表示し，該当のメディアを待っている別のアクセスのスケジュールを行う。

ＨＳＡの別の実施形態には，論理ボリュームマネージャ（ＬＶＭ）及び／又は冗長構成ディスク（ＲＡＩＤ）が含まれる。ＯＤＳＳは，ＬＶＭ及び／又はＲＡＩＤを使用して物理的ディスクドライブを集約し，大きな論理ディスクドライブとして取り扱って，一つのディスクドライブが故障することによるデータの損失を防ぐ。

図１に示すように，ソフトウェア構造１０００は，インターネット小型計算機システムインタフェース（ｉＳＣＳＩ）１４０，論理ユニット番号（ＬＵＮ）レイヤ１５０，及びＸＦＳファイルシステム１６０を備える。インタフェース１４０は，標準ディスクブロック装置ＳＣＳＩのコマンドを受信し，ＸＦＳファイルシステム１６０上に置かれたＬＵＮレイヤ１５０と通信する。ＬＵＮレイヤ１５０は，ＬＵＮをＨＳＡ永続記憶スペース（ＰＳＳ）にマップする。ＬＵＮ内の論理ブロックは，ＸＦＳファイルシステム１６０を通じてアクセスされ得るＨＳＡ ＰＳＳ内のファイルにマップされる。したがって，ｉＳＣＳＩ １４０は，ＨＳＡがクライアントにテープ装置ではなく標準ディスク装置のように認識されるようにする。ＨＳＡ ＰＳＳ内のファイルは，標準ディスク装置に記憶されたように生成，アクセス，編集，及び削除することができる。図２と図３は，ＬＵＮレイヤ１５０を有するＨＳＡからデータの読み取り又は書き込み動作を示す。

図２は，ＬＵＮレイヤ１５０を有するＨＳＡ ２３０を使用してデータを書き込む動作を示す図である。クライアントアプリケーション２２０は，書込みコマンド２２１を発行し，ＨＳＡ ２３０が書込みコマンド２２１を受信する。ＳＣＳＩコマンド記述子ブロック（ＣＤＢ）は，書込みコマンドをデータブロックにマップする（２３２）。ブロックは，ＰＳＳファイルにマップされるが（２３３），それは究極的に，メディアライブラリ内の光メディア記憶ディスク２４０に記録される（２３４）。ファイルシステムのファイル生成及び記録状態は，ファイル生成及び記録処理の結果として返却される（２３５）。その結果は，ブロック装置の記録のための標準のＳＣＳＩ仕様書に定義されているように，適当なＳＣＳＩエラー及びセンス（ｓｅｎｓｅ）コードにマップされる（２２７）。ＳＣＳＩエラー及びセンスコード２２７は，ＨＳＡ ２３０からクライアントアプリケーション２２０に伝送される。

図３は，ＬＵＮレイヤ１５０を有するＨＳＡ ２３０を使用してデータを読み取る動作についての実施形態を示す図である。クライアントアプリケーション２２０は，読み取りコマンド３３１を発行し，ＨＳＡ ２３０が読み取りコマンド３３１を受信する。ＳＣＳＩ ＣＤＢが読み取りコマンドを適当なデータブロックにマップする（３３２）。適当なデータブロックは，対応するＰＳＳファイルにマップされ（３３３），ＰＳＳファイルは，究極的にメディアライブラリ内の光メディア記憶ディスク２４０から読み取られる（３３４）。ファイルの読み取り状態及びファイルからのデータの読み取り状態が返却され（３３５），ブロック装置の読み取りのための標準仕様書に定義されているように，適当なＳＣＳＩエラー及びセンスコードにマップされる（３３６）。ＳＣＳＩエラー及びセンス並びにファイルから読み取られたデータ３３７は，ＨＳＡ ２３０からクライアントアプリケーション２２０に伝送される。

図４は，ＬＵＮブロックマッピングの実施形態を示す図である。ＬＵＮレイヤ１５０は，ブロックをＨＳＡ ＰＳＳにマップする。論理ブロックの要求は，ＸＦＳファイルのアクセスとして解釈される。一実施形態において，複数の連続ブロックは，一つのファイルにマップされる。例えば，図４に示すように，ＬＢＡ ０及びＬＢＡ １は一つのＸＦＳファイル“ｂｌｋ＿０＿ｖｅｒｓ＿０”にマップされる。ブロックに対する修正又は変更はファイルのバージョン付けによって処理される。ブロックが変更されると，バージョンが上がった新しいファイルが生成され，古いファイル／古いバージョンについての参照が削除される。したがって，ＬＢＡ １のデータが変更されると，更新されたデータを有する新しいファイル“ｂｌｋ＿０＿ｖｅｒｓ＿１”が生成され，古いファイルである“ｂｌｋ＿０＿ｖｅｒｓ＿０”についての参照は削除される。一実施形態において，ＬＵＮレイヤ１５０は，ファイルの最後のバージョンにだけアクセスし，したがって最新のバージョンのファイルにアクセスする。その結果，追記特性を有する光メディアのライブラリが，クライアントアプリケーションには非追記特性を有する一つ以上の論理ブロック装置として認識される。

＜ファイルの圧縮＞
一実施形態において，ユーザファイル内容は，メディアライブラリのＵＤＦアーカイブボリュームとして使用される際に圧縮される。ＵＤＦインクリメントの生成のためのファイルの圧縮時の問題点は，実際に圧縮しないと圧縮されたファイルのサイズを知ることができないということである。ファイルを圧縮するために，内容を読み取る必要があり，好ましくは，ファイルの内容を一回だけ読み取ってインクリメントを生成しなければならない。したがって，一実施形態において，ファイル内容を圧縮する動作は，圧縮されたデータを生成されるインクリメントに入れる。圧縮時の別の問題は，ユーザが大容量のファイルから一部のデータだけを取得することを所望するとき，大きい容量のデータを圧縮することが非効率的なことである。圧縮されたユーザファイル内で粗粒度探索が可能であるようにデータを圧縮することが好ましい。

図５は，従来のＵＤＦレイアウトの例を示す図である。ＵＤＦは，ＵＤＦファイルシステム内のディスクブロックのフォーマット及び配置を記述する標準である。図５において，複数のブロックは，ＵＤＦファイルシステム定義によって規定される領域であり，該定義は欧州電子計算機工業会１６７，すなわちＥＣＭＡ−１６７標準に記載されている。一実施形態において，ＵＤＦファイルシステム定義に加え，エラー訂正コード（ＥＣＣ）データとして参照されたブロックが，図５の最上部からＥＣＣデータが開始される位置まで，ＵＤＦファイルシステムに記録されたデータの検査合計（ｃｈｅｃｋｓｕｍ）を記憶する。検査合計の領域のブロックが損傷されると，光ドライブ及びメディアによって使用されるＥＣＣがデータの復元に不十分になって，ＥＣＣはデータの復元の別のレベルを試みるために使用される。図５に示すように，ファイルシステムメタデータは，圧縮されるユーザデータの前に記録される。

図６は，一実施形態による修正されたＵＤＦレイアウトを示す図である。一実施形態において，修正されたＵＤＦレイアウトによって，図６の最上部から開始されて，可能な限り連続して記録が行われる。ファイルシステムメタデータの内容は，ＵＤＦファイルシステムのユーザデータ領域に置かれるファイルのサイズによって定められる。データを圧縮するとき，圧縮されたサイズを予め知ることができない。したがって，データを２回圧縮することを回避するために，データは，ＵＤＦファイルシステムのユーザデータ領域に圧縮され，圧縮されたファイルのサイズは同時に得られる。したがって，ファイルシステムメタデータを生成するように圧縮されたユーザデータが，まずＵＤＦファイルシステムに記録される。図６に示すように，ＵＤＦファイルシステムインクリメントに圧縮されたデータのストリーミングを直接許容できるように，ユーザデータの位置はインクリメントのパーティション領域の開始点に移動される。圧縮されたユーザデータの後にファイルシステムメタデータがある。

歴史的に，インクリメントの生成ステップは２つのステップに分けられている。第１のステップは，凍結した（ｆｒｏｚｅｎ）ファイルに対するメタデータを収集し，対応するＵＤＦメタデータを木構造としてメモリに生成し，収集されているＵＤＦインクリメントが満杯になるまでその過程を繰り返す。大容量のファイルがインクリメントの空きスペースに入らないときは，インクリメントのサイズを再調整することができる。インクリメントが満杯になると，インクリメント用のディスクスペース（ディスクスペース内の適当な数のセクタ）が予め割り当てられ，ＵＤＦメタデータを合成し，ユーザファイルデータをインクリメントにコピーし，生成されたエラー訂正コードデータをインクリメントに記録することによって，ＵＤＦインクリメントが生成される。

図７は，一実施形態によって圧縮されたファイルを有するインクリメントを生成する方法７００を示す図である。インクリメント生成の歴史的な処理において変更された点は，インクリメントに入れる最初のファイルのサイズに少なくとも部分的に基づいて，ステップ７０１においてインクリメントのサイズが選択されることである。最初のファイルが所望のインクリメントのサイズより小さいときは，所望のインクリメントのサイズは，ファイルを追加して定められる。最初のファイルが所望のインクリメントのサイズより大きいときは，インクリメントのサイズはそのファイルを記憶できるように調整される。

ステップ７０２において，選択されたインクリメントのサイズによって，圧縮されるユーザデータを追跡するファイル集合記述子の番地を指定することができる。例えば，ファイル集合記述子の番地は，エラー訂正コードによって保護されるインクリメント内の最後の２セクタであってよい。

ステップ７０３において，インクリメントのサイズが固定され，インクリメントファイルのためのスペースが割り当てられると，ＵＤＦインクリメントファイルにユーザデータのプリアンブルが記録される。一実施形態において，プリアンブルは，図６における「圧縮ユーザデータ」の上の項目，すなわちボリューム認識シーケンスと，主ボリューム記述子シーケンスと，アンカボリューム記述子ポインタとを含む。

ステップ７０４において，ユーザファイルが読み取られ，圧縮され，ＵＤＦインクリメントに使用される。圧縮されたファイルの記録中に，ステップ７０５において，メモリに含まれているＵＤＦメタデータは，ファイルの位置及びファイルディレクトリ情報によって更新される。一実施形態において，それぞれのファイルに対する圧縮されたチャンクディレクトリが生成されてＵＤＦメタデータに記録される。インクリメントにファイルが追加されるにつれて，いずれ，次のファイル及びメタデータを保持する十分なスペースがない時点が来る。次のファイル及びメタデータを収容する十分なスペースがインクリメントに残っていないときは，ステップ７０６においてＵＤＦメタデータがインクリメントに記録される。

ＵＤＦメタデータがインクリメントファイルに記録された後，ステップ７０７において，ＵＤＦ情報の後端が書き込まれる。一実施形態において，ＵＤＦ情報の後端は，図６における「ファイルシステムメタデータ」の下の項目，すなわちファイル集合記述子と，エラー訂正コードデータと，予備ボリューム記述子シーケンスと，アンカボリューム記述子ポインタと，仮想割当テーブルファイルエントリとを含む。ＵＤＦ情報の後端が書き込まれた後，インクリメントが完了する。

一実施形態において，ファイルは，所定のサイズ，例えば，６４メガバイトのチャンクに圧縮される。一実施形態において，ファイル内容は一般的に６４メガバイトのチャンクで呼び出される（ｒｅｃａｌｌｅｄ）ため，６４メガバイトのチャンクは好ましいサイズである。しかし，６４メガバイトより大きいか，又は６４メガバイトより小さいチャンクを使用してもよい。ユーザファイルの圧縮は，ファイルから６４メガバイト（又は６４メガバイトより小さいサイズ）を読み取り，チャンクを別のバッファに圧縮し，圧縮された結果をＵＤＦインクリメントに記録することを含む。このような処理は，ファイルが完全にインクリメントに含まれるまで繰り返される。チャンクを圧縮しようとしたが６４メガバイトより大きいチャンクになったときは，圧縮されていないデータがインクリメントに記録される。最終の目的は，アーカイブメディア上のセクタを節約することであるから，ファイルを圧縮したとき，圧縮を正当化するようにスペースが少なくとも一つのセクタ（一実施形態においては２０４８バイト）の節約になることが望ましい。そうでなければ，データは圧縮されていない状態でアーカイブされる。

（圧縮又は非圧縮の）ファイルの６４メガバイトチャンクはそれぞれ，圧縮されたチャンクディレクトリ内に記憶されたファイルの開始点に対するバイトオフセットを有する。ステップ７０５に関して説明したように，それぞれのファイルは，圧縮されたチャンクディレクトリを有し，圧縮されたチャンクディレクトリは，例えば，ファイルのＵＤＦ拡張属性に記憶される。圧縮されたチャンクディレクトリは，ファイルを呼び出す際に圧縮されたアーカイブファイル内の任意の６４メガバイトチャンクの位置を迅速に決定するために使用される。

図８は，一実施形態によってアーカイブファイル内の圧縮されたデータにアクセスする方法８００を示す図である。ステップ８０１において，圧縮されたデータを記憶するアーカイブメディアのボリューム識別子（ＩＤ）がアーカイブファイルから得られる。一実施形態において，アーカイブファイルはそれぞれ，ファイルを含むＰＳＳ用のＸＦＳ内にスタブを有する。一実施形態において，スタブは，光メディアからファイルデータを復元するために必要な情報を有し，拡張属性を有する同じ名称の，長さ０のファイルである。この情報は，ボリューム（データが書き込まれた光ディスク）のリスト及びボリュームごとのファイルの範囲（ｅｘｔｅｎｔ）のリストを含む。範囲はそれぞれ，光メディア上の位置及びサイズを詳細に記述する。

圧縮に加えて，呼び出そうとする圧縮されたデータがファイルの圧縮されたデータ内のどこに位置するかを知る必要がある。ステップ８０２において，所望の圧縮されたデータの位置はチャンクディレクトリから得られる。前述のように，圧縮されたファイルごとのＵＤＦ拡張属性に，圧縮されたチャンクディレクトリがある。ファイル呼出コードが圧縮されたチャンクディレクトリに迅速に到達するように，一実施形態において，チャンクディレクトリの位置がファイル用のＸＦＳ拡張属性に記憶される。一実施形態においては，バッファを使用して，圧縮されたチャンクディレクトリを保持する。呼出処理は，拡張属性内で指示された圧縮されたチャンクディレクトリで読取りを行う。そして，圧縮されたデータを記憶するアーカイブセクタを識別することができる。

ステップ８０３において，識別されたセクタ内の圧縮されたデータが伸張される。アーカイブファイルの内容を呼び出すステップは，ファイルが圧縮されているとき，内容の伸張を必要とする。圧縮されたファイルは，圧縮されたチャンクディレクトリの存在によって検出される。一実施形態において，ディレクトリが存在しないとき，そのファイルは圧縮されていないと推定される。一実施形態において，圧縮は６４メガバイトチャンクで行われ，二つの６４メガバイトバッファがファイル呼出処理のために使用される。一つは圧縮されたデータを記憶し，他の一つは伸張されたデータを記憶する。

前述のユーザデータを圧縮し，圧縮されたユーザデータにアクセスする処理は，周知の多くの圧縮アルゴリズムと互換性を有し，補完的である。一実施形態において，ＬＺＯ圧縮アルゴリズムが使用される。ＬＺＯ圧縮アルゴリズムは，ｈｔｔｐ：／／ｗｗｗ．ｏｂｅｒｈｕｍｅｒ．ｃｏｍ／ｏｐｅｎｓｏｕｒｃｅ／ｌｚｏから得ることができる。

＜メディアクラウドからの一貫した回復＞
ハイブリッド記憶機器（ＨＳＡ）は，非常に大きなファイルコレクションにオンラインのアーカイブアクセスを提供する。一実施形態において，ファイルは光メディアのクラウド内に多様な形態で分散されている。クラウドは，ＷＡＮ／ＬＡＮを介したＨＳＡ，すなわち姉妹（ｓｉｓｔｅｒ）ＨＡＳに局所的に付加されているか，遠隔で接続されているライブラリに保存された光メディア全体を示す。基本的な光メディアの性質は，冗長性及び自動エラー回復用の伝統的な技術を使用することを許容しない。従来のファイルシステムは，ミラーリング及びパリティドライブのような多様なレベルのＲＡＩＤを考慮したブロック装置によってバックアップされる。ＨＡＳは，ファイル単位の光メディアによってバックアップされ，ライブラリ及び光メディアにまたがるデータの生成，復元及び分散のために，ネットワーク接続，光メディア，ライブラリロボット及び光ドライブにおける故障から一貫して回復させるために別の技術が使用される。

図９は，光メディアのクラウド１００についての実施形態を示す図である。メディアクラウド１００は，局在する（ｌｏｃａｌ）複数のライブラリと，姉妹ＨＡＳを介して遠隔で接続されたライブラリとを備える。図９に示すように，クラウド１００は，局所的に付加されたライブラリ１１１及び１１２を有するＨＳＡサーバ１１０と，付加されたライブラリ１２１及び１２２を有する遠隔ＨＳＡサーバ１２０とを含む。遠隔ＨＳＡサーバ１２０は，ＨＳＡサーバ１１０と通信ネットワーク１０１を介して接続される。一実施形態において，通信ネットワーク１０１はＷＡＮ又はＬＡＮであり，別の実施形態において，通信ネットワーク１０１はイントラネット又はインターネットである。一実施形態において，クラウド１００の一部に問題が発生すると，要求は，その要求が満たされるように通信ネットワーク１０１を介してクラウド１００の別の部分に差し向けられる。

ファイル記憶に関して，ファイルは，まずサーバ上のフロントエンドファイルシステムキャッシュに現れる。ファイルが凍結されて，光メディアへ移行できると記されるまで，待機時間がある。図７を参照して説明したように，一つのファイル，一つのファイルの一部，又は二つ以上のファイルを含むインクリメントが生成される。インクリメントが用意されると，ライブラリと，一つのメディアと，光ドライブとがインクリメントを書き込むために選択される。一つのメディアは，１又は複数のインクリメントを含むことができる。インクリメントは，冗長性のために２以上のメディアに書き込むことができる。そして，メディアはメディアクラウドの任意の場所に配置することができる。

ファイルがインクリメントに置かれると，ファイルはシステムから削除され，そのファイルが次にアクセスされるときに，フロントエンドキャッシュにファイルの復元を開始させるスタブが残る。前述のように，一実施形態において，スタブは，光メディアからのファイルデータの復元に必要な情報を有する拡張属性を有する，同じ名称の，長さ０のファイルである。この情報は，ボリューム（データが書き込まれた光ディスク）のリストと，ボリュームごとのファイル範囲のリストとを含む。範囲はそれぞれ，光メディアにおける位置及びサイズを詳細に記述する。

書き込み過程で故障が発生すると，新しい組合せのライブラリ，メディア及び光ドライブが選択され，一つ又はそれ以上のインクリメントのコピーが作成されるまで処理が続く。一実施形態において，メディアクラウド１００におけるデータの最終位置は，一般的にＨＳＡサーバ１１０のユーザには知らされない。

フロントエンドファイルシステムキャッシュを介してファイルへのアクセスが要求されると，メディアクラウド１００からファイルが復元される。ファイルスタブアクセスは，メディアクラウド１００への要求を発生させる。資源可用性に基づき，そのファイルを記憶するメディアが選択される。ファイルが一つのメディア上にあるときは，判断すべきことは，単にいつそのメディアを利用可能なドライブへロードするかをスケジュールすることである。メディアがクラウド１００の複数の位置にあるときは，局所ライブラリ１１１及び１１２に比べた遠隔ライブラリ１２１及び１２２の選好度，並びにライブラリ及び／又はライブラリ内のドライブの可用性に基づいて判断される。

このメディアへのアクセスを試みて失敗したときは，クラウドは，自動的に新しい組合せのライブラリ，ドライブ，及び光メディアを選択する。一実施形態において，自己回復メディアクラウド１００は次の特徴を有する。

・失敗した要求は，前の要求が停止したところから開始される。データが前のメディア組合せから得られたときは，そのデータが使用され，現在のメディア組合せからは再度読み出されない。これによって時間が節約され，処理資源が温存される。

・ドライブが故障したときは，同じライブラリ内の別のドライブにメディアが移動する。

・ライブラリが故障したときは，メディアのコピーを含む別のライブラリに要求が転送される。

・メディアが故障したときは（例えばディスクが不良になったときは），当該メディアの別のコピーが使用される。故障したメディアは無効にされ，それと交換するために当該メディアの新しいコピーを生成してもよい。

データがサーバのフロントエンドキャッシュに到着すると，データはデータの本来の要求者に返送される。最終ユーザは，ユーザの要求がどのようにメディアクラウド１００によって実行されたかを知らされる必要もないし，知る必要もない。若干の非活性期間の後に，そのファイルの内容はフロントエンドキャッシュから削除され，スタブによって置き換えられる。一実施形態において，この削除の際に如何なるデータも光メディアに書き込まれない。

メディアクラウド１００は，ライブラリ及び光メディアにまたがるデータの生成，復元及び分散に関して，自動故障時引継ぎ（ｆａｉｌ ｏｖｅｒ）を提供する。メディアクラウド１００は，ライブラリと，ドライブと，光メディアとにおける故障から回復することができ，メディアクラウドの動作は，ＨＳＡの最終ユーザには気付かれない（ｔｒａｎｓｐａｒｅｎｔ）ものであってよい。

＜メディアタグ及びリストによるライブラリ内のメディア追跡＞
一実施形態において，ＨＳＡは，ライブラリ内の５００枚のメディアに対応する。このメディアは，記憶カートリッジと，ディスク移送アセンブリと，メディアドライブとを含むライブラリ内の５１４箇所の間を移動する。光メディアは通常，ライブラリから頻繁に出入りする小さなカートリッジ（例えば２５スロット）又はバルクカートリッジ（例えば２２５スロット）内にある。各ディスクをロードし，その内容を読み取ることは，その構成によっては２時間以上掛かることがあるため，ディスク内容の要約と共に，ライブラリ内の各ディスクの位置を追跡する機構が使用される。このような情報はまた，カートリッジをライブラリに出し入れするときに，カートリッジ内のディスクに付いて廻る。

カートリッジが含むメディアごとの詳細情報を有するリストが，カートリッジ単位に生成される。一実施形態において，リストは，メディアカートリッジの本体に物理的に付加された，例えばフラッシュ装置内で維持される。別の記憶メカニズム又はメモリ装置も使用することができる。一実施形態において，フラッシュ装置はまた，ライブラリ内の光ドライブと，カートリッジのスロットと光ドライブとの間のメディアの移送に使用されるロボットスレッドの本体と，にも付加することができる。各メディアは，ライブラリ内のメディアについて廻る，連携するメディアタグを有する。メディアは，カートリッジ，ロボットスレッド又は光ドライブに存在することができる。メディアタグは，フラッシュに記憶されるか，現在当該メディアがある装置（例えば，カートリッジ，ロボットスレッド又は光ディスクドライブ）にある別の記憶媒体に記憶される。

図１０は，一実施形態によるメディアタグ１００１及び複数のカートリッジリスト１０１０を示す図である。一例として，メディアタグ１００１は，メディアタグが有効であるか否かを示す情報と，メディアタグがカートリッジリスト１０１０のエントリにマップされるか否かを示す情報と，メディアタグ１００１と連携するメディアについての詳細情報を有するリストエントリを含むカートリッジリスト１０１０を有するカートリッジ位置１００４に対する指示子と，メディアタグ１００１と関係付けられたメディアについての詳細情報を有するエントリが発見され得るリストでの位置を示す，カートリッジリストに対するインデクス１００５と，含む。カートリッジリスト１０１０は，当該カートリッジ内の各メディアに対応するエントリを含む。一実施形態において，リストエントリは，カートリッジ内の特定のスロットには結び付けられず，その代わりにメディアタグによってメディアと関係付けられる。

図１１は，一実施形態によってリスト１０１０を生成する方法を示す図である。カートリッジは，初期化されていない状態でライブラリに導入される。ステップ１１０１において，初期化されていないカートリッジに関して，リスト及びメディアタグがないことが検出される。ステップ１１０２において，初期化されていないカートリッジ用に空のリスト１０１０が生成されて，カートリッジに付加された，例えばフラッシュ装置に記憶される。ステップ１１０３において，カートリッジ内のスロットごとにディスクの存否に関する調査が行われる。すべてのスロットに有効１００２を示すタグが与えられ，マップされていない状態になる。これは，スロットにメディアがあるが，まだ調査されていないことをライブラリに示す。ステップ１１０４において，まだ調査されていない各メディアがドライブにロードされ，その内容を判定するために調査される。そして，ステップ１１０５において，調査されたディスクがドライブからカートリッジに戻されたとき，カートリッジリスト１０１０内にリストエントリが割り当てられ，更新される。ステップ１１０４及びステップ１１０５は，すべてのディスクが更新されたリストエントリを有するまで繰り返される。リストエントリの位置は，新たな「マップ済み」１００３を示すメディアタグの生成に使用され，当該メディア用のメディアタグ１００１が更新される。

一実施形態において，ライブラリは，起動時にライブラリにあるすべてのメディアに関して棚卸し（ｉｎｖｅｎｔｏｒｙ）を行う。この目録（ｉｎｖｅｎｔｏｒｙ）は，カートリッジと，ロボットスレッドと，ドライブとにある多様なフラッシュ装置の内容から生成される。カートリッジについては，リストエントリ１０１０及びメディアタグ１００１がカートリッジフラッシュ内にあり，それによってカートリッジがライブラリから取り外され又は置き換えられても，目録へ即時アクセスすることができる。棚卸しの結果，連携するメディアタグ１００１と共にメディアの位置を示すマップがライブラリに与えられる。メディアがメディアタグ１００１を有する場合には，対応するリストエントリはカートリッジフラッシュから検索される。このような初期棚卸し処理は非常に迅速に行われ，ディスクをドライブにロードするか，ディスクを特定の位置に登録する必要がない。

一実施形態において，正常な動作中に，リストエントリは，ディスクがドライブにある（例えば，メディアにデータが記録される）間に行われる動作によってだけ修正される。しかし，単に内容を読み取るためにドライブにディスクをロードすることは，リストの内容を変更しない。ディスクがドライブにある間にディスクに対する動作が行われた後，メディアの現在の状態は，ロードされていないときのリスト内のメディアの記録された状態と比較される。両方の状態が相異なる場合，リスト１０１０は，現在の状態を反映するように更新される。前述のように，リストエントリは，カートリッジ内の特定のスロットに結び付けられず，その代わりにリストエントリは，メディアタグ１００１によってメディアと関係付けられる。これによって，リストエントリを変更せずに，カートリッジと，ロボットスレッドと，光ディスクドライブとの中を，メディアが自由に移動できるようになる。

実施形態において，正常動作中は，メディアタグ１００１は次の状況を除いて変更されない。

・新しいディスクがスロットに現れたとき。前述のように，新しいディスクがカートリッジに追加されると，メディアタグ１００１はマッピング情報なし１００３で有効１００２として設定される。

・まず，新しいディスクが調査され，リストエントリが割り当てられるとき。メディアタグ１００１はマッピング情報１００３を含み，マッピング情報１００３はカートリッジリスト１０１０のエントリを示すように設定される。メディアタグ１００１用のカートリッジ位置１００４及びリストインデクス１００５もこのときに更新することができる。

・ディスクがあるカートリッジから別のカートリッジに移動するとき。リストエントリが元のカートリッジから目的のカートリッジにコピーされる。元のリストエントリは空きになる。メディアタグ１００１は，目的カートリッジのカートリッジ位置１００４と，目的カートリッジ内のリストエントリのリストインデクス１００５内の新しい位置とを示すように修正される。

・カートリッジがライブラリで置き換えられるとき。メディアタグ１００１は，ライブラリ内の位置１００４に基づいて親（ｐａｒｅｎｔ）カートリッジを追跡する。ライブラリから出入りするとき，カートリッジの位置が変更されることがあるため，メディアタグ１００１は，誤ったカートリッジの位置を示し始めることがある。一実施形態において，ライブラリは，まず，カートリッジの棚卸しをするとき，メディアタグ１００１が正確なカートリッジの位置１００４を参照するか否かを確認する。メディアタグ１００１が正確なカートリッジの位置１００４を参照していないときは，メディアタグ１００１はライブラリ内の新しいカートリッジの位置を反映するように更新される。したがって，カートリッジをライブラリ内の新しい位置に移動させることは，目録には大きな影響がない。

メディアタグ１００１は，これまで詳細に説明した特定の状況を除いて，正常動作中は変更されないため，メディアタグ１００１及びリストを更新する頻度は変更可能（ｍａｎａｇｅａｂｌｅ）である。したがって，メディアタグ及びカートリッジリストは，メディアがライブラリに搬入され，内部を移動し，搬出されるとき，ライブラリ内のメディアの追跡に便利な機構を提供する。

＜その他の考慮事項＞
上記の説明は実施形態の動作を例示するためのものであって，本発明の範囲を制限することを意図するものではない。上記の説明からこの分野の当業者にとっては多様な変形が明らかであり，また，当業者は明細書の教示から別の実施形態を認識するであろう。部品の特定の命名法，用語の大文字化，属性，データ構造又は別のプログラミング若しくは構造の態様は強制的又は重要ではなく，特徴を具現するメカニズムは，別の名称，フォーマット，プロトコルを有することができる。また，明細書に記載された多様なシステム要素間の相関関係の特定の分離は単に例示のためのものであって，強制されず，一つのシステム部品によって実行される機能を複数の部品によって実行してもよいし，複数の部品によって実行される機能を一つの要素によって実行してもよい。

本明細書に提示された方法及び動作は，特定のコンピュータ又は装置に固有に関連していない。このような多様なシステムに対して要求される構造は，均等な変換物と共にこの分野の当業者には明らかである。また，実施形態は，特定のプログラム言語を参照して説明されない。多様なプログラム言語を明細書に記載された教示を行うために使用してもよく，特定の言語に対する参照は，開示された最良の実施形態を実現するために提供される。

開示された実施形態は，非常に多様なトポロジのコンピュータネットワークシステムに適する。この分野で，大きなネットワークの構成及び管理は，インターネットのようなネットワークを介して別のコンピュータ及び記憶機器に通信で接続された記憶機器及びコンピュータを含む。

明細書で使用された文言は，主に可読性及び教示のために選択されたものであり，発明の主な特徴を制限するために選択されたものではない。したがって，記載内容は例示のためのものであり，発明の範囲を制限するものではない。

Claims (19)

1. 追記（ＷＯＲＭ）特性を有する光メディアのライブラリを利用して非追記型論理ブロック装置をシミュレーションする方法において，
   小型計算機システムインタフェース（ＳＣＳＩ）プロトコルのコマンドを受信し，論理ブロックを参照する前記コマンドを前記論理ブロックを含む現在バージョンのファイルにマップする論理ユニット番号レイヤを提供するステップであって，前記ファイルは前記追記特性を有する光メディアのライブラリに記憶される，ステップと，
   前記論理ブロックへの修正を受信するステップと，
   前記の修正された論理ブロックを含む新しいファイルを生成するステップであって，前記新しいファイルはバージョンが上がっており，前記上がったバージョンが前記ファイルの現在バージョンになる，ステップと，
   前記新しいファイルを前記光メディアのライブラリに記憶するステップと，
   を有する方法。
2. 前記ファイルの前のバージョンへの参照を削除するステップを更に有する請求項１に記載の方法。
3. 前記ファイルはキャッシュファイルシステム（ＸＦＳ）ファイルである，請求項１に記載の方法。
4. 前記ファイルは，複数の連続する論理ブロックを含む，請求項１に記載の方法。
5. アーカイブ記憶のためにデータを圧縮する方法において，
   インクリメントに含まれるべき第１ファイルのサイズに少なくとも部分的に基づいて，インクリメントサイズを選択するステップと，
   データのファイルをチャンクに圧縮するステップと，
   圧縮されたチャンクを前記インクリメントに書き込むステップと，
   圧縮されたユーザファイルの位置及びファイルディレクトリ情報によって，メモリ内のメタデータを更新するステップと，
   前記メタデータを前記インクリメントに書き込むステップと，
   を有する方法。
6. 前記第１ファイルのサイズに少なくとも部分的に基づいて，インクリメントサイズを選択する前記ステップは，前記第１ファイルが所望のインクリメントサイズより大きくなったとき，前記ファイルを含むように前記インクリメントサイズを増加させる，請求項５に記載の方法。
7. 前記ファイルディレクトリ情報は，前記インクリメント内のファイルごとに圧縮チャンクディレクトリを有し，前記ファイルの開始点に対するバイトオフセットは，対応する圧縮チャンクディレクトリに記憶される，請求項５に記載の方法。
8. メディアクラウドからデータを復元する方法において，
   フロントエンドファイルシステムキャッシュにおいてデータのファイルを受信するステップと，
   前記ファイルを少なくとも一つの光メディアのインクリメントに記憶するステップと，
   前記フロントエンドファイルシステムキャッシュから前記ファイルを削除するステップと，
   前記フロントファイルシステムキャッシュに前記ファイルに関するスタブを記憶するステップであって，前記スタブは，前記の記憶されたファイルと同じ名称を有し，前記光メディア上の前記記憶されたファイルの一つ以上の記憶位置を識別する拡張属性を有するファイルを有し，
   前記フロントファイルシステムキャッシュを介して，前記記憶されたファイルにアクセスする要求を受信するステップと，
   前記スタブによって識別される前記光メディア上の記憶位置にある前記記憶されたファイルにアクセスするステップと，
   を有する方法。
9. 前記拡張属性は，前記光メディア上の前記記憶されたファイルの複数の記憶位置を識別し，前記光メディア上の記憶位置にある前記記憶されたファイルにアクセスする前記ステップは，
   記憶ライブラリと，一つの光メディアと，光ドライブとの第１の組合せによって，前記記憶されたファイルの第１部分を読み取るステップと，
   前記第１の組合せが，前記記憶されたファイルの第２部分を読み取ることに失敗したとき，記憶ライブラリと，一つの光メディアと，光ドライブとの第２の組合せによって前記記憶されたファイルの第２部分を読み取るステップと，を有し，
   前記第２の組合せは第１の組合せと異なり，前記第２の組合せは前記第１の組合せが読み取った前記記憶されたファイルの第１部分を読み取らない，請求項８に記載の方法。
10. 前記スタブによって識別される前記光メディア上の記憶位置にある前記記憶されたファイルにアクセスする前記ステップは，
    前記記憶されたファイルを読み取るために，記憶ライブラリと，一つの光メディアと，光ドライブとの第１の組合せを選択するステップと，
    前記読取りの完了を妨げる前記光ドライブの故障に応答して，前記読取りを完了させるために，前記一つの光メディアを前記記憶ライブラリ内の別の光ドライブに移動させるステップと，を有する請求項８に記載の方法。
11. 前記拡張属性は，前記光メディア上の前記記憶されたファイルの複数の記憶位置を識別し，
    前記スタブによって識別される前記光メディア上の記憶位置にある前記記憶されたファイルにアクセスする前記ステップは，
    前記記憶されたファイルを読み取るために，記憶ライブラリと，一つの光メディアと，光ドライブとの第１の組合せを選択するステップと，
    前記読取りの完了を妨げる前記光ドライブの故障に応答して，別のライブラリ内の光メディア上の前記記憶されたファイルの別の記憶位置にある前記記憶されたファイルにアクセスするステップと，を有する請求項８に記載の方法。
12. 前記要求に対応して，前記記憶されたファイルを配信するステップと，
    前記フロントエンドファイルシステムキャッシュから前記記憶されたファイルを削除し，前記記憶されたファイルを前記スタブで置き換えるステップと，を更に有する請求項８に記載の方法。
13. 光メディアライブラリ記憶機器内の複数の光メディアを含むカートリッジのリストを管理する方法において，
    前記カートリッジ内の光メディアごとに，前記光メディアの内容についての詳細な情報を有するリストエントリを生成するステップであって，メディアタグと連携する各光メディアは対応するリストエントリにマッピングされる，ステップと，
    光メディアがドライブからアンロードされたとき，前記光メディアの現在状態と，前記メディアタグによって識別される対応するリストエントリ内の前記光メディアの記録された状態とを比較するステップと，
    前記現在状態と前記記録された状態とが相異なる場合，前記現在状態を反映するように前記対応するリストエントリを更新するステップと，
    を有する方法。
14. 前記リストエントリは，前記カートリッジ上のフラッシュ装置に記憶される，請求項１３に記載の方法。
15. 前記光メディアライブラリ記憶機器は，少なくとも一つのカートリッジと，少なくとも一つのディスク移送アセンブリと，少なくとも一つのメディアドライブとを備え，前記カートリッジと，ディスク移送アセンブリと，メディアドライブとはそれぞれメモリ装置を含み，前記メモリ装置は前記のカートリッジ，ディスク移送アセンブリ又はメディアドライブに現在存在する光メディアそれぞれと連携するメディアタグを記憶する，請求項１３に記載の方法。
16. 前記光メディアライブラリ記憶機器にカートリッジが挿入されたとき，前記リストにアクセスして，前記カートリッジの内容の棚卸しを実行するステップを更に有する請求項１３に記載の方法。
17. 一つの光メディアが元のカートリッジから目的のカートリッジに移動されたとき，前記元のカートリッジのリストから前記一つの光メディアに関するリストエントリを削除するステップを更に有する請求項１３に記載の方法。
18. 前記メディアタグは，前記一つの光メディアのリストエントリを有するカートリッジに対応するカートリッジ位置の指示を有する，請求項１３に記載の方法。
19. カートリッジが前記光メディアライブラリ記憶機器内の第１カートリッジ位置から取りはずされて，第２カートリッジ位置に挿入されたとき，前記カートリッジがリストエントリを有する光メディアそれぞれのメディアタグ内の前記カートリッジ位置の指示を更新する請求項１８に記載の方法。

Images