JP2006294031A - ネットワーク上での動作のための記憶ドライブ、ネットワークからシーケンシャルアクセス記憶媒体におけるファイルデータにアクセスする方法、ファイルに基づくコマンドを変換するための論理およびｔｏｃを格納するための論理を含む記憶論理、磁気テープ、ならびにテープのデータおよびｔｏｃ領域にアクセスするための論理 - Google Patents

Abstract

【課題】記憶ドライブ論理およびスタンドアローンのテープファイル構造を提供する。
【解決手段】ファイル転送論理は、第１のプロトコルに従って、ファイルデータをネットワークにおよびネットワークから転送する。媒体アクセス論理は、第２のプロトコルに従って、ドライブに関連付けられるシーケンシャルアクセス記憶媒体にアクセスする。媒体管理論理は、第１のプロトコルに従ってネットワークから受取られた、ファイルに基づくコマンドを、第２のプロトコルに従うシーケンシャルアクセスデバイスコマンドに変換する。デバイスコマンドは、ドライブによるデータのアクセスを制御する。記憶媒体は、ファイル形式でデータを格納するためのデータ領域、およびデータ領域内でファイルの位置を索引付けする目次を格納するための目次（ＴＯＣ）領域を含む磁気テープであり得る。
【選択図】図２

Description

関連出願の相互参照
この出願は、２００５年４月６日に出願された「ネットワークに取付け可能な、ファイルにアクセス可能な記憶ドライブ（Network-Attachable, File-Accessible Storage Drive）」と題される米国仮出願番号第６０／６６９，０５８号、および２００５年４月１５日に出願された「ネットワークに取付け可能な、ファイルにアクセス可能な記憶ドライブ（Network-Attachable, File-Accessible Storage Drive）」と題される米国仮出願番号第６０／６７１，９５０号の利益を主張し、これらの開示は本明細書に全文が援用される。

発明の背景
１．発明の分野
この発明は概して記憶装置に関し、より特定的には、ネットワーク上で動作する記憶ドライブに関する。

２．関連技術
図１は、従来のストレージエリアネットワーク（ＳＡＮ）１００を示す。テープライブラリ１０２は複数のテープドライブ１０４を含み、テープドライブ１０４の中に、データを格納するためのテープカートリッジ１０６が挿入される。ネットワーク上のユーザは、オートメーションサーバ１０８などの制御ノードを使用することによって、ライブラリと、ビデオサーバ１１０などの、ネットワーク上の他のノードとの間でファイルを転送したいと思うだろう。

現在のテープドライブおよびライブラリは、ＳＣＳＩまたはファイバチャネルインターフェイスなどのデバイスプロトコルを使用してデータを通信する。しかしながら、ネットワーク上のユーザは、イーサネット（登録商標）インターネットプロトコルなどのネットワークプロトコルに従ってネットワークと通信するワークステーションを動作させているだろう。図１を参照して、アーカイブ（または記憶）マネージャ１１２は、従来のネットワークにおいてデバイスプロトコルとネットワークプロトコルとの間のプロトコル変換を実行する。その変換に基づいて、アーカイブマネージャ１１２におけるデータムーバ１１４はそれぞれ、デバイスプロトコルに従って、データをテープドライブ１０４から読取る、またはデータをテープドライブ１０４に書込む。

さらに、典型的なテープドライブは、たとえばブロック形式で情報のアドレス指定を要求する未加工のデータ形式を利用する。しかしながら、ユーザは典型的にはファイル形式を使用してデータにアクセスすることを望む。アーカイブマネージャ１１２は、ファイル形式と未加工のデータ形式との間の変換を処理する。アーカイブマネージャは、さらに、データベースサーバ１１６を使用して、ライブラリに格納されたデータについてのメタデータを格納し、ライブラリにおけるデータの物理的な位置へのファイルのマッピングをもたらす。

従来のテープバックアップホストアプリケーションは、バックアップのためにハードドライブから選択されたファイルの組をテープに格納する。アプリケーションは、各々のバ
ックアップデータの組のために目次（ＴＯＣ）を格納してもよい。ＴＯＣは、テープ、およびホストアプリケーションを動かすサーバの半導体メモリに格納されてもよい。複数のバックアップデータの組は、共通するいくつかのファイル、たとえば、異なるときに格納された同一のファイルを格納してもよい。

このアプリケーションはＴＯＣを使用して、テープ上の特定のデータの組における特定のファイルにアクセスするためにドライブヘッドがどこに移動しなければならないかを判断する。しかしながら、ホストアプリケーションは、特定のファイルのためのブロック位置を含むＴＯＣを見つけるために、テープ上のすべてのデータの組に関する具体的な知識を持たなければならない。同一ファイルの複数のコピーが異なるデータの組に格納される可能性があるので、特定のファイルの正確なコピーのための正確なブロック位置を含む正確なＴＯＣを見つけるために、ホストは複雑な規則の組を利用しなければならない。この構成の不利な点は、要求されたデータファイルを見つけるためにホストアプリケーションのみに依存することである。さらに、特定のファイルの正確なコピーのための正確なブロック位置を見つけるために、正確なＴＯＣが突き止められるまでホストはすべてのＴＯＣを読取らなければならない。

現在のＳＡＮの構成に対する別の不利な点は、アーカイブマネージャおよびデータムーバ用に今日市場で入手可能なソフトウェアが独占権下にあり、時間とともに変化し得ることである。これは、第三者のソフトウェアに依存するのを懸念することなく、非常に長い期間ライブラリにデータをアーカイブすることができるようになる必要性と対照をなす。

発明の簡単な概要
この発明のいくつかの局面は、ネットワーク上での動作のための記憶ドライブ論理を提供する。ファイル転送論理は、第１のプロトコルに従って、ファイルデータをネットワークにおよびネットワークから転送する。媒体アクセス論理は、第２のプロトコルに従って、ドライブに関連付けられるシーケンシャルアクセス記憶媒体にアクセスする。媒体管理論理は、第１のプロトコルに従ってネットワークから受取られた、ファイルに基づくコマンドを、第２のプロトコルに従うシーケンシャルアクセスデバイスコマンドに変換する。デバイスコマンドは、ドライブによるデータのアクセスを制御する。

たとえば、ファイル転送論理はＦＴＰサーバを含んでもよく、記憶ドライブはテープドライブを含んでもよく、記憶媒体は磁気テープを含んでもよく、第２のプロトコルはテープ通信プロトコルを含んでもよい。第１のプロトコルはイーサネット（登録商標）プロトコルであってもよく、第２のプロトコルはＳＣＳＩプロトコルであってもよい。

ファイルデータは複数のファイルを含んでもよく、各々のファイルはデータペイロードおよびメタデータを含む。この発明のいくつかの局面に従って、媒体管理論理はデータペイロードを記憶媒体に格納することができ、記憶媒体上で対応するデータペイロードの物理的な位置にファイルを索引付けする目次（ＴＯＣ）を含むメタデータを格納することができる。媒体管理論理は、記憶媒体上の既存のデータを消去することなく、記憶媒体の始めの近くにメタデータを書込み得る。

この発明のいくつかの局面に従って、媒体管理論理はネットワークへの転送のために、記憶媒体からデータペイロードの一部を選択することができ、データペイロードの選択された部分の特徴を反映するように、データペイロードに関連付けられるメタデータを修正することができ、その結果、データペイロードの選択された部分および関連付けられる修
正されたメタデータの、ネットワークへの転送を可能にする。

この発明のいくつかの局面に従って、磁気テープは、ファイル形式でデータを格納するためのデータ領域、およびデータ領域内でファイルの位置を索引付けする目次を格納するための目次（ＴＯＣ）領域を含む。ＴＯＣ領域は、データをテープに書込む方向に対してデータ領域の前に位置してもよい。ＴＯＣ領域におけるＴＯＣは、データ領域におけるデータをいずれも消去することなく修正され得る。ＴＯＣ領域はテープの始めの近くに位置してもよい。

発明の詳細な説明
以下の記載は、当業者がこの発明をなし、使用することができるように提示される。具体的な装置、技術、および用途の記載は、単に例として提供される。本明細書に記載される例に対するさまざまな修正は当業者に容易に明らかであり、本明細書に規定される一般的な原理は、この発明の精神および範囲から逸脱することなく他の例および用途に適用されてもよい。したがって、この発明は、本明細書に記載され、示される例に限定されるように意図されるものではなく、特許請求の範囲と整合性のある範囲に一致するように意図される。

図２は、この発明の実施例に従う記憶ドライブ２０１を示す。ドライブは、ドライブに関連付けられる記憶媒体からデータを読取る、および記憶媒体にデータを書込むための、標準的な記憶ドライブ２００（たとえば、この発明の譲受人によって製造されるＳＤＬＴ６００テープドライブ）に見られるものなどの媒体アクセス論理を含む。この発明の強化されたドライブに関連付けられるデータ転送論理２０２は、ネットワークにおよびネットワークからデータを転送する。たとえば、データ転送論理２０２はこの発明のドライブ内のＦＴＰサーバであってもよい。ｈｔｔｐサーバ２０４は、この発明の実施例に従って、ネットワーク上のユーザが記憶ドライブにアクセスすることを可能にする。

データ転送論理２０２は第１のプロトコルに従ってネットワークと通信するが、標準的なドライブ２００における媒体アクセス論理は第２のプロトコルに従ってデータを通信する。媒体マネージャ２０６は、第１のプロトコルと第２のプロトコルとの間の変換を処理し、それによって、ネットワークの中の他の場所でその機能性を有する必要性を取り除く。記憶ドライブはテープドライブであってもよく、第１のプロトコルはイーサネット（登録商標）などのネットワークプロトコルであってもよく、第２のプロトコルはＳＣＳＩまたはファイバチャネルインターフェイスなどのデバイスプロトコルであってもよい。

媒体マネージャ２０６は、さらに、ファイル形式でネットワークから受取られたコマンドを、標準的なテープドライブによって使用されるデータブロック形式などの別の形式に変換し得る。コマンドは、ドライブとネットワーク上のノードとの間のデータの通信を制御する。データ転送論理２０２がＦＴＰサーバを含む場合、媒体マネージャ２０６は、ファイルに基づくコマンドを、他の形式でデータにアクセスし、操作するコマンドに変換するように、標準的なＦＴＰコマンドに対する修正を含んでもよい。他の形式とは、線形の形式でデータブロックにアクセスし、操作するテープドライブのためのコマンドなどである。その場合には、たとえば、媒体マネージャ２０６は対応するデータブロックに各々のファイルをマッピングしてもよく、ＳＣＳＩファイルマークによってファイルを分けてもよい。媒体マネージャ２０６は、ファイルの位置を示すメタデータとして、各々のファイルにおける第１のブロックの位置をメモリに格納してもよい。

データは少なくとも１つのファイルを含んでもよく、そのファイル自体がデータペイロードおよびメタデータを含んでもよい。媒体マネージャ２０６はドライブによって受取ら
れたメタデータをメモリに格納することができ、データペイロードのすべてまたは一部を記憶媒体に書込むことができる。（本出願において媒体マネージャの「格納」、「読取」、または「書込」を参照するとき、媒体マネージャは実際の読取／書込動作自体を実行する必要はなく、代わりに、ドライブにおいて、たとえば媒体アクセス論理において、標準的な読取／書込の機能性を制御し得ることを当業者は認識する。）メモリは、ドライブにおけるＲＡＭなどの半導体メモリ、または記憶媒体を保持するデータカートリッジにおけるチップであってもよい。

１つの実施例では、ドライブが記憶媒体上に格納するためにネットワークからデータを受取る間、媒体マネージャ２０６は受取られたメタデータの一部のみをメモリに格納する。しかしながら、媒体マネージャはメタデータのすべて、およびデータペイロードのすべてまたは一部を記憶媒体上に依然として書込み得る。メモリに格納されたメタデータは、記憶媒体上に格納されたデータペイロードを記載する目次（ＴＯＣ）２０８を含んでもよい。ＴＯＣ２０８は、当該技術分野において公知のディレクトリ情報、ならびにファイル名、記憶媒体上のファイルの物理的な開始位置（たとえば、ブロック）、ファイルの大きさ、およびタイムスタンプなどの他のメタデータ（ファイルの属性）を含んでもよい。ＴＯＣを格納するメモリはＴＯＣキャッシュとして機能し、ネットワークにおけるユーザが、ドライブに格納された、ファイルに関するメタデータに素早くアクセスできるようにする。この高速アクセスは、媒体がテープのような順次アクセス可能なものである場合に特に有益である。

媒体マネージャ２０６は、ネットワークへの転送のために記憶媒体からデータペイロードの一部（またはすべて）を選択することができ、データペイロードの選択された部分の特徴を反映するように、データペイロードに関連付けられるメタデータを修正することができ、その結果、関連付けられる修正されたメタデータとともにデータペイロードの選択された部分を新しいファイルとして転送することを可能にする。たとえば、選択された部分がデータペイロード全体よりも小さい場合、媒体マネージャは、その部分の大きさを反映するようにメタデータを更新するために、関連付けられるメタデータ（ＴＯＣ）を修正するであろう。したがって、この例では、媒体マネージャは元のファイルから選択されたペイロードデータ部分のラップを解き、新しいファイルを作成するために適当なメタデータを用いてその選択されたペイロードデータ部分を再びラップしたことになる。ＭＸＦ形式（以下に記載）を利用する実施例では、媒体マネージャはこれらの機能のためにＭＸＦファイルアンラッパおよびファイルラッパ２１０を使用してもよい。ＸＭＬコンバータ２１２は、ＸＭＬ形式でのＭＸＦヘッダの生成を可能にする。

別の例として、ユーザはファイルの所有権の変更、またはビデオ映画の許可された再生回数の増加などのライセンス条件の変更を示したいと思うだろう。媒体マネージャはオンチップＴＯＣキャッシュにおいてこの情報を更新することができ、記憶媒体上で殆ど同時にＴＯＣ情報を変更することができる。

この発明の１つの実施例に従って、データペイロードが媒体に書込まれている間は媒体マネージャがＴＯＣ２０８を記憶媒体に書込まないことに注目されたい。たとえば、記憶媒体がテープである場合、媒体マネージャ２０６は、テープがこの発明のテープドライブに挿入されるときにＴＯＣ情報への後の高速アクセスを考慮に入れるように、テープの始め（ＢＯＴ）にＴＯＣ２０８を書込んでもよい。しかしながら、データペイロードが書込まれているとき、ＴＯＣは同時にテープに書込まれることができない。媒体マネージャはペイロードデータのテープへの書込の際の一時的な停止を待つことができ、たとえばファイルまたはパーティション（以下に記載）が書込まれるのを待つことができ、次いでＴＯＣを書込むためにＢＯＴに行くことができる。

この発明の別の実施例に従って、媒体マネージャ２０６は、ペイロードデータのテープへの書込を完了するまで待つことができ、テープを取出す要求に応答して、取出す前にメモリから、ＢＯＴまたは他の予め定められた位置（たとえば、ＢＯＴの前）から始まるテープにメタデータを書込むことができる。ＢＯＴの前にメタデータを格納する例は、２００４年６月１日に出願され、２００４年１２月９日に公開された、「補助メモリのエミュレーション（Emulation of Auxiliary Memory）」と題される米国出願番号第１０／８５８，９１１号において与えられ、これはこの発明の譲受人に譲渡され、引用によって本明細書に全文が援用される。その例では、ＴＯＣはｅＭＡＭ領域における追加の部分に位置してもよい。ＴＯＣを記憶媒体に書込むことによって、媒体自体はスタンドアローンのファイルシステムになる。媒体がこの発明の実施例の別のドライブに挿入されるとき、媒体マネージャは記憶媒体からＴＯＣ情報を読取ってもよく、そのＴＯＣ情報を高速アクセスのためにメモリに再び格納してもよい。

ユーザは、既存のメタデータにメタデータを追加したいと思うだろう。たとえば、ユーザはスペイン語の字幕を含むようにビデオファイルを修正したいと思うだろう。ビデオ業界では、字幕は典型的にはデータペイロードではなくメタデータの一部として格納される。従来のシステムにおいて新しい字幕を追加することは、典型的には、ファイル全体を書き換えることを必要とするであろう。この発明の実施例は、この必要性をなくす。字幕データが大きな記憶領域を必要とし得るので、媒体マネージャ２０６はチップ上にこのデータを書込むことを避けるように構成されてもよい。その代わりに、媒体マネージャは新しいメタデータを記憶媒体に（たとえば、ＢＯＴの前のｅＭＡＭ領域の部分に）格納してもよく、ＴＯＣオンチップキャッシュにおけるポインタ（このポインタは、さらに、１つの実施例では、テープ上のＴＯＣ領域に位置する）を記憶媒体における新しいメタデータの位置に与えてもよい。この発明のこの実施例に従って、元のファイルがドライブから読取られるとき、ＴＯＣにおけるポインタによって字幕メタデータが同様に検索されることになるであろう。

この発明のドライブはすべてのバックアップデータの組のためにただ１つのＴＯＣを使用し得るので、ドライブは記憶媒体上で特定のファイルを見つけるために複数のＴＯＣを読取る必要性をなくす。したがって、以前にバックアップされたファイルをバックアップするようにホストアプリケーションがドライブに命令する場合、記憶媒体、たとえばテープ上の既存のデータの終わりの後ろにファイルを書込むことができ、記憶媒体上の新しい位置をファイル（つまり、バックアップ時のファイルの現在のコピー／バージョン）の位置として指すようにＴＯＣを更新することができる。

ファイルを削除するようにホストがドライブに命令する場合、ドライブは、記憶媒体上のファイルを実際に消去する必要なくファイルへのどの参照も排除するようにＴＯＣを単に更新し得る。同じ文脈で、ファイル（たとえば、字幕）は、記憶媒体上のデータの終わりの後ろに新しいファイルを書込むことによって、および古いファイルを実際に消去することなく古いファイルへの参照を排除しながら記憶媒体上の新しいファイルの始め（たとえば、第１のブロック）を指すようにＴＯＣにおけるポインタを更新することによって置換えられてもよい。別の例では、ファイルの一部は、ファイル自体を実際に修正することなくその部分の終点のみを参照するようにＴＯＣを更新することによって、記憶媒体上に「事実上」格納されてもよい。ＴＯＣにおけるファイルの名前は、さらに、ＴＯＣがここで元のファイルの一部（「ビデオの抜粋」）のみを参照することを反映するように修正されてもよい。多くの例では、ＴＯＣのみを更新するこの機能は、記憶媒体全体を書き換える必要性をなくす。

いくつかの実施例では、メタデータ（たとえば、字幕）が、最初に書込まれ得る、記憶媒体上の領域（たとえば、ｅＭＡＭ領域の部分）よりも大きい場合、媒体マネージャはそ
の第１の領域にメタデータの一部を格納し、たとえば残余のメタデータをテープ上のデータの終わり（ＥＯＤ）に、またはパーティション（以下のパーティションの記載を参照）内のデータの終わりに追加することによって、残余の部分を記憶媒体の別の領域に格納するであろう。テープ上および／またはオンチップのＴＯＣは、テープ上のメタデータの最初の部分および残余の部分の両方の位置にポインタを与えるであろう。媒体マネージャは、次いで、メタデータへのアクセスをもたらすようにこのポインタの情報を読取ることができる。

図３を参照して、テープは少なくとも１つのパーティションにフォーマットされてもよく、各々のパーティションは少なくとも１つのトラックの対３００を含む。（この図は、各々のパーティションがただ１つのトラックの対を含む例を示す。）線形の形式を辿るテープ（ＳＤＬＴなど）上では、データは蛇行したパターンに従って、つまり第１の物理的なトラック（通常は「トラック０」と表わされる）のためにＢＯＴからテープの終わり（ＥＯＴ）まで書込まれ、次いで、第２の物理的なトラック（たとえば、「トラック１」）のためにＥＯＴからＢＯＴまで書込まれる。トラックの対は、１つの「往復」、たとえばトラック０および１の両方から構成される。この態様でテープをフォーマットすることによって、媒体マネージャは、テープ上のデータの終わり（ＥＯＤ）から始まるデータを追加する（通常なされているように）ことによってだけでなく、パーティション内のデータの終わりから始まるデータを追加することによってもデータをテープに追加し得る。さらに、媒体マネージャは他のパーティションに影響を及ぼすことなくパーティション内のデータを消去することができ、消去されたパーティションの始めから新しいデータが書込まれることを可能にする。媒体マネージャは、さらに、パーティションの数およびその対応するパーティションの数によって索引付けされるファイルの一覧を、メモリにおけるメタデータとして格納してもよい。各々のトラックの対が長いので、この分割方法は特に、映画およびテレビ番組のためのビデオファイルなどの大きなファイルに非常に好適である。

媒体マネージャは、メタデータがパーティションの始め、特にテープ上の第１のパーティションの始めに書込まれるようにすることができる。メタデータを保持する第１のパーティションの部分は、アドレス指定の目的で論理的な第１のパーティション（「パーティション０」）（破線によって示される）として処理されてもよく、残余の物理的な媒体は第２の論理的なパーティション（「パーティション１」）として処理される。第１の論理的なパーティションの長さがトラックの対の残りと比較して短い可能性があるので、パーティション１におけるデータペイロードは事実上、殆どＢＯＴに存在し得る。パーティション０の長さは固定されてもよい。

この発明のドライブは業界標準のマテリアルエクスチェンジフォーマット（ＭＸＦ）形式を利用してもよい。ＭＸＦ形式は、当該技術分野において周知であり、たとえば提案された標準規格ＳＭＰＴＥ３７７Ｍ、「マテリアルエクスチェンジフォーマット（ＭＸＦ）ファイル形式仕様書（標準）（Material Exchange Format (MXF) File Format Specification (Standard)）２００３年６月２４日」に記載され、これは引用によって本明細書に全文が援用される。当該技術分野において公知であるように、ＭＸＦメタデータはＫＬＶ（キー／長さ／値）フィールド４００、４０２、４０４にフォーマットされてもよい。ＭＸＦメタデータは、ファイル構造、本体の内容（たとえば、ＭＰＥＧ、ＤＶ）、キーワードまたは題、字幕、編集ノート、場所、時間、日付、およびバージョン番号などの属性に関する情報を担持してもよい。

図４は、この発明の実施例に従うＭＸＦメタデータを含むファイル構造、ならびにデータペイロードおよびＭＸＦファイルマーカの終わりを示す。空間を節約するために、この発明の媒体マネージャは典型的には、入ってくるファイルからのＭＸＦメタデータのすべてをメモリにおけるＴＯＣに書込むのを避けることができるが、その代わりに、アプリケ
ーションに適当であると考えられるメタデータのみを選択するであろう。このような選択されたメタデータは、たとえば、ＵＭＩＤ、ＯＰ、タイムコード、およびエッセンスタイプを含んでもよい。

この発明のドライブは、ＭＸＦファイルおよび非ＭＸＦファイルの両方を処理し得る。ＭＸＦファイルは典型的には、ＭＸＦ専用のメタデータおよび非ＭＸＦ専用のファイルシステムメタデータの両方を含むことになる。図５を参照して、媒体マネージャ２０６はしたがって、ＭＸＦファイルのために、選択されたＭＸＦメタデータおよび非ＭＸＦファイルシステムメタデータの両方を含むＴＯＣ２０８を作成することになる。非ＭＸＦファイルのために、ＴＯＣは非ＭＸＦファイルシステムメタデータのみを含んでもよい。ＴＯＣに書込まれ得る非ＭＸＦ専用のファイルシステムメタデータのうちのいくつかは、たとえばファイル名（または、フォルダ名）、ファイルの大きさ、テープ上のファイルの位置、およびフォルダツリーにおけるファイルの論理的な位置を含んでもよい。

ＴＯＣは、各々のファイルが書込まれるときに動的に作成され得る。ＴＯＣは、テープ上に格納される各々のファイルのためにファイルシステムメタデータとディレクトリ情報とを保存することによって、各々のテープがスタンドアローンのファイルシステムとして機能することを可能にする。１つの実施例では、各々のＭＸＦファイルのために選択されたＭＸＦメタデータのコピーをテープ上に保存することによって、ＴＯＣはＭＸＦデータへの高速アクセスを可能にする。

図６は、この発明の実施例に従う、記憶ドライブを含むネットワークを示す。同様に、図７は、この発明の実施例に従うドライブおよびライブラリの、ＧｉｇＥスイッチファブリック７００を介する、ネットワーク、アプリケーション、またはワークステーションへの接続性を示す。ドライブはデータムーバの必要性をなくし、かつアーカイブマネージャがネットワークプロトコルとデバイスプロトコルとの間で変換し、テープ上の物理的な位置へのファイルのマッピングを維持する必要性をなくすことに注目されたい。この発明の実施例に従って、ホストアプリケーションはそれ自体のＴＯＣを維持する必要がなく、ファイル名をドライブに与えることのみが必要である。したがって、この発明は記憶ドライブへの「プラグアンドプレイ」アクセスを可能にする。

上記の記載は、明確にするために、種々の機能ユニットを参照してこの発明の実施例を記載してきたことが理解される。しかしながら、種々の機能ユニット間の機能性の好適な分散はいずれも、この発明を損なうことなく使用され得ることは明らかである。したがって、具体的な機能ユニットを参照することは、厳密な論理的または物理的な構造または編成を示すのではなく、記載される機能性をもたらすための好適な手段への参照として単に見られるべきである。

この発明は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せを含む任意の好適な形状で実現され得る。この発明の異なる局面は、１つ以上のデータプロセッサおよび／またはデジタル信号プロセッサ上で作動するコンピュータソフトウェアまたはファームウェアとして少なくとも部分的に実現されてもよい。この発明の実施例の要素および構成要素は、任意の好適な方法で物理的、機能的、および論理的に実現されてもよい。実際に、機能性は単一のユニットにおいて、複数のユニットにおいて、または他の機能ユニットの一部として実現されてもよい。したがって、この発明は単一のユニットにおいて実現されてもよく、または異なるユニットとプロセッサとの間で物理的および機能的に分散されてもよい。

この発明はいくつかの実施例に関連して記載されてきたが、本明細書に記載される具体的な形状に限定されるように意図されるものではない。むしろ、この発明の範囲は特許請
求の範囲によってのみ限定される。さらに、特徴は特定の実施例に関連して記載されているように見えるかもしれないが、記載される実施例のさまざまな特徴はこの発明に従って組合せられてもよいことを当業者は認識するであろう。さらに、実施例に関連して記載されるこの発明の局面は発明として独立し得る。たとえば、本明細書に記載されるパーティションの形式は、この発明の他の実施例に関連して使用されてもよく、またはいくつかの例では、必ずしもこの発明の他の実施例に関連して使用されなくてもよい。

さらに、さまざまな修正および変更がこの発明の精神および範囲から逸脱することなく当業者によってなされ得ることが理解される。この発明は前述の例示的な詳細によって限定されるべきではなく、特許請求の範囲に従って規定されるべきである。

従来のストレージエリアネットワークの図である。 この発明の実施例に従う記憶ドライブの図である。 この発明の実施例に従うテープのフォーマッティングの図である。 この発明の実施例に従う、ＭＸＦメタデータを含むファイル構造の図である。 この発明の実施例に従う目次の構造の図である。 この発明の実施例に従う、記憶ドライブを利用するライブラリを組入れるネットワークの図である。 この発明の実施例に従うドライブまたはライブラリの、ＧｉｇＥスイッチファブリックを介する、ネットワーク、アプリケーションまたはワークステーションへの接続性の図である。

符号の説明

２０１ 記憶ドライブ
２０２ ＦＴＰサーバ
２０４ ＨＴＴＰサーバ
２０６ 媒体マネージャ
２０８ 目次（ＴＯＣ）
２１０ ＭＸＦラッパ／アンラッパ
２１２ ＸＭＬコンバータ

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. 請求項２６に記載の、前記ＴＯＣ領域における前記ＴＯＣを書込むようにさらに動作可能である、請求項３８に記載の論理。