(57)【特許請求の範囲】
【請求項１】
データ・ファイルを保管するためのキャッシュ・メモリとして使用される不揮発性メモリであって、前記キャッシュ・メモリの少なくとも一部が、先入れ先出しポリシー管理を使用して管理される第１の領域と、最長未使用時間ポリシー管理を使用して管理される第２の領域とを含む、不揮発性メモリと、
テープ・ドライブ・システム上に保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースとしての、前記データ・ファイルをテープ上に順次方式で読み書き保管するＬＴＦＳと、
１つまたは複数のリモート・システムが前記ファイル・システム・インターフェースの記憶手段あるいは前記キャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースとを含む、テープ・ドライブ・システム・サーバであって、
前記サーバが、前記ファイル・システム・インターフェース（ＬＴＦＳ）を含み、
前記テープ・ドライブ・システムおよび前記キャッシュ・メモリに１つまたは複数のデータ・ファイルを書き込むための１つまたは複数の書き込み要求を前記１つまたは複数のリモート・システムから受信し、
前記ファイル・システム・インターフェース（ＬＴＦＳ）により、前記テープ・ドライブ・システムおよび前記キャッシュ・メモリに前記１つまたは複数のリモート・システムによって書き込むよう指示されたデータ・ファイルに関連付けられた属性を解釈し、データ・ファイルのキャッシング優先順位クラスを確保し、
前記キャッシング優先順位クラスに応じて前記リモート・システムによって書き込むよう指示されたデータ・ファイルを保管する、
ように構成される、テープ・ドライブ・システム・サーバ。
【請求項２】
前記ファイル・システム・インターフェース（ＬＴＦＳ）は、前記データ・ファイルに関連する前記属性を解釈するためのキャッシュ管理機能を含む、請求項１記載のテープ・ドライブ・システム・サーバ。
【請求項３】
前記属性がキャッシング優先順位クラスに対応する、請求項２記載のテープ・ドライブ・システム・サーバ。
【請求項４】
第１のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
書き込むよう指示されたデータ・ファイルを前記キャッシュ・メモリの前記第１の領域に書き込むことと、
その後、前記第１の領域に保管されたデータ・ファイルをテープ・ドライブ・システムにコピーすることであって、前記コピーが前記サーバのバックグラウンド・タスクとして実行されることと、
前記コピーが終了した後に、前記キャッシュ・メモリの前記第１の領域からデータ・ファイルを追い出すこと
を実行させる、請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項５】
第２のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
書き込むよう指示されたデータ・ファイルを前記キャッシュ・メモリの前記第１の領域に書き込むことと、
その後、前記第１の領域に保管されたデータ・ファイルをテープ・ドライブ・システムにコピーすることであって、前記コピーが前記サーバのバックグラウンド・タスクとして実行されることと、
前記第１の領域に書き込まれた前記データ・ファイルの第１の読み取り後に、前記データ・ファイルが１回または複数の追加回数読み取られるかどうかを判断することと、
前記データ・ファイルが１回または複数の追加回数読み取られると判断された場合に、前記キャッシュ・メモリの前記第２の領域に前記データ・ファイルを移動することと、    前記データ・ファイルが１回または複数の追加回数読み取られると判断されない場合に、前記キャッシュ・メモリの前記第１の領域からデータ・ファイルを追い出すこと
を実行させる、請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項６】
第３のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
前記キャッシュ・メモリの前記第１の領域上で、前記キャッシュ・メモリの前記第１の領域に前に保管された１組のデータ・ファイルをプリフェッチすることと、
前記プリフェッチされた１組のデータ・ファイルの第１の読み取り後に、前記プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られるかどうかを判断することと、
前記プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られると判断された場合に、前記キャッシュ・メモリの前記第２の領域に前記１組のデータ・ファイルを移動すること、を実行させる、
請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項７】
第４のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
前記キャッシュ・メモリの前記第２の領域上で、前記キャッシュ・メモリの前記第１の領域に前に保管された１組のデータ・ファイルをプリフェッチすることを実行させる、
請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項８】
第５のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
データ・ファイルへの複数の読み出しアクセスによりテープからキャッシュ・メモリにフェッチされたシーケンシャルなテープイメージの最大オフセットまで前記キャッシュ・メモリの前記第２の領域内にデータ・ファイルを入れること、
を実行させる、請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項９】
第６のキャッシング優先順位クラスが、前記キャッシュ管理機能により、
データ・ファイルがアクセスされるかどうかとは無関係に、データ・ファイルにキャッシング優先順位クラスが設定されたときに、前記キャッシュ・メモリの前記第１の領域内に直ちにデータ・ファイルを入れることと、
構成可能な時間間隔が満了したときに、前記キャッシュ・メモリからデータ・ファイルを追い出すこと
を実行させる、請求項２および３の何れか１項記載のテープ・ドライブ・システム・サーバ。
【請求項１０】
キャッシング・クラスがユーザまたはアプリケーションのいずれか一方によって指定され、
それに関するキャッシング・クラスが前記ユーザまたは前記アプリケーションによって指定されていないデータ・ファイルについて前記キャッシュ管理機能がデフォルト・キャッシング・クラスをさらに割り当てる、請求項３ないし９の何れか１項に記載のテープ・ドライブ・システム・サーバ。
【請求項１１】
前記属性が拡張属性であり、そのフォーマットが前記データ・ファイルの所与のデータ・フォーマットと互換性がある、請求項１ないし１０の何れか１項に記載のテープ・ドライブ・システム・サーバ。
【請求項１２】
複数のユーザによる並行した同時データ書き込みあるいは読み取りまたはその両方を最適化するためにデータ・ファイルに関連する属性が前記キャッシュ管理機能によって使用される、請求項２ないし１０のいずれかに記載のテープ・ドライブ・システム・サーバ。
【請求項１３】
請求項１ないし１２のいずれか１項に記載のテープ・ドライブ・システム・サーバと、
前記サーバがそれとのインターフェースが取られているテープ・ドライブ・システムと
を含む、テープ・アプライアンス・システム。
【請求項１４】
請求項１ないし１２のいずれか１項に記載のテープ・ドライブ・システム・サーバまたは請求項１３記載のテープ・アプライアンス・システムを含むシステムであって、前記テープ・ドライブ・システムがテープ・ライブラリである、システム。
【請求項１５】
請求項２ないし１２の何れか１項に記載のテープ・ドライブ・システム・サーバにキャッシュ管理機能を実行させるためのコード手段を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テープ・ドライブ・システムに関するキャッシュ・アーキテクチャの分野に関し、具体的にはテープ・ドライブ・システム・サーバに関する。
【背景技術】
【０００２】
過去数年にわたるＨＤＤ（ハードディスク・ドライブ）技術の著しい進歩にもかかわらず、磁気テープ・システムは、現在の層化ストレージ・インフラストラクチャの不可欠な部分を構成している。テープ技術は、低コスト、バックアップならびに災害復旧目的のためのデータの長期保管、省エネ、セキュリティ、耐用年数、および信頼性を含む、いくつかの重要な利点を提供している。
【０００３】
データがテープ・システムに記録されると、その媒体は受動的なものになる。これは、その媒体が単純にラック内に置かれ、いかなる電力も不要であることを意味する。同様のディスクベースのシステムと比較して、テープベースのアーカイブは約２９０倍も少ない電力を消費する。セキュリティの点では、データが記録され、カートリッジがアクセス・システムから除去されると、カートリッジがアクティブ・システムに再設置されるまで、データはアクセス不能になる。セキュリティはドライブレベルの暗号化によってさらに強化され、この暗号化はリニア・テープ・オープンの第４世代ドライブ（ＬＴＯ−４）で導入されたものであり、エンタープライズレベルのテープ・ドライブにおいて標準的なものでもある。テープ媒体は３０年以上の耐用年数を有するが、テープ・ハードウェアが急速に進歩し、より大容量のカートリッジへの移行に関連してコスト節約が行われるので、これは滅多に利用されない。信頼性の点では、ＬＴＯ−４のテープは、ＳＡＳ（シリアル・アタッチドＳＣＳＩ）ＨＤＤのものより少なくとも１桁優れたビット・エラー率を有する。その上、テープ媒体が取り外し可能であり交換可能であることは、ＨＤＤとは対照的に、カートリッジを単純に他のドライブに取り付けることができるので、テープ・ドライブの機械的故障がデータ損失をもたらさないことを意味する。
【０００４】
上記の利点はいずれも、コストと信頼性というテープ・システムの主要な究極の利点に貢献する。ディスクとテープとのコスト節約の推定値は３倍から２０倍以上の範囲に及ぶ。
【０００５】
ハードディスクは、データへのランダム・アクセスを可能にし、一般に、ファイル・システムによって管理されたファイル索引を収容している。これらのファイルは、様々なオペレーティング・システムおよびアプリケーションを使用して、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）の標準セットによってアクセスすることができる。対照的に、テープは、典型的に「シングリング（shingling）」と呼ばれる技法を使用して線形順序方式で書き込まれ、この技法は逆方向書き込み互換性を提供するが、末尾のみに新しいデータを付加することができ、カートリッジ全体を再利用して書き直した場合にのみ前に書き込まれた領域を再利用できることも意味する。伝統的なテープ・システムでは、所与のカートリッジに書き込まれたファイルの索引は、通常、独自所有のバックアップ・アプリケーションなどのアプリケーションによって管理される外部データベースのみに保持される。データを取り出すために外部データベースにアクセスする必要性があるため、テープ上のデータは、ＨＤＤまたはＵＳＢ（ユニバーサル・シリアル・バス）ドライブなどの代替記憶方法より可搬性およびアクセス可能性が低いものになる。
【０００６】
このような欠点に対処するために、最近、リニア・テープ・ファイル・システム（ＬＴＦＳ）と呼ばれる新しいファイル・システムがテープ・ドライブ・システムに導入され、標準的かつ精通したシステム・ツールおよびインターフェースを使用してテープへの効率的なアクセスを可能にしている。ＬＴＦＳは、最近のテープ・ドライブ・フォーマットでサポートされているデュアルパーティション機能を利用することによって実現される。いわゆる索引パーティションは索引を書き込むために使用され、第２のさらに大きいパーティションはデータ自体に使用される。索引パーティションはファイル・システムのディレクトリに使用され、データ・パーティションはファイル・システム内の実際のユーザのファイルを保管するために使用される。個別のパーティションに索引を置くことは、実データに影響を及ぼさずにそれを書き直すことができるので、有利である。ＬＴＦＳは、ＰＯＳＩＸ様のファイル・システム・インターフェースをユーザに公開し、索引パーティションでファイル・システム索引を管理し、データ・パーティションにデータを保管する。ＬＴＦＳソフトウェアによって代表されるファイル・システムはファイルおよびディレクトリをディレクトリ・リストとともにデスクトップ上に表示させ、ファイルは実際にはテープ上に位置する。ファイル・システム・ユーザはテープとの間でファイルを「ドラッグ・アンド・ドロップ」することができ、ディスク・システム用に開発されたアプリケーションを実行することができる。ライブラリ・モードでは、個々のカートリッジを取り付けずに、ライブラリ内のすべてのボリュームの内容をリストしサーチすることができる。これらの特徴はいずれも、テープ、ファイル管理、およびアーカイブのコスト低減に役立ち、ミドルウェア層への依存を解消する。このため、保管されているギガバイト（ＧＢ）あたりのコストが低減される。加えて、テープはクロスプラットフォームポータブルになり（ＬＴＦＳはＬｉｎｕｘ（Ｒ）、Ａｐｐｌｅ  Ｍａｃ  ＯＳ  Ｘ（Ｒ）、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（Ｒ）上で使用可能である）、プラットフォーム間でのデータの共用を可能にし容易にする。これらの特徴は、ビデオ・アーカイブ、医療画像など、テープに関する重要な新しいユースケースを可能にする。その他のストレージ・ソリューションよりテープの方がコスト上優位であること、テープ・カートリッジ容量の継続スケーリングおよびＧＢあたりのコストの潜在能力が実証されたこと、ならびにＬＴＦＳなどの進歩によって提供されるテープの有用性の増加を考慮すると、テープは、アーカイバル・データ・ストレージ・ソリューションのためのマーケットの爆発的増加に重要な役割を果たすように定められているようである。
【０００７】
しかし、ＬＴＦＳの場合でも、ファイルはテープ上に順次方式で保管され、このため、読み書きなどの入出力動作中にアクセス時間が無視できないほど長くなる。
【０００８】
米国特許出願第２０１１／０２１９１８４Ａ１号、米国特許出願第２０１１／０１４５４９４Ａ１号、米国特許第７７４３２０６Ｂ２号、米国特許第７１６２５７４Ｂ２号、米国特許第７７４７８１６Ｂ１号、米国特許第５８２９０４６号、２０１０年４月２２日発行のBeth Parizeauによる「IBM Launches long term file system (LTFS) forLTO-5 tape management」、および２００９年１１月１２日発行の「」という文書は本発明の分野に関連するものである。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許出願第２０１１／０２１９１８４Ａ１号
【特許文献２】米国特許出願第２０１１／０１４５４９４Ａ１号
【特許文献３】米国特許第７７４３２０６Ｂ２号
【特許文献４】米国特許第７１６２５７４Ｂ２号
【特許文献５】米国特許第７７４７８１６Ｂ１号
【特許文献６】米国特許第５８２９０４６号
【非特許文献】
【００１０】
【非特許文献１】２０１０年４月２２日発行のBethParizeauによる「IBM Launches long term file system (LTFS) for LTO-5tape management」
【非特許文献２】２００９年１１月１２日発行の「Virtual tape library for HSM」
【発明の概要】
【発明が解決しようとする課題】
【００１１】
第１の態様によれば、本発明は、
−データ・ファイルを保管するためのキャッシュ・メモリとして使用される不揮発性メモリであって、キャッシュ・メモリの少なくとも一部が、先入れ先出し（First In First Out）ポリシー管理を使用して管理される第１の領域と、最長未使用時間（Least Recently Used）ポリシー管理を使用して管理される第２の領域とを含む、不揮発性メモリと、
−テープ・ドライブ・システム上に保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースと、
−１つまたは複数のリモート・システムが記憶手段あるいはキャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースと
を含む、テープ・ドライブ・システム・サーバであって、
このサーバが、
−テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のデータ・ファイルを書き込むための１つまたは複数の書き込み要求を１つまたは複数のリモート・システムから受信し、
−テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のリモート・システムによって書き込むよう指示されたデータ・ファイルに関連付けられた属性を解釈し、
−解釈された属性に応じてリモート・システムによって書き込むよう指示されたデータ・ファイルを保管する
ように構成される、テープ・ドライブ・システム・サーバとして実施される。
【課題を解決するための手段】
【００１２】
諸実施形態では、テープ・ドライブ・システム・サーバは、以下の特徴のうちの１つまたは複数を含むことができる。
−データ・ファイルに関連する属性を解釈するためのキャッシュ管理機能（cache management function）
−属性がキャッシング優先順位クラス（caching-priority class）に対応すること
−第１のキャッシング優先順位クラスが、キャッシュ管理機能により、
−書き込むよう指示されたデータ・ファイルをキャッシュ・メモリの第１の領域に書き込むことと、
−その後、第１の領域に保管されたデータ・ファイルをテープ・ドライブ・システムにコピーすることであって、そのコピーがサーバのバックグラウンド・タスクとして実行されることと、
−コピーが終了した後に、キャッシュ・メモリの第１の領域からデータ・ファイルを追い出すこと
を実行させること、
−第２のキャッシング優先順位クラスが、キャッシュ管理機能により、
−書き込むよう指示されたデータ・ファイルをキャッシュ・メモリの第１の領域に書き込むことと、
−その後、第１の領域に保管されたデータ・ファイルをテープ・ドライブ・システムにコピーすることであって、そのコピーがサーバのバックグラウンド・タスクとして実行されることと、
−第１の領域に書き込まれたデータ・ファイルの第１の読み取り後に、データ・ファイルが１回または複数の追加回数読み取られるかどうかを判断することと、
−データ・ファイルが１回または複数の追加回数読み取られると判断された場合に、キャッシュ・メモリの第２の領域にデータ・ファイルを移動することと、
−データ・ファイルが１回または複数の追加回数読み取られると判断されない場合に、キャッシュ・メモリの第１の領域からデータ・ファイルを追い出すこと
を実行させること、
−第３のキャッシング優先順位クラスが、キャッシュ管理機能により、
−キャッシュ・メモリの第１の領域上で、キャッシュ・メモリの第１の領域に前に保管された１組のデータ・ファイルをプリフェッチすることと、
−プリフェッチされた１組のデータ・ファイルの第１の読み取り後に、プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られるかどうかを判断することと、
−プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られると判断された場合に、キャッシュ・メモリの第２の領域に１組のデータ・ファイルを移動すること
を実行させること、
−第４のキャッシング優先順位クラスが、キャッシュ管理機能により、キャッシュ・メモリの第２の領域上で、キャッシュ・メモリの第１の領域に前に保管された１組のデータ・ファイルをプリフェッチすることを実行させること、
−第５のキャッシング優先順位クラスが、キャッシュ管理機能により、
−任意の所与の時期にアクセスされた最大オフセットまでキャッシュ・メモリの第２の領域内にデータ・ファイルを入れること
を実行させること、
−第６のキャッシング優先順位クラスが、キャッシュ管理機能により、
−データ・ファイルがアクセスされるかどうかとは無関係に、データ・ファイル・キャッシング・クラスが設定されたときに、キャッシュ・メモリの第１の領域内に直ちにデータ・ファイルを入れることと、
−構成可能な時間間隔が満了したときに、キャッシュ・メモリからデータ・ファイルを追い出すこと
を実行させること、
−キャッシング・クラス（cachingclass）がユーザまたはアプリケーションのいずれか一方によって指定され、それに関するキャッシング・クラスがユーザまたはアプリケーションによって指定されていないデータ・ファイルについてキャッシュ管理機能がデフォルト・キャッシング・クラスをさらに割り当てること、
−属性が拡張属性であり、そのフォーマットがデータ・ファイルの所与のデータ・フォーマットと互換性があること、
−複数のユーザによる並行した同時データ書き込みあるいは読み取りまたはその両方を最適化するためにデータ・ファイルに関連する属性がキャッシュ管理機能によって使用されること。
【００１３】
他の態様によれば、本発明は、
−本発明のテープ・ドライブ・システム・サーバと、
−このサーバがそれとのインターフェースが取られているテープ・ドライブ・システムと
を含む、テープ・アプライアンス・システム（tape appliance system）として実施される。
【００１４】
他の態様によれば、本発明は、本発明のテープ・ドライブ・システム・サーバまたは本発明のテープ・アプライアンス・システムを含み、テープ・ドライブ・システムがテープ・ライブラリであるシステムとして実施される。
【００１５】
他の態様によれば、本発明は、コンピュータ可読媒体上に保管され、テープ・ドライブ・システム・サーバにキャッシュ管理機能を実行させるためのコード手段を含む、コンピュータ・プログラムとして実施される。
【００１６】
次に、非限定的な例として、添付図面に関連して、プロセスおよび本発明を実施するプロセスについて説明する。
【図面の簡単な説明】
【００１７】
【図１】本発明により他のシステムによってリモートでアクセスされるテープ・アプライアンス・システムのアーキテクチャ図の一例である。
【図２】図１に描写されたテープ・アプライアンス・システムのデータ・パス図の一例である。
【図３】図１に描写されたテープ・アプライアンス・システムのデータ・パス図の他の例である。
【図４】図１〜図３に描写されたテープ・アプライアンス・システムのキャッシングの一例である。
【発明を実施するための形態】
【００１８】
本発明はテープ・ドライブ・システム・サーバについて記述するものである。テープ・ドライブ・システム・サーバは、データ・ファイルを保管するためのキャッシュ・メモリとして使用される不揮発性メモリを含む。キャッシュ・メモリの少なくとも一部は、先入れ先出し（ＦＩＦＯ）ポリシー管理を使用して管理される第１の領域と、最長未使用時間（ＬＲＵ）ポリシー管理を使用して管理される第２の領域（４２）とを含む。テープ・ドライブ・システム・サーバは、テープ・ドライブ・システム上に保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースをさらに含む。テープ・ドライブ・システム・サーバは、１つまたは複数のリモート・システムが記憶手段あるいはキャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースをさらに含む。このインターフェースは、ある機械が他の機械と遠距離通信できるようにする特定の規格に合わせて普通に設計されたものなどの通信インターフェースにすることができる。テープ・ドライブ・システム・サーバは、１つまたは複数の書き込み要求を１つまたは複数のリモート・システムから受信するように構成される。書き込み要求は、テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のデータ・ファイルを書き込むためのものである。これは、書き込み要求が、テープ・ドライブ・システムのみに１つまたは複数のデータ・ファイルを書き込むこと、あるいはキャッシュ・メモリのみに１つまたは複数のデータ・ファイルを書き込むこと、あるいはテープ・ドライブ・システムとキャッシュ・メモリの両方に１つまたは複数のデータ・ファイルを書き込むことを要求できることを意味する。テープ・ドライブ・システム・サーバは、テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のリモート・システムによって書き込むよう指示されたデータ・ファイルに関連付けられた属性を解釈するようにさらに構成される。属性を解釈することは、テープ・ドライブ・システム・サーバがその属性に応じてどの特定のアクションを実行すべきかを判断できることを意味する。テープ・ドライブ・システム・サーバは、解釈された属性に応じてリモート・システムによって書き込むよう指示されたデータ・ファイルを保管するようにさらに構成される。書き込むべきデータ・ファイルを保管することは、書き込むべきデータ・ファイルが記録されると言うことに等しい。
【００１９】
したがって、提案されている発明の焦点は、アクセス待ち時間の点のみならず、キャッシング戦略を適用するフレキシビリティの点でも、テープ・ドライブ・システム（たとえば、ＬＴＦＳに基づくテープ・ストレージ・システム）のパフォーマンスを改善するシステムにある。
【００２０】
そのために、テープ・ドライブ・システム・サーバは、テープ・ドライブ・システムに保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースと協力してキャッシュ・メモリを使用する。キャッシュ・メモリは、記憶手段の上のキャッシング層として使用される。テープ・ドライブ・システム・サーバは、属性の形でキャッシング・ヒントを提供する。属性（拡張属性ともいう）は、ファイル・システム・インターフェースおよびより一般的にはテープ・ドライブ・システム・サーバに関する機能および追加の情報を提供する。その属性の解釈に基づいて、テープ・ドライブ・システム・サーバは、１つまたは複数のリモート・システムによって書き込むよう指示されたデータ・ファイルをどこにどのように保管するかを把握する。したがって、提示されているシステムは、最も最近あるいは頻繁にまたは最も最近かつ頻繁にキャッシュされたファイルへの高速アクセスを可能にするキャッシング戦略を提供するだけでなく、その必要性に応じて、たとえば、システムの作業負荷に応じて、アプリケーションまたはユーザがキャッシング戦略を変更できるように設計されている。
【００２１】
当業者によって認識されるように、本発明の諸態様は、システムまたはコンピュータ・プログラム・プロダクト（computer program product）として実施することができる。したがって、本発明の諸態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアとハードウェアの諸態様を組み合わせる実施形態の形を取ることができ、いずれも本明細書では一般に「回路」、「モジュール」、または「システム」と呼ぶことができる。さらに、本発明の諸態様は、そこにコンピュータ可読プログラム・コードが実施されている１つまたは複数のコンピュータ可読媒体に実施されたコンピュータ・プログラム・プロダクトの形を取ることができる。
【００２２】
１つまたは複数のコンピュータ可読媒体の任意の組み合わせを使用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体にすることができる。コンピュータ可読記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、あるいは上記のものの任意の適切な組み合わせにすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的リスト）としては、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光学記憶装置（ＣＤ−Ｒ／Ｗ、ＤＶＤ、ＢＤ）、磁気記憶装置、あるいは上記のものの任意の適切な組み合わせを含むであろう。本明細書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを収容または保管することができる任意の有形媒体にすることができる。
【００２３】
コンピュータ可読信号媒体は、たとえば、ベースバンド内でまたは搬送波の一部として、そこに実施されたコンピュータ可読プログラム・コードを含む伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはそれらの任意の適切な組み合わせを含むがこれらに限定されない様々な形のうちのいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを通信、伝搬、または輸送することができる任意のコンピュータ可読媒体にすることができる。
【００２４】
コンピュータ可読記憶媒体上に実施されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、あるいは上記のものの任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して伝送することができる。
【００２５】
本発明の諸態様のための動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語あるいは「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成することができる。プログラム・コードは、完全にユーザのコンピュータ上で、一部分はユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、一部分はユーザのコンピュータ上でしかも一部分はリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行することができる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してリモート・コンピュータがユーザのコンピュータに接続される場合もあれば、（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに接続が行われる場合もある。
【００２６】
本発明の諸態様は、本発明の諸実施形態による方法、装置（システム）、およびコンピュータ・プログラム・プロダクトの流れ図あるいはブロック図またはその両方に関連して以下に記載されている。流れ図あるいはブロック図またはその両方の各ブロックおよび流れ図あるいはブロック図またはその両方内の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実現可能であることが理解されるであろう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供し、コンピュータまたはその他のプログラマブル・データ処理装置のプロセッサにより実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するための手段を作成するような機械を生産することができる。
【００２７】
また、これらのコンピュータ・プログラム命令は、コンピュータ可読媒体に保管された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現する命令を含む製造品（article of manufacture）を生産するような特定の方法で機能するよう、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイスに指示することができるコンピュータ可読媒体に保管することもできる。
【００２８】
また、コンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上にロードし、コンピュータまたはその他のプログラマブル装置上で実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／行為を実現するためのプロセスを提供するようなコンピュータで実行されるプロセスを生産するように、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上で一連の動作ステップを実行させることもできる。
【００２９】
図面内のブロック図は、本発明の様々な諸実施形態によるシステム、方法、およびコンピュータ・プログラム・プロダクトについて可能な実現例のアーキテクチャ、機能、および動作を例示している。この点に関しては、流れ図またはブロック図内の各ブロックは、指定の論理機能（複数も可）を実現するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または一部分を表すことができる。また、いくつかの代替実現例では、ブロック内に示された機能は図面内に示された順序から外れて行われる可能性があることに留意されたい。たとえば、連続して示されている２つのブロックは、関係する機能次第で、実際にはほぼ同時に実行される場合もあれば、ときには逆の順序で実行される場合もある。また、ブロック図あるいは流れ図またはその両方の各ブロックおよびブロック図あるいは流れ図またはその両方内の複数ブロックの組み合わせは、指定の機能または行為を実行する特殊目的ハードウェアベースのシステムあるいは特殊目的ハードウェアとコンピュータ命令との組み合わせによって実現可能であることも留意されるであろう。
【００３０】
図１は、１つまたは複数のリモート・システム１１０、１２０によってリモートでアクセスされるテープ・アプライアンス・システム１００の一実施形態のアーキテクチャ図である。本発明の一実施形態によるテープ・アプライアンス１００は、テープ・ドライブ・システム・サーバ１０２と、テープ・ドライブ・システム・サーバがそれとのインターフェースが取られているテープ・ドライブ・システム１０４とを含む。
【００３１】
テープ・ドライブ・システム１０４は、所定のデータ・フォーマットによるデータ・ファイルを保管することができる。テープ・ドライブ・システムは、多数のテープ・ドライブまたはヘッドをサポートすることができる、スタンドアロン・テープ・ドライブ（またはテープ・ライブラリ）などの順次アクセス媒体にすることができる。スタンドアロン・テープ・ドライブは、１つまたは複数のテープ・カートリッジ上のリニア・テープについて操作するために使用される。テープ・ドライブに保管されたデータの所定のデータ・フォーマットは、ファイル・コンテンツ・データと関連のファイル・メタデータを保持する、ＬＴＦＳフォーマットのデータ・フォーマットを使用することができる。したがって、テープ・ドライブに保管され、ＬＴＦＳフォーマットを使用して書き込まれたデータは、ＬＴＦＳフォーマットを理解できるその他のシステム１１０、１２０と交換することができる。
【００３２】
図１の実施形態によるテープ・ドライブ・システム・サーバ１０２は、データ・ファイルを保管するためのキャッシュ・メモリとして使用される不揮発性メモリ１０６を含む。キャッシュ・メモリは、作業負荷の時間的および空間的局所性を活用して、ストレージ・システムのパフォーマンスを最適化する。キャッシュ・メモリは読み書きキャッシュである。キャッシュ・メモリは、そのデータに関する将来の要求に対してより高速に対応できるように、データを透過的に保管することによりパフォーマンスを改善する。要求されたデータがキャッシュ内に収容されている場合、すなわち、キャッシュ・ヒットが発生した場合、単にキャッシュを読み取るだけでこの要求に対応することができ、これはバックエンド・ストレージ・デバイスから読み取るより比較的高速である。そうではない場合、キャッシュ・ミスが発生し、より低速のバックエンド・ストレージ・デバイスからデータをフェッチしなければならない。
【００３３】
キャッシュ・メモリは不揮発性メモリであり、有利なことにテープ・ドライブ・システムがオフになったときにそこに保管されているファイルを保持することができる。キャッシュ・メモリとして使用される不揮発性メモリは、ハードディスク・ドライブあるいはソリッドステート・ドライブまたはその両方のアレイを含むことができる。大容量ＨＤＤあるいはＳＳＤまたはその両方のアレイは、ＲＡＩＤ（冗長ディスク・アレイ）方式で構成することができる。キャッシュ・メモリ・コントローラは、サーバのオペレーティング・システムに対して単一論理ボリュームを公開し、したがって、キャッシュ・メモリの管理をより容易にすることができる。また、ｅｘｔ３、ｅｘｔ４、またはＮＴＦＳなどを含むがこれらに限定されない従来のディスク・ファイル・システムは、その論理ボリュームにインストールされ、ディスク・アレイに対するすべての入出力動作に使用される。キャッシュ・メモリ、すなわち、ディスク・アレイ全体は、キャッシング専用であり、システムの他のコンポーネントと共用されることはない。
【００３４】
キャッシュ・メモリはファイル・レベルのキャッシュ・メモリにすることができる。代わって、キャッシュ・メモリはブロックレベルのキャッシュ・メモリにすることもできる。この場合、アレイのＨＤＤあるいはＳＳＤまたはその両方は、ファイル・システムのないロウ・デバイス（raw device）として使用され、その後、ボリュームが作成され、オペレーティング・システムがこれらのボリュームに接続し、それを個別ハード・ドライブとして使用する。ブロックレベルのキャッシュ・メモリは、ファイル・ストレージ、データベース・ストレージ、仮想計算機ファイル・システム（ＶＭＦＳ）ボリュームなどを含む、ほとんどすべての種類のアプリケーションに使用可能である。
【００３５】
次に、図４を参照し、図１に描写されているテープ・ドライブ・システム・サーバ１０２のキャッシュ・メモリの一例について述べる。キャッシュ・メモリは不揮発性ストレージであり、したがって、キャッシュ・メモリは、変更されたデータと未変更のデータの両方をファイル・レベルで安全に保持することができる。
【００３６】
キャッシュ・メモリ１０６の少なくとも一部は、第１の領域または空間４０と第２の領域または空間４２とを含む。第１および第２の領域は、記憶手段に初めから保管されているファイルを保管するように適合されている。第１および第２の領域におけるファイルの保管は、キャッシュ容量管理に関する１組のルールにより実行される。
【００３７】
第１の領域はＦＩＦＯ（先入れ先出し）領域４０であり、第２の領域はＬＲＵ（最長未使用時間）領域４２である。これは、キャッシュ・メモリの少なくとも一部がＦＩＦＯキャッシュとＬＲＵキャッシュに分割されると言うことに等しい。ＦＩＦＯ領域は先入れ先出し置き換えポリシーを使用して管理され、ＬＲＵ領域は最長未使用時間ポリシーを使用して管理される。ＦＩＦＯ領域は典型的に、キャッシュに書き込まれた後に多くても１回だけアクセスされるファイルを保持するようになっている。これは、たとえば、バックアップ書き込み検証プロセスのケースである。ＬＲＵ領域は典型的に、近い将来に複数のアクセスが行われる確率が高いファイルをキャッシュするようになっている。
【００３８】
図４に示されているように、ユーザ書き込みは通常、そのデータをＦＩＦＯキャッシュに書き込み、ユーザ読み取りは通常、ＬＲＵキャッシュによって対応される。しかし、これは必要条件ではなく、実際には、受信データが近い将来に複数回アクセスされることをユーザがヒントとして示した場合、そのデータもＬＲＵキャッシュに書き込まれる可能性がある。これに対して、要求されたデータがそこにあることが判明した場合、ＦＩＦＯキャッシュからユーザ読み取りに対応することができる。
【００３９】
同時に、任意選択で、その作業負荷次第でキャッシュの２つの領域間でファイルが移動し、実際には、キャッシュ・メモリは記憶容量サイズが限られており、それを分割してＦＩＦＯおよびＬＲＵセクションにするには特定レベルの制御権を必要とする。換言すれば、キャッシュ容量は１組のルールにより管理される。キャッシュ容量管理に関する以下のルールを使用することができる。
−ＦＩＦＯ領域がいっぱいである場合、最も古いファイルが追い出される。ファイルをキャッシュから追い出すには、まずそれをテープにコピーする必要がある可能性がある。
−ＬＲＵ領域がいっぱいである場合、アクセス数が最も少なく、最終アクセス時間が最も古いファイルが追い出される。ファイルをキャッシュから追い出すには、まずそれをテープにコピーする必要がある可能性がある。
−ＦＩＦＯ領域がいっぱいで、ＬＲＵ領域が少なくとも５０％の空き容量を有する場合、ＦＩＦＯ領域はＬＲＵ領域の容量の３０％を獲得する。
−ＬＲＵ領域がいっぱいで、ＦＩＦＯ領域が少なくとも５０％の空き容量を有する場合、ＬＲＵ領域はＦＩＦＯ領域の容量の３０％を獲得する。
【００４０】
前述のパーセンテージは設計パラメータであり、特定のアプリケーションおよび作業負荷次第で変化する可能性があることを理解されたい。
【００４１】
図１に戻って参照すると、テープ・ドライブ・システム・サーバ１０２は、少なくとも１つのコンピュータ処理装置（ＣＰＵ）１０００またはプロセッサと、典型的にダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）であるメイン・メモリ１００２とを含むことができる。ＣＰＵおよびＤＲＡＭはバス１００４に接続される。このバスは、ＬＣＤモニター１００８などのディスプレイに接続されるディスプレイ・コントローラ１００６に接続することができる。ディスプレイは、テープ・アプライアンス・システム１００に関する情報を表示するために使用することができる。バスは、任意のキーボード／マウス・コントローラ１０１０を介してキーボード１０１２およびマウス１０１４にさらに接続することができる。また、このバスは、たとえば、イーサネット（登録商標）プロトコルに適合する通信コントローラ１０１４に接続することもできる。通信コントローラは、テープ・ドライブ・システム・サーバをネットワーク、たとえば、ネットワーク１３０と物理的に接続するために使用される。また、このバスは、ＩＤＥ／ＳＡＴＡ、ＳＣＳＩ、ファイバ・チャネル、ファイバ・チャネル・オーバ・イーサネット（ＦＣｏＥ）、またはｉＳＣＳＩコントローラなどのデバイス・コントローラ１０１８によりハードディスク１０４またはＤＶＤ１０２０などのストレージ・デバイスにも接続される。
【００４２】
テープ・ドライブ・システム・サーバは、テープ・ドライブ・システム１０４に保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースをさらに含む。ファイル・システム・インターフェースは、テープ・ドライブ・システムと通信し、そこに保管されたデータ・ファイルを管理する、たとえば、データ・ファイルを書き込むかまたは読み取るための能力をテープ・ドライブ・システム・サーバに提供する。このため、テープ・ドライブ・システム・サーバ１０２は、そのために公開されている根本的なテープ容量をテープ・ドライブ・システム・サーバが活用できるように、ファイル・システム・インターフェースを介してテープ・ドライブ・システム１０４に取り付けることができる。ファイル・システム・インターフェースは、テープ・ドライブ・システム・サーバ上で実行されるＬＴＦＳソフトウェアにすることができる。
【００４３】
テープ・ドライブ・システム・サーバは、Ｌｉｎｕｘ（商標）オペレーティング・システムなどを含むがこれに限定されないオペレーティング・システムを実行する。このサーバはネットワーク１３０に接続され、それによりリモート・ネットワーク・ユーザ１２０およびアプリケーション１３０は記憶手段（たとえば、ＬＴＦＳファイル・システム）を取り付け、データを直接保管するかまたは記憶手段からデータを取り出すことができる。
【００４４】
次に、図３を参照すると、図１に描写されているテープ・ドライブ・システム・サーバ１０２のデータ・パス図の一例が示されている。テープ・ドライブ・システム・サーバ１０２はネットワーク・インターフェース、たとえば、図１の通信コントローラ１０１６を含む。別の言い方では、テープ・ドライブ・システム・サーバは、１つまたは複数のリモート・システム（１１０、１２０）が記憶手段あるいはキャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースを含む。
【００４５】
図３では、テープ・ドライブ・システム１０４に対するすべての入出力動作がＬＴＦＳファイル・システム動作として実現されている。たとえば、図３に示されているように、テープ・ドライブ・システムへのクライアントの書き込みは必ず、最後には、特定のオフセットから始まり、特定のバイト数の長さを有するＬＴＦＳファイルへの書き込み動作になる。第１のシナリオでは、リモート・ユーザ１１０は、テープ・ドライブ・システム・サーバへのＮＦＳマウントを使用して、「／ｌｔｆｓ／ｇｒｅｅｔｉｎｇｓ．ｔｘｔ」というファイルへの書き込みを発行する。この書き込み要求は、ファイル・システム・インターフェースＬＴＦＳ２２にその要求を渡すテープ・ドライブ・システム・サーバによって管理される。次に、ＬＴＦＳは、このファイルがすでにＨＤＤキャッシュ１０６にキャッシュされていることに気付き、書き込みはＨＤＤ上で吸収され、「／ｌｔｆｓ／ｇｒｅｅｔｉｎｇｓ．ｔｘｔ」はＨＤＤファイル・システム上でｅｘｔ３ファイルになる。異なるシナリオでは、他のリモート・ユーザ１２０は、ＦＴＰプロトコルを使用して、テープ・アプライアンス・システム上のファイルから数バイトを読み取りたいと希望する。このユーザはＦＴＰ取得要求を発行し、テープ・ドライブ・システム・サーバはＬＴＦＳファイル・システム・インターフェースを介してその要求をＬＴＦＳ読み取り要求に変換する。ＬＴＦＳファイル・システム・インターフェースはキャッシュ・メモリ１０６内で要求されたファイルを捜すが、それがそこにないことに気付く。したがって、ＬＴＦＳファイル・システム・インターフェースは要求されたファイルをテープ・ドライブ・システム１０６から読み取り、最初の１００バイトをユーザに返す。その時点で、ＬＴＦＳはＨＤＤ１０６上にそのファイルをキャッシュするかどうかを選択することができる。
【００４６】
次に、図２を参照すると、アプリケーションまたはクライアントなどのリモート・システムと図１に描写されているテープ・ドライブ・システム・サーバとの間のデータ・パス図の他の例が示されている。テープ・ドライブ・システム・サーバ１０２は、たとえば、ネットワークを介して、アプリケーション１１０またはクライアント１２０などのシステムによってリモートでアクセスされる。その他のシステムは、ＧＰＦＳ（汎用並列ファイル・システム）クラスタまたはＮＡＳ（ネットワーク接続ストレージ）ファイラなどのファイル・システム・サーバである可能性がある。
【００４７】
リモート・システムは、ネットワーク・ファイル・システムを使用してそれを取り付けることあるいはＦＴＰ（ファイル転送プロトコル）プロトコルまたはＳＳＨ（セキュア・シェル）プロトコルを使用してそれに対してデータを読み書きすることのいずれかにより、テープ・ドライブ・システム・サーバにアクセスすることができる。テープ・ドライブ・システム・サーバ１０２にリモートでアクセスするために任意のその他のプロトコルを使用できることを理解されたい。
【００４８】
テープ・ドライブ・システム・サーバ１０２は、図２に示されているように適切なインターフェース２３、２４、２５、２６、２７を提供し、その結果、テープ・ドライブ・システム・サーバを使用して多数のアプリケーション１１０に必要なストレージを収容することができる。図２では、テープ・ドライブ・システム・サーバは、たとえば、多数のテープ・ドライブなどのテープ・ドライブ・システム（１０４）に保管されたデータ・ファイルと対話するためにファイル・システム・インターフェースを含む。テープ・ドライブに保管されたファイルを管理するためのアプリケーションの例は以下の通りであるが、これらに限定されない。
１）ネットワークによりテープ・ドライブ・システム・サーバに接続されたＧＰＦＳ（またはその他の）ファイル・システムのバックアップ。ＧＰＦＳファイル・システム全体あるいは個別ディレクトリまたはファイル・セットは、テープ・アプライアンス・システムにバックアップすることができる。全バックアップまたは増分バックアップを行うことができ、同じかまたは異なるテープ・カートリッジ上で複数のバージョンをサポートすることができる。さらに、同じかまたは異なるファイル・システム／クラスタから発生した複数のバックアップを同じアプライアンスでサポートすることができる。有利なことに、ＬＴＦＳは、バックアップをテープ・カートリッジ上で自立型かつ自己記述にすることができ、ユーザが集中型バックアップ・サーバを配備して維持する必要性を省くことができる。加えて、ＧＰＦＳのファイル属性はＬＴＦＳ上に保存することができ、ＬＴＦＳに対する何らかの変更によって施行することもできる。バックアップ・プロセスは、ＧＰＦＳノードまたはテープ・アプライアンス自体のいずれか一方により調整することができ、以下のステップで概説する。
ａ．クラスタ内で実行されるＧＰＦＳポリシーは、最後のバックアップ以降に変更されたファイルを識別する。
ｂ．このポリシーはバックアップを実行するために外部プロセスを呼び出す。
ｃ．バックアップ・プロセスは、ＧＰＦＳファイル属性を保存しているアプライアンスにファイルをコピーする。
ｄ．コピー動作は、ＳＳＨによりまたはＮＦＳ／ＣＩＦＳマウントを使用して実行することができる。
ｅ．プロセスが終了すると、テープ・カートリッジを取り外してボールトに入れるかまたは任意の他のシステムに移動することができる。
ファイルは、同じかまたは任意の他のテープ・システムでそのテープを読み取るだけでバックアップから復元することができ、ＬＴＦＳによって提供されたファイル・システム・インターフェースを強化することができ、これによりＧＰＦＳと同じ名前空間を保持することができる。これは、ファイラからバックアップされたどのファイルもＬＴＦＳ内の名前（パスおよびファイル）を有することができ、それにより簡単なリカバリを可能にすることを意味する。
２）ＧＰＦＳ（またはその他の）ファイル・システムからのファイルの移行、すなわち、ストレージ階層内の１つの層としてテープ・ドライブ・システムを使用すること。ユーザはユーザ指定のＧＰＦＳポリシーの形でファイルまたはディレクトリに関する移行基準を指定し、システムは、前述の指定の基準に適合するファイルをテープ・ドライブ・システムに移行することによりシームレスにデータをテープ上に置く。テープ・ドライブ・システムに移行するそれぞれのファイルについて、そのファイルはファイル・スタブ（プレースホルダ）によってＧＰＦＳ内で置き換えられる。それにより、ファイルはＧＰＦＳ名前空間内に存続し、ユーザおよび既存のアプリケーションによって通常のファイルとしてアクセスすることができる。移行されたファイルにアクセスすると、ファイルはテープ・ドライブ・システムから再呼び出しされる。
３）そのファイラからＬＴＦＳに古いスナップショットをコピーし、より古いスナップショットをそのファイラから削除するためのＮＡＳファイラ（たとえば、ＮｅｔＡｐｐファイラ）との統合。その利点は、典型的により多くの記憶容量を必要とする古いスナップショットがテープ・ドライブ・システムに保管され、ＮＡＳファイラによって提供されたＮＦＳまたはＣＩＦＳなどのＮＡＳインターフェースにもすることができるＬＴＦＳファイル・システム・インターフェースによりシームレスにアクセスできることである。
４）メディア管理（ＭＡＭ）では、媒体は同じデータ・ストリームの複数のバージョンを収容している場合が多い。同じコンテンツの低解像度バージョンであるいわゆる「プロキシ」とともにオーディオビデオ・ストリームの高精細バージョンを有することは一般的な慣例である。再生ストリームを生成するかまたは直接再生するために高精細の元のストリームに後で適用されると思われるカット・リストを生成するために、コンテンツを編集／カットするためにより頻繁に使用されるので、プロキシに関係するファイルをキャッシュすることは非常に有益になるであろう。
５）保管されているファイルのメディア管理、バージョン管理、ボールト、フォーマット・チェックおよびリカバリを含むがこれらに限定されない、テープ・アプライアンス・システムをリモートで管理するためのグラフィカル・ユーザ・インターフェース。
【００４９】
このため、テープ・ドライブ・システム・サーバは、キャッシュ・メモリとして使用され、単一論理アドレス空間になるように論理的に構成可能な不揮発性メモリ（たとえば、ＨＤＤ／ＳＤＤアレイ）と、テープ・ドライブ・システム（たとえば、図１に示されているように、並行して動作する１つまたは複数のテープ・ドライブ）に保管されたデータ・ファイルと対話するためのファイル・システム・インターフェースと、１つまたは複数のリモート・システムが記憶手段あるいはキャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースとを含む。
【００５０】
テープ・ドライブ・システム・サーバは、テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のデータ・ファイルを書き込むための１つまたは複数の書き込み要求を１つまたは複数のリモート・システムから受信するようにさらに構成される。実際に、書き込み要求は、１つまたは複数のリモート・システムが記憶手段あるいはキャッシュ・メモリまたはその両方に保管されたデータを読み書きできるようにするためのインターフェースによって受信される。したがって、このインターフェースは、ある機械が他の機械と遠距離通信できるようにする特定の規格に合わせて普通に設計されたものなどの通信インターフェースにすることができる。
【００５１】
加えて、テープ・ドライブ・システム・サーバは、テープ・ドライブ・システムおよびキャッシュ・メモリに１つまたは複数のリモート・システムによって書き込むよう指示されたデータ・ファイルに関連付けられた属性を解釈するように構成される。この方法により、キャッシング・ヒントが属性の形で提供される。典型的に、属性は、データ・ファイルの所与のデータ・フォーマットと互換性のあるフォーマットを有する拡張属性である。属性は、ＰＯＳＩＸ規格に応じてファイルおよびディレクトリ・ベースでファイル・システム・インターフェースによってサポートされる。有利なことに、これにより、ファイル・システム・インターフェース（たとえば、ＬＴＦＳファイル・システム）による属性の解釈をより容易なものにすることができる。
【００５２】
属性は、実際には、ユーザ１２０またはアプリケーション１１０によって選択され、有利なことに、これによりユーザまたはアプリケーションは拡張属性の形でキャッシング・ヒントを提供することができる。したがって、属性はキャッシング優先順位クラスに対応する。別の言い方では、ユーザまたはアプリケーションは、所与のデータ・ファイルについてキャッシング優先順位を選択することができる。属性の名前はすでにキャッシング優先順位情報を含むことができる。属性の名前は好ましくは事前定義されている。
【００５３】
さらに、テープ・ドライブ・システム・サーバは、解釈された属性に応じてリモート・システムによって書き込むよう指示されたデータ・ファイルを保管するようにさらに構成される。このため、書き込むよう指示されたデータ・ファイルのキャッシングは属性の値（たとえば、属性の名前）に基づいて実行される。
【００５４】
キャッシング優先順位選択はいつでもユーザによって提供することができ、ファイルに関するキャッシング優先順位選択は時間の経過につれて変化する可能性があることを理解されたい。たとえば、同じユーザあるいはアプリケーションまたは異なるユーザ／アプリケーションが新しいヒントまたはキャッシング優先順位を提供する可能性がある。キャッシュ管理は、次にアクセスされたときまたはユーザ／アプリケーションが明示的に要求した場合にはそれ以前に、ファイルに関するそのキャッシング決定を変更することになる。これは、有利なことに、テープ・ドライブ・システム・サーバの作業負荷などのパラメータ次第で、ユーザまたはアプリケーションによって変更可能なキャッシング優先順位のフレキシビリティを改善するものである。
【００５５】
その最も単純な形では、キャッシュ・ヒントは特定のファイルに関するキャッシュ優先順位である。デフォルト・キャッシュ優先順位クラス（たとえば、クラス３）は、たとえば、ユーザまたはアプリケーションが指定しない場合に、テープ・ドライブ・システム・サーバによって想定できることを理解されたい。
【００５６】
次に、キャッシング優先順位クラスおよびそのセマンティクスの例について述べる。それぞれの属性の解釈は典型的にキャッシュ管理機能によって実行することができ、解釈された属性に応じて書き込むよう指示されたデータ・ファイルの保管もキャッシュ管理機能によって実行することができる。
【００５７】
第１のキャッシング優先順位クラス（クラス１ともいう）では、キャッシュ管理機能により、データ・ファイルを１回書き込むことができ、データ・ファイルはＦＩＦＯキャッシュに書き込まれ、バックグラウンドで直ちにテープにコピーされる。コピーが終了すると、ファイルはキャッシュから廃棄される。別の言い方では、書き込むよう指示されたデータ・ファイルはキャッシュ・メモリの第１の領域に書き込まれ、その後、第１の領域からテープ・ドライブ・システムにコピーされる。そして、コピーが終了した後に、データ・ファイルはキャッシュ・メモリの第１の領域から追い出され、すなわち、データ・ファイルはキャッシュ・メモリのＦＩＦＯ領域から削除される。コピーは有利なことにサーバのバックグラウンド・タスクとして実行される。これにより書き込み中にキャッシングを行うことが可能になり、特にテープ・ライブラリが使用中であるときに、データ・ファイルをまずキャッシュ・メモリに書き込み、バックグラウンドで非同期的にテープに移動することができる。したがって、書き込みは、書き込みを開始する前にテープ・ドライブ・システムのテープに対する進行中の読み取りが終了するのを待つ必要がない。
【００５８】
第２のキャッシング優先順位クラス（クラス２ともいう）では、キャッシュ管理機能により、データ・ファイルを書き込み、次にデータ・ファイルを１回読み取ることができる。この目的のために、データ・ファイルはＦＩＦＯキャッシュに書き込まれ、バックグラウンドでテープにコピーされる。データ・ファイルに対する次の読み取り動作が行われるまで、ファイルはＦＩＦＯキャッシュに保持される。第１の読み取り動作後にファイルが複数回読み取られる場合、ファイルはキャッシュ・メモリのＬＲＵキャッシュに移動する。最初の読み取り動作後にファイルが一定の期間内にまたはキャッシュ空間を再利用する必要が生じるまでにまったく読み取られない場合、ファイルはキャッシュから追い出される。他の言い方では、クラス２では、キャッシュ管理機能はキャッシュ・メモリの第１の領域に書き込むよう指示されたデータ・ファイルを書き込み、その後、第１の領域に保管されたデータ・ファイルをテープ・ドライブ・システムにコピーし、そのコピーはサーバのバックグラウンド・タスクとして実行される。次に、キャッシュ管理機能は、第１の領域に書き込まれたデータ・ファイルの第１の読み取り後に、データ・ファイルが１回または複数の追加回数読み取られるかどうかを判断する。データ・ファイルが１回または複数の追加回数読み取られると判断された場合に、データ・ファイルはキャッシュ・メモリの第２の領域に移動する。これに反して、データ・ファイルが１回または複数の追加回数読み取られると判断されない場合に、データ・ファイルはキャッシュ・メモリの第１の領域から追い出される。このため、クラス２は有利なことに書き込み中にキャッシングを可能にし、その後の読み取りのためのキャッシングを可能にし、書き込み検証動作をサポートする。テープ・ドライブ・システム上に置かれているが、依然として何らかのユーザによって規則正しくアクセスされるデータ・ファイル（たとえば、アーカイブの最も頻繁に使用される部分）はキャッシュ・メモリに保管される。したがって、これらのアクセスはテープの高レイテンシで悪化することはない。その結果、複数のユーザがＦＩＦＯ領域に保管された同じデータ・ファイルを読み取ることができ、したがって、データ・ファイルがテープ・ドライブ・システムに保管されている間のデータ・ファイルへのアクセス時間が減少する。
【００５９】
第３のキャッシング優先順位クラス（クラス３ともいう）では、キャッシュ管理機能により、すでに書き込まれている既存のファイルについて、ファイル全体をＦＩＦＯキャッシュにプリフェッチすることができる。最初の読み取り動作後にファイルが複数回読み取られる場合、ファイルはＬＲＵキャッシュに移動する。したがって、キャッシュ・メモリの第１の領域上で、キャッシュ・メモリの第１の領域に前に保管された１組のデータ・ファイルがプリフェッチされ、プリフェッチされた１組のデータ・ファイルの第１の読み取り後に、プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られるかどうかが判断される。プリフェッチされた１組のうちの１つまたは複数のデータ・ファイルが１回または複数の追加回数読み取られると判断された場合に、１組のデータ・ファイルはキャッシュ・メモリの第２の領域、すなわち、ＬＲＵ領域に移動する。このクラスは有利なことに、アプリケーションまたはユーザからの読み取りコマンドが発行される前にキャッシュすべきファイルを読み取ることにより読み取りキャッシュを可能にする。
【００６０】
第４のキャッシング優先順位クラス（クラス４ともいう）では、キャッシュ管理機能により、キャッシュ・メモリの第１の領域に前に保管された１組のデータ・ファイルをプリフェッチすることによりキャッシュ・メモリの第２の領域上でプリフェッチを実行することができる。したがって、すでに書き込まれている既存のファイルは、直ちに２回以上順次読み取られることになる。したがって、このクラスは、アプリケーションまたはユーザからの読み取りコマンドが発行される前にキャッシュすべきファイルを読み取ることにより読み取りキャッシュを可能にする。
【００６１】
第５のキャッシング優先順位クラス（クラス５ともいう）では、キャッシュ管理機能により、任意の所与の時期にアクセスされた最大オフセットまでデータ・ファイルをＬＲＵキャッシュにフェッチすることができる。すでに書き込まれている既存のファイルはランダム方式で読み取られることになる。このクラスは、アプリケーションまたはユーザからの読み取りコマンドが発行される前にキャッシュすべきファイルを読み取ることにより読み取りキャッシュを可能にする。別の言い方では、このクラスは、任意の所与の時期にアクセスされた最大オフセットまでキャッシュ・メモリの第２の領域内にデータ・ファイルを入れさせる。興味深いことに、データ・ファイルへのランダム書き込みはキャッシュ・メモリに吸収することができる。したがって、関連バイト範囲をテープ・ドライブ・システムに書き込む前に、データ・ファイル内でオフセットを開始することにより、関連バイト範囲をソートすることができる。そのデータ・ファイルに対する連続順次読み取り動作はテープ上で前後に動いてシークする必要がなく、ファイルが依然としてキャッシュ内にある場合に、当然のことながらテープ・ドライブ・システムにアクセスせずにキャッシュから対応できることを理解されたい。
【００６２】
第６のキャッシング優先順位クラス（クラス６ともいう）では、キャッシュ管理機能により、データ・ファイルがアクセスされるかどうかとは無関係に、データ・ファイル・キャッシング・クラスが設定されたときに、キャッシュ・メモリの第１の領域内に直ちにデータ・ファイルを入れ、構成可能な時間間隔が満了したときに、キャッシュ・メモリからデータ・ファイルを追い出すことができる。これにより、キャッシュ・メモリの第１の（ＦＩＦＯ）領域または第２の（ＬＲＵ）領域内にファイルが無限に常駐するのを防止することができる。キャッシュ内のファイルの最大常駐時間である最大時間間隔はユーザまたはアプリケーションによって構成することができる。ユーザまたはアプリケーションのいずれもこの最大時間を定義しない場合、キャッシュ内のファイルのデフォルト最大常駐時間をキャッシュ管理機能によって選択できることを理解されたい。最大常駐時間により、キャッシュ・メモリに保管されるデータの量を調整することができる。特に、古いデータは追い出されることになる。
【００６３】
加えて、ユーザまたはアプリケーションは事前定義された拡張属性を介してキャッシュ優先順位クラスをリセットすることができる。キャッシュ優先順位クラス・リセットを受信すると、テープ上でのその常駐を保証した後に、ファイルがキャッシュから除去される。この場合も、これにより、キャッシュ・メモリに保管されるデータ・ファイルの量を管理することができる。
【００６４】
一般的なユースケースのサポートを改善するために、所与のファイルに関するキャッシュ優先順位クラスをユーザまたはアプリケーションによって時間の経過につれて変更することができる。たとえば、開示されている新規のテープ・アプライアンス・システムにファイルが書き込まれると、そのファイルはクラス１に割り当てられ、そのファイルがＦＩＦＯキャッシュに書き込まれることを保証する。これは有利なことに、ユーザ書き込みプロセス中にテープを位置決めする必要性を解消するものである。
【００６５】
クラス１のポリシーにより、データ・ファイルは直ちにテープに書き込まれ、これが実行された後、ファイルはＦＩＦＯキャッシュから廃棄される。次に、ユーザまたはアプリケーションがファイルを順次読み取りたいと希望する場合、読み取りコマンドを実行する前に、ユーザまたはアプリケーションは事前定義された拡張属性を介してデータ・ファイルにクラス３を割り当てる。次に、テープ・アプライアンスは、ファイルがＦＩＦＯまたはＬＲＵキャッシュ内にあるかどうかをチェックすることにより、新しいクラス割り当てを認識し、ファイルを処理する。ファイルがキャッシュ・メモリのＦＩＦＯまたはＬＲＵ領域内にある場合、１回読み取られるまでファイルが除去されないことが保証され、ファイルがキャッシュ・メモリのＦＩＦＯまたはＬＲＵ領域内にない場合、ファイルはテープからＦＩＦＯキャッシュに読み取られる。有利なことに、読み取りコマンドがアプリケーションまたはユーザによって送信される前にファイルがすでにＦＩＦＯキャッシュ内にあるので、この処理は高速読み取りアクセスを保証する。その上、テープ・ドライブ・システムからキャッシュ・メモリ内に大きいファイルをプリフェッチすることにより、ユーザがファイル全体を要求する前でも、ユーザ読み取りあたり可能な限り短い時間の間、テープ・ドライブ・システムを使用中に保持することができ、それにより、システムを解放し、他のユーザ／アプリケーションがそれを使用できるようにする。
【００６６】
テープ・アプライアンスの通常動作中に、たとえば、テープ・ドライブ・システム・サーバの作業負荷次第で、キャッシュ優先順位クラスについてより多くの組み合わせが可能であることを理解されたい。
【００６７】
バックアップ・データをまずキャッシュ・メモリに書き込むことにより、書き込み手順自体は有利なことに、少なくとも以下の理由によって、より短いものになる。キャッシュ・メモリのシーク時間は数ミリ秒程度であり、テープ・ドライブ・システムのテープの終わりに達し、書き込みを開始するのに必要なシーク時間は数十秒程度である。さらに、キャッシュ・メモリは典型的にテープより優れた帯域幅を提供する。たとえば、キャッシュ・メモリ・ハードディスクはより大きい帯域幅を有する。加えて、より短い書き込み時間（バックアップ・ウィンドウ）を有することにより、バックアップが終了する前にリモート・システムが故障する確率が低減される。テープ・ドライブ・システム・サーバ内にキャッシュ・メモリを有することのもう１つの利点は、テープ・ドライブ・システムのバックアップ・メタデータをそこに保管できることである。したがって、これにより、ユーザまたはアプリケーションがバックアップを照会したいと希望するときにテープにアクセスする必要性が回避される。
【００６８】
復元すべきデータがすでにキャッシュ内に存在しない場合でも、復元手順も加速することができ、実際に、システムは、同じバックアップに属し、同じバックアップ・バージョンまたはタイムスタンプを有するか、あるいは同じディレクトリに属すデータをプリフェッチすることができる。次に、これらのファイルは効率よくキャッシュ・メモリから取り出すことができる。増分ブロックレベル・バックアップが（ファイル・レベルとは対照的なものとして）使用される場合、テープ・ドライブ・システムのテープを１回通過することにより複数のファイルをキャッシュ内で再構築することができ、その場合、ブロックは典型的にテープ上でインターリーブされる。
【００６９】
もう１つの利点として、多くのファイルを並行して書き込んだ結果、ファイルがテープ上でインターリーブされず、実際に、その書き込みはまずキャッシュ・メモリで吸収され、次に古くなってキャッシュ・メモリから出されるときにその全体がテープに書き込まれる。別の言い方では、複数のユーザによる並行した同時書き込みあるいは読み取りまたはその両方を最適化するためにデータ・ファイルに関連する属性がキャッシュ管理機能によって使用される。
【００７０】
保管すべきいくつかの大きいデータ・ファイルがより小さいファイルに関連付けられ、それぞれの小さいファイルが大きいファイルの内容のサムネイルまたは低解像度バージョンを収容している場合、キャッシュ管理機能は高速アクセスのためにその小さいファイルをキャッシュ内に入れる。
【００７１】
キャッシュ・メモリは、磁気テープ媒体などの１つまたは複数のストレージ・デバイスを含むことができる。ファイル・システム・インターフェースは典型的にＬＴＦＳファイル・システムを使用して管理される。他のファイル・システムを使用できることを理解されたい。ＬＴＦＳファイル・システム・インターフェースはサーバ１０２内で実行され、そのサーバにはテープ・ライブラリとキャッシュ・メモリの両方が直接接続される。キャッシュ・メモリはＬＴＦＳファイル・システム用のキャッシュとして使用され、有利なことに記憶手段に保管されたデータへの高速ランダム・アクセスを可能にする。以下の文章ではキャッシュ・メモリとしてＨＤＤを使用しているが、任意の他の記憶媒体も使用できることを理解されたい。
【００７２】
諸実施形態では、キャッシュ・メモリのＨＤＤは、ロウ・デバイスとして、すなわち、いかなるファイル・システムも使用せずに、テープ・ドライブ・システム・サーバによって使用することができる（ｅｘｔ３など）。その場合、キャッシュは（ファイル・レベルのものとは対照的なものとして）ブロックレベルのものになるか、またはＬＴＦＳはＨＤＤ用のファイル保管機能を実現する必要が生じるであろう。
【００７３】
キャッシュ管理機能は、テープ・ドライブ・システム・サーバ１０２上で実行されるコンピュータ・プログラムとして実現し、サーバによって実行することができる。たとえば、図２に関連して説明すると、キャッシュ管理機能は、テープ・ドライブ・システム１０４を管理するように適合されたＬＴＦＳソフトウェアのＬＴＦＳコードの内部に実現することができる。
【００７４】
好ましくは、キャッシュ管理機能を実現するコンピュータ・プログラムはユーザ空間プログラム・コンポーネントである。有利なことに、ユーザ空間ソフトウェア・コンポーネントは（カーネル空間のものとは対照的なものとして）実現の複雑さの低減を考慮しているので、これにより可搬性を改善することができる。
【００７５】
諸実施形態では、キャッシュ管理機能およびすべてのキャッシング機能は、外部モジュールとしてＬＴＦＳの外部に実現することができる。それにより、ＬＴＦＳは、将来、任意の他のテープ・ファイル・システムで置き換えることができる。外部モジュールはテープ・ドライブ・システム・サーバのオペレーティング・システムとテープ・ファイル・システムの両方とインターフェースを取る必要が生じることを理解されたい。
【図１】
0006016939.tif 000002
【図２】
0006016939.tif 000003
【図３】
0006016939.tif 000004
【図４】
0006016939.tif 000005