JP6005010B2 - 複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム - Google Patents
複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム Download PDFInfo
- Publication number
- JP6005010B2 JP6005010B2 JP2013167682A JP2013167682A JP6005010B2 JP 6005010 B2 JP6005010 B2 JP 6005010B2 JP 2013167682 A JP2013167682 A JP 2013167682A JP 2013167682 A JP2013167682 A JP 2013167682A JP 6005010 B2 JP6005010 B2 JP 6005010B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- index
- media
- medium
- tape
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0682—Tape device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
Description
本発明は、テープドライブ用のファイルシステムにおいて、１つのファイルを複数のテープメディアに分割して保管、即ちスパニング（ｓｐａｎｎｉｎｇ）する方法に関する。
テープメディア（テープカートリッジ、メディア）をあたかもＨＤＤやＵＳＢメモリのようにファイルシステム経由で利用する方法である。例えば、ＬＴＦＳ（Linear Tape File System）は、テープメディアをデータ・パーティション（ＤＰ：Data Partition）とインデックス・パーティション（ＩＰ：Index Partition）と呼ばれる２つの領域に分割して管理する。ＬＴＦＳは、ファイル本体をテープメディアのＤＰに保管すると共に、インデックスと呼ばれるファイル名やファイルを特定するためのIDなど、ファイルに関するメタデータもテープメディアのＩＰにＸＭＬファイル形式で保管する。インデックスには、１つのテープメディア上に保管された全てのファイルのメタデータが含まれる。現在のＬＴＦＳ フォーマットでは１つのファイルを複数のテープメディアに分割して保管することは許容していない。
例えば、第５世代のＬＴＯ（Linear Tape Open）テープドライブではメディアの最大容量１．５TBを超えてデータを書込むことはできない。また、既にある程度のデータが書き込まれているメディアに別のデータをさらに追記する場合には、メディアの最大容量よりは少ない容量のデータしか追記できない。
更に、書き込むファイルのサイズも書き込みを始める時点では決まっていないことがある。放送業界などで番組作成のための録画をリアルタイムに行う場合や、セキュリティシステムでＵＳＢカメラなどの映像をメディアに直接書き続ける場合である。このような場合メディアに追記しているファイルのサイズがメディアの容量を超えることになる。それまでに書かれたファイルを分割して保管しておき、続きのデータを別のメディアに書き続けることになる(ｓｐａｎｎｉｎｇ)。
スパニングされたファイルに変更（データの追記および一部削除、ファイル名の変更など)を実施した場合、ファイルの部分を保管する全てのテープメディアのインデックス情報 (ファイルサイズ、タイムスタンプ、ファイル名など) を更新する必要が生じる。
テープドライブにテープメディアがマウントされると、テープメディアからインデックスを読み出すのは時間がかかるため、ＬＴＦＳはメモリないしハードディスク上に、テープメディア上に記録されたインデックスのコピーを保持する。このコピーの内容がテープメディア上のインデックスと同一の情報を持つ場合は、テープメディア上のインデックスを利用することはない。言い換えると、ＬＴＦＳがテープメディア上のインデックスの情報を読み出すのは、メモリやハードディスク上のインデックスのコピーがなにがしかの理由で利用できない場合である。
テープドライブにテープメディアがマウントされると、テープメディアからインデックスを読み出すのは時間がかかるため、ＬＴＦＳはメモリないしハードディスク上に、テープメディア上に記録されたインデックスのコピーを保持する。このコピーの内容がテープメディア上のインデックスと同一の情報を持つ場合は、テープメディア上のインデックスを利用することはない。言い換えると、ＬＴＦＳがテープメディア上のインデックスの情報を読み出すのは、メモリやハードディスク上のインデックスのコピーがなにがしかの理由で利用できない場合である。
スパニングしたファイルのインデックスを更新する時に、そのファイルが格納された一部のテープメディアのインデックスしか更新していない場合に問題が生じる。ＬＴＦＳがテープメディア上のインデックスを読み出す場合にどのテープメディアに格納されたインデックスの情報を採用して良いか判断が付かなくなる。ファイル部分の変更の場合でも、スパニングされたファイルを保管する全てのテープメディアのインデックス情報）を更新する必要が生じる。
テープライブラリを利用しテープドライブ・システムにマウントされたテープメディアを交換する場合、平均でも２分、長い場合では４分以上の時間が必要となる。ファイル本体をテープメディアに記録してもインデックスを更新する前にテープドライブの電源が落ちるなどトラブルが生じた場合に問題が生じる。ＬＴＦＳでは、インデックスに登録されていないファイルの本体を利用することができなくなるため、標準の設定ではファイル本体の書き込み中は５分ごとにインデックスを更新する。
特許文献１は、ファイル管理に必要なシステム情報を各メディアに分散し保管するため、システム情報を１本のメディアに書き込むように再配置する技術を開示する。
しかし、特許文献１は、１つのファイルが１のメディアに納まらない場合を１つのファイルのメタデータがどのメディアの情報が代表するのか示していない。従来のＬＴＦＳとして、複数本のカートリッジに分割してファイルを書き込むにあたり、一定時間毎にテープドライブにマウントされたテープメディアを入れ替えることはパフォーマンス (書き込み所要時間に与える影響) の観点で現実的ではない。
従って、本発明の目的は、ＬＴＦＳにおいて、1つのファイルを複数のテープメディアに分割して保管するスパニング機能を有する方法及びストレージ・システムを提供することである。
かかる目的のもと、本発明は、少なくとも１つのテープドライブを含むテープストレージ・システムにおいて１つのファイルを複数のテープメディアに分割して保管（スパニング）する方法である。この方法は、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分（ファイル部分）を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メデイアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を含み、
前記世代情報は、前記システムが分割保管された前記ファイルの読み出し要求を受けた場合、その値が最大値に有するファイル部分を保管したメディア上のインデックスを確保し前記ファイルのメタデータを読み出すことを特徴とする。
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分（ファイル部分）を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メデイアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を含み、
前記世代情報は、前記システムが分割保管された前記ファイルの読み出し要求を受けた場合、その値が最大値に有するファイル部分を保管したメディア上のインデックスを確保し前記ファイルのメタデータを読み出すことを特徴とする。
また、このスパニングする方法は、前記所定のフォーマットが、
前記メディアは、ストレージ・システムのシーケンシャルアクセスのためのファイルシステムにより読み書きを可能にするために、2以上のパーティションに区分され、
前記パーティションは、ファイルのメタデータ（インデックス）を保管するインデック・パーティション（ＩＰ）とファイルのデータを保管するデータ・パーティション（ＤＰ）とを含む。
前記メディアは、ストレージ・システムのシーケンシャルアクセスのためのファイルシステムにより読み書きを可能にするために、2以上のパーティションに区分され、
前記パーティションは、ファイルのメタデータ（インデックス）を保管するインデック・パーティション（ＩＰ）とファイルのデータを保管するデータ・パーティション（ＤＰ）とを含む。
また、このスパニングの方法は、各メディアが保管する前記世代情報が、最初は１つのファイルを分割して後続のメディアに書き込む毎に１つ増加させた値として、各メディアに保管すること、を含む。
また、このスパニングする方法において、前記ファイル部分の変更する場合に、前記ファイル部分の変更の履歴として前記世代情報の最大値を１つ増加させて更新して前記メディアに保管すること、を含む。
また、このスパニングする方法は、前記ファイル部分を保管する前記各メディアに前記ファイルを指示するＩＤ（ＵＵＩＤ）を前記インデックスとして保管することと、を含み、
前記ファイル部分を保管する複数の前記メディアに、前記ファイルのＩＤと関連付けて１つの前記ファイルの部分であることを指示することを特徴とする。
前記ファイル部分を保管する複数の前記メディアに、前記ファイルのＩＤと関連付けて１つの前記ファイルの部分であることを指示することを特徴とする。
また、このスパニングする方法は、前記１つのファイルの部分を保管する前記メディアが、前記ファイルの他のファイル部分を保管する前記各メディアを指示するＩＤの少なくとも１つを前記ファイルに関連付けて、インデックスとして保管することと、を含む。
また、このスパニングする方法は、第１のファイル部分を保管したメディアに、第１のファイル部分に対して直前のファイル部分を保管する前記メディアのＩＤ（直前メディアＩＤ）と、第１のファイル部分の直後のファイル部分を保管する前記メディアのＩＤ（直後メディアＩＤ）と、前記インデックスとして更に保管することと、を含む。
また、このスパニングする方法は、前記ファイルを変更（データの追記、データの一部削除、ファイル名の変更など）する要求をテープストレージ・システムが受け取った場合、前記システムは更新に該当するファイル部分を保管する前記メディアのＩＤを特定して前記メディアをドライブにマウントすることと、
前記ＩＤのメディアのインデックスを前記システムのメモリ又はハードディスクにコピーすることと、
前記ファイル部分の変更に基づいて前記メディアの前記ＤＰのデータを変更すること、
前記ＤＰのデータの変更と同時に、前記ファイル部分の変更内容を反映するように前記メモリ上の前記インデックスを変更することと、
前記変更されたメモリ上の前記インデックスに、前記変更時点でのドライブの前記世代情報を含ませことと、
所定の時点（マウント中５分毎、アンマウント時）で前記メディアのＩＰに前記インデックスを登録すること、を含むことを特徴とする。
前記ＩＤのメディアのインデックスを前記システムのメモリ又はハードディスクにコピーすることと、
前記ファイル部分の変更に基づいて前記メディアの前記ＤＰのデータを変更すること、
前記ＤＰのデータの変更と同時に、前記ファイル部分の変更内容を反映するように前記メモリ上の前記インデックスを変更することと、
前記変更されたメモリ上の前記インデックスに、前記変更時点でのドライブの前記世代情報を含ませことと、
所定の時点（マウント中５分毎、アンマウント時）で前記メディアのＩＰに前記インデックスを登録すること、を含むことを特徴とする。
更に、かかる目的のもと、本発明は、少なくとも１つのテープドライブを含み、１つのファイルを複数のテープメディアに分割して保管（スパニング）するテープストレージ・システムである。このシステムは、
前記システムの読み書き制御は、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メデイアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を含み、
前記世代情報は、前記システムが分割保管された前記ファイルの読み出し要求を受けた場合、その値が最大値に有するファイル部分を保管したメディア上のインデックスを確保し前記ファイルのメタデータを読み出すことを特徴とする。
前記システムの読み書き制御は、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メデイアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を含み、
前記世代情報は、前記システムが分割保管された前記ファイルの読み出し要求を受けた場合、その値が最大値に有するファイル部分を保管したメディア上のインデックスを確保し前記ファイルのメタデータを読み出すことを特徴とする。
更に、かかる目的のもと、本発明は、少なくとも１つのテープドライブを含むテープストレージ・システムにおいて１つのファイルを複数のテープメディアに分割して保管（スパニング）するプログラムである。このプログラムは、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メディアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を前記システムに実行させることを特徴とする。
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管するようにフォーマットすることと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分を保管する複数の前記各メディアを指示（identify）するＩＤの少なくとも１つを前記ファイルに関連付けて管理することと、
前記メディアに前記各ファイル部分に保管および更新する履歴の回数を示す世代情報を、各メディアに前記インデックスとして保管することと、を前記システムに実行させることを特徴とする。
上述の本発明を適用するシステムでは、スパニングされたファイルを更新するにあたり、複数のテープメディアのインデックスを更新することなく、かつ、１つのテープメディアから最新のインデックスを取得することが可能である。
以下において、テープライブラリ・システムに１つのファイルの複数の部分のデータの書込み、読み出し、及び編集の場合について本発明の実施の形態（実施例）を説明する。
本発明の内容は、新たな要素をＬＴＦＳのＩＰのインデックスに含ませることである。ＬＴＦＳでスパニングをサポートするにあたり、インデックスにおいてファイル毎に次の情報を保持する。
（１）ファイルのＩＤ、例えばＵＵＩＤ(Universally UniqueIdentifier)：
テープメディアは内部に保管する複数のファイルをＩＤで管理する。複数のテープメディアに跨ってスパニングされる１つのファイルを指示にするＩＤを新たに設ける。
（２）直前および直後のテープメディアのＩＤ(例えばバーコードラベル)：
テープメディアはインデックスに自己のテープメディアＩＤを保管する。他のテープメディアとの関連すけのためにその他のメディアのＩＤを保管する。他のメディアとはファイルの部分を順に保管する前後のメディアを指示できるように、自己のメディアに関連して前と後のメディアのＩＤを新たに設ける。
（３）世代情報（generation number）：
この世代情報は、１つのファイルを変更した回数を示す指標（thenumber of changing index for the file）を意味する。１つのファイルの複数の部分を後続のメディアに保管し続ける毎に、各メディアに保管される値を前方の値に１つインクリメントされて保管される。また、アプリケーション３０（図５）から特定のファイル部分にいて変更要求がある場合に、すべてのスパニングされたメディアが保管する全ての世代情報を確保する。全ての世代情報のうち最大値のものに、１つインクリメントして変更ファイル部分を含むメディアの世代情報として保管する。システムが世代情報を参照することにより、スパニングされたファイルを作成/更新するにあたり、全てのテープメディアのインデックスを更新することなく、ＬＴＦＳ はテープメディアから最新の情報を取得することが可能となる。具体的の世代情報の利用は、テープメディアからインデックスを読み出す場合は、テープライブラリ内の全てのテープメディアのインデックスを収集し、ファイル毎に持つ世代情報が一番高い情報をそれぞれ採用することにより、ファイルサイズやタイムスタンプの情報を得ることができる。また、そこに登録された直前/直後のテープメディアのＩＤを辿ることにより、各テープメディアに分割して格納されたファイルの断片がそれぞれどのテープメディア上のどこに保管されているかということを知ることができる。例えば、アプリケーションは、ファイルの先頭部分があるメディアを含むパスを指定してファイルをＯｐｅｎしにくるタイミングで先頭のメディアから後続のメディアへと順次に辿って、各メディアのインデックスに含まれる世代情報を確保できる。
本発明の内容は、新たな要素をＬＴＦＳのＩＰのインデックスに含ませることである。ＬＴＦＳでスパニングをサポートするにあたり、インデックスにおいてファイル毎に次の情報を保持する。
（１）ファイルのＩＤ、例えばＵＵＩＤ(Universally UniqueIdentifier)：
テープメディアは内部に保管する複数のファイルをＩＤで管理する。複数のテープメディアに跨ってスパニングされる１つのファイルを指示にするＩＤを新たに設ける。
（２）直前および直後のテープメディアのＩＤ(例えばバーコードラベル)：
テープメディアはインデックスに自己のテープメディアＩＤを保管する。他のテープメディアとの関連すけのためにその他のメディアのＩＤを保管する。他のメディアとはファイルの部分を順に保管する前後のメディアを指示できるように、自己のメディアに関連して前と後のメディアのＩＤを新たに設ける。
（３）世代情報（generation number）：
この世代情報は、１つのファイルを変更した回数を示す指標（thenumber of changing index for the file）を意味する。１つのファイルの複数の部分を後続のメディアに保管し続ける毎に、各メディアに保管される値を前方の値に１つインクリメントされて保管される。また、アプリケーション３０（図５）から特定のファイル部分にいて変更要求がある場合に、すべてのスパニングされたメディアが保管する全ての世代情報を確保する。全ての世代情報のうち最大値のものに、１つインクリメントして変更ファイル部分を含むメディアの世代情報として保管する。システムが世代情報を参照することにより、スパニングされたファイルを作成/更新するにあたり、全てのテープメディアのインデックスを更新することなく、ＬＴＦＳ はテープメディアから最新の情報を取得することが可能となる。具体的の世代情報の利用は、テープメディアからインデックスを読み出す場合は、テープライブラリ内の全てのテープメディアのインデックスを収集し、ファイル毎に持つ世代情報が一番高い情報をそれぞれ採用することにより、ファイルサイズやタイムスタンプの情報を得ることができる。また、そこに登録された直前/直後のテープメディアのＩＤを辿ることにより、各テープメディアに分割して格納されたファイルの断片がそれぞれどのテープメディア上のどこに保管されているかということを知ることができる。例えば、アプリケーションは、ファイルの先頭部分があるメディアを含むパスを指定してファイルをＯｐｅｎしにくるタイミングで先頭のメディアから後続のメディアへと順次に辿って、各メディアのインデックスに含まれる世代情報を確保できる。
図１は、従来のＬＴＦＳによる１つのファイルを複数のメディアに分割して保管、即ちスパニングする典型的な態様を示す。図は、１つのドライブに対して複数のメディアをロード／アンロードする態様を示している。典型的には、ストレージ・システムは１または２以上のテープドライブを含み、複数のメディアが複数のドライブを使用する。ａ，ｂ，ｃメディアの指標を意味するメディアのＩＤであり、テープライブラリなどのストレージ・システムは、このＩＤで目的のメディアを特定する。スパニングのために1つのドライブで使用可能で、他のドライブは他の用途に使用されている場合を想定する。１つのドライブに最初のメディアａをロード（マウント）し、ファイルの先頭（最初のファイル部分）を書込む。このドライブはメディアａについて、インデックスとしてそのファイルのメタデータを保管する。次にメディアａをアンロード（アンマウント）して。同じドライブに次のメディアｂをロードし、ファイルの次のファイル部分を書込む。このドライブはメディアｂについて、インデックスとしてそのファイルのメタデータを保管する。次にメディアｂをアンロードし、同じドライブに次のメディアｃをロードし、ファイルの次のファイル部分を書込む。このドライブはメディアｃについて、インデックスとしてそのファイルのメタデータを保管する。ここで、１つのファイルのスパニングが完了したことになる。従来のＬＴＦＳでは、複数メディアを書き込む場合に、書き始めの段階の複数メディアに書き込む場合あるとは想定できないので、各メディアは各ファイル部分を独立に保管することになる。１つのファイルの部分が保管されたメディアのＩＤはホストのアプリケーションが管理するのみである。メディアはインデックスとして自己のメディアＩＤとファイル部分のＩＤを保管する、他のファイル部分を保管したメディアと関連付けされていない。
図２は、１つのファイル1を複数メディアにスパニングする場合、各メディアのメタデータをインデックス・パーティションに登録の方法を示す。
態様は、１つのファイルが例えば３つのファイル部分に分割され、３つのメディアに書き込まれる場合を示す。図２（ａ）は、１つのファイルを複数のメディアに渡って書込むスパニングの従来の方法を示す。各メディアは自己のメディアのＩＤ（ａ，ｂ，ｃ）とファイル部分（部分１，部分２，部分３）のＩＤ（ｂ１，ｂ２，ｂ３）をインデックスとして、ＩＰに登録する。従来のＬＴＦＳでは、自己のメディアのＩＤおよび保管されるファイルを自己のメディア内でＩＤを割り当てるのみである。
態様は、１つのファイルが例えば３つのファイル部分に分割され、３つのメディアに書き込まれる場合を示す。図２（ａ）は、１つのファイルを複数のメディアに渡って書込むスパニングの従来の方法を示す。各メディアは自己のメディアのＩＤ（ａ，ｂ，ｃ）とファイル部分（部分１，部分２，部分３）のＩＤ（ｂ１，ｂ２，ｂ３）をインデックスとして、ＩＰに登録する。従来のＬＴＦＳでは、自己のメディアのＩＤおよび保管されるファイルを自己のメディア内でＩＤを割り当てるのみである。
図２（ｂ）は、１つのファイルを複数のメディアに渡って書込むスパニングの本発明の方法を示す。
ファイルの書き込み時においては、（１）自己のメディアＩＤの他に前後のメディアＩＤ、（２）ファイルのＩＤ（ＵＵＩＤ）、（３）世代情報（変更回数指標を意味する）をインデックスに設けている。前提として、ホストのアプリケーショ全てのメディアａ．ｂ．ｃを順次ロードして全てのインデックスから、ファイル部分１，２，３のメタデータをホスト３００またはシステム１００のメモリ上にマップする。典型的には、アプリケーションが、ファイルの先頭部分を含むパスを指定してファイルをＯｐｅｎしにくるタイミングでａから順にｂ，ｃと後続のメディア辿って、各メディアのインデックスを確保できる。
（１）他のメディアのＩＤの保管。
例えばメディアｂは自己のメディアＩＤ（ｂ）の他に自分が保管するファイルの部分２の前の部分１を保管するメディアのＩＤ（ａ）、後続の部分３を保管するメディアのＩＤ（ｃ）を保管する。
（２）アプリケーションが管理する１つのファイル（Ｆ１）をテープライブラリで１つのＩＤとして登録する。複数のメディアに１つのファイルの部分が保管されていることを示す。ファイルの部分１，部分２、部分３を各メディアが自己のメディア内で管理するＩＤとは区別する。
（３）世代情報（generationnumber）。
メディアａ、ｂ、ｃに部分が保管するメディアが増える毎に１つ増加させる値を割当ている。メディアａへの部分１の世代を１として、順次更新するメディアｂ、ｃと増える毎に、２、３と大きな値を設ける。また、メディアｂが保管する部分２を変更する書込みを行った場合、１つのファイル(Ｆ１)において全ての部分（部分１，２，３）その世代情報の内一番大きな全体で大きな値（メディアｃの３）を確保し、その値より１大きな値を世代情報としてメディアｂのインデックスとし保管する。
ファイルの書き込み時においては、（１）自己のメディアＩＤの他に前後のメディアＩＤ、（２）ファイルのＩＤ（ＵＵＩＤ）、（３）世代情報（変更回数指標を意味する）をインデックスに設けている。前提として、ホストのアプリケーショ全てのメディアａ．ｂ．ｃを順次ロードして全てのインデックスから、ファイル部分１，２，３のメタデータをホスト３００またはシステム１００のメモリ上にマップする。典型的には、アプリケーションが、ファイルの先頭部分を含むパスを指定してファイルをＯｐｅｎしにくるタイミングでａから順にｂ，ｃと後続のメディア辿って、各メディアのインデックスを確保できる。
（１）他のメディアのＩＤの保管。
例えばメディアｂは自己のメディアＩＤ（ｂ）の他に自分が保管するファイルの部分２の前の部分１を保管するメディアのＩＤ（ａ）、後続の部分３を保管するメディアのＩＤ（ｃ）を保管する。
（２）アプリケーションが管理する１つのファイル（Ｆ１）をテープライブラリで１つのＩＤとして登録する。複数のメディアに１つのファイルの部分が保管されていることを示す。ファイルの部分１，部分２、部分３を各メディアが自己のメディア内で管理するＩＤとは区別する。
（３）世代情報（generationnumber）。
メディアａ、ｂ、ｃに部分が保管するメディアが増える毎に１つ増加させる値を割当ている。メディアａへの部分１の世代を１として、順次更新するメディアｂ、ｃと増える毎に、２、３と大きな値を設ける。また、メディアｂが保管する部分２を変更する書込みを行った場合、１つのファイル(Ｆ１)において全ての部分（部分１，２，３）その世代情報の内一番大きな全体で大きな値（メディアｃの３）を確保し、その値より１大きな値を世代情報としてメディアｂのインデックスとし保管する。
図３は、ＬＴＦＳフォーマットでのメディアのインデックス・パーティションとデータ・パーティションの内容を示す。
ＬＴＦＳでは、テープメディア上のファイルを読み書きするにあたり、事前にテープメディアをＬＴＦＳ フォーマットで初期化する必要がある。テープメディアをＬＴＦＳで利用する場合、テープメディアをインデックス・パーティション（ＩＰ：Index Partition ）およびデータ・パーティション（ＤＰ：Data Partition）と呼ばれる２つのパーティションに分割して利用する。ユーザがＬＴＦＳを利用してテープメディアに書き込むと、テープメディアではファイル本体の他、インデックス・ファイル（単に「インデックス」とも言う）と呼ばれるメタデータをテープメディアに書き込む。インデックスは、ファイル名やファイル作成日などの情報を持つ。ＩＰには、主に最新のインデックスが書き込まれる。ＤＰには、ファイルの本体、及び、インデックスの履歴が書き込まれる。
ＬＴＦＳでは、テープメディア上のファイルを読み書きするにあたり、事前にテープメディアをＬＴＦＳ フォーマットで初期化する必要がある。テープメディアをＬＴＦＳで利用する場合、テープメディアをインデックス・パーティション（ＩＰ：Index Partition ）およびデータ・パーティション（ＤＰ：Data Partition）と呼ばれる２つのパーティションに分割して利用する。ユーザがＬＴＦＳを利用してテープメディアに書き込むと、テープメディアではファイル本体の他、インデックス・ファイル（単に「インデックス」とも言う）と呼ばれるメタデータをテープメディアに書き込む。インデックスは、ファイル名やファイル作成日などの情報を持つ。ＩＰには、主に最新のインデックスが書き込まれる。ＤＰには、ファイルの本体、及び、インデックスの履歴が書き込まれる。
１本のテープカートリッジのメディアがインデックス・パーティションとデータ・パーティションに区分されていることを示す。この図は、ＬＴＯ５に準拠したメディアの構成例を示す。テープの先頭部（ＢＯＴ：Beginning of Tape）から終端部（ＥＯＴ：End of tape）に渡ってＩＰとＤＰとの２つに区分される例を示す。メディアは、データを記録するトラックに沿って、先頭部のインデックス・パーティションと、テープ記憶域の大部分を占めるデータ・パーティションとに区分される。様々な仕様に応じてパーティション数は３以上の任意の数に変更することも可能である。
図３の（Ａ）は、ＬＴＦＳフォーマットで初期化した直後のテープメディアに書き込まれる情報を示す。
テープメディアを ＬＴＦＳ フォーマットで初期化した直後には、テープメディアには図３（Ａ）に示す情報が書き込まれる。
・ＦＩＤ(Format Identification Data set)は、テープドライブがテープメディアを初期化する際、テープメディアの先頭に書き込まれる特殊なデータであり、テープメディア上のパーティションの数や各パーティションの容量などの情報を持つ。
・ＶＯＬ１Ｌａｂｅｌは、ANSI Label とも呼ばれるもので、文字通り ANSI で規定された一般的なフォーマットのラベルである。
・ＬＴＦＳＬａｂｅｌは、ＬＴＦＳ フォーマットで規定されたラベルで、このテープメディアがＬＴＦＳフォーマットのどのバージョンに準拠してフォーマットされたかといった情報を保持するラベルである。ここでメディアに記録されるレコードのサイズを指示する。ファイルの終端がレコード・サイズ（例えば、５１２ＫＢ）に満たない場合でもレコードサイズを確保する。
・ＦＭ(Filemark)とは、テープメディアで一般的に利用される、いわば本のしおりのようなものであり、データの頭出し(seek)を行う際に利用される。Index #0とは、フォーマット時に書き込まれるインデックスであり、この段階ではファイル自体は一つも存在しないためファイル固有の情報は持たないもののテープメディアのボリューム名などの情報を保持するため書き込まれる。
テープメディアを ＬＴＦＳ フォーマットで初期化した直後には、テープメディアには図３（Ａ）に示す情報が書き込まれる。
・ＦＩＤ(Format Identification Data set)は、テープドライブがテープメディアを初期化する際、テープメディアの先頭に書き込まれる特殊なデータであり、テープメディア上のパーティションの数や各パーティションの容量などの情報を持つ。
・ＶＯＬ１Ｌａｂｅｌは、ANSI Label とも呼ばれるもので、文字通り ANSI で規定された一般的なフォーマットのラベルである。
・ＬＴＦＳＬａｂｅｌは、ＬＴＦＳ フォーマットで規定されたラベルで、このテープメディアがＬＴＦＳフォーマットのどのバージョンに準拠してフォーマットされたかといった情報を保持するラベルである。ここでメディアに記録されるレコードのサイズを指示する。ファイルの終端がレコード・サイズ（例えば、５１２ＫＢ）に満たない場合でもレコードサイズを確保する。
・ＦＭ(Filemark)とは、テープメディアで一般的に利用される、いわば本のしおりのようなものであり、データの頭出し(seek)を行う際に利用される。Index #0とは、フォーマット時に書き込まれるインデックスであり、この段階ではファイル自体は一つも存在しないためファイル固有の情報は持たないもののテープメディアのボリューム名などの情報を保持するため書き込まれる。
図３の（Ｂ）ＬＴＦＳフォーマットで初期化した後にファイルを書き込んだ場合にテープメディアに書き込まれる情報を示す。
ＬＴＦＳフォーマットで初期化後、ファイル（File1）を書き込むと、テープメディア上に書き込まれたデータは（Ｂ）のようになる。太線で囲まれた部分が追加/更新されたデータである。Index#1はＦｉｌｅ１の情報を持つ。ＩＰは最新のインデックスのみ保持する一方、ＤＰはインデックスの履歴を保持する。インデックスを更新するタイミングはファイルシステムの実装にまかされており、例えば一定時間毎に更新したり、テープドライブからテープメディアを取り出す時のみ更新したりしている。更に使い続ける場合も、ＩＰに置かれるインデックスは常に最新のインデックスのみが置かれ、ＤＰは既存のインデックスを上書きすることなく、ファイルおよびインデックスを追記していく。
ＬＴＦＳフォーマットで初期化後、ファイル（File1）を書き込むと、テープメディア上に書き込まれたデータは（Ｂ）のようになる。太線で囲まれた部分が追加/更新されたデータである。Index#1はＦｉｌｅ１の情報を持つ。ＩＰは最新のインデックスのみ保持する一方、ＤＰはインデックスの履歴を保持する。インデックスを更新するタイミングはファイルシステムの実装にまかされており、例えば一定時間毎に更新したり、テープドライブからテープメディアを取り出す時のみ更新したりしている。更に使い続ける場合も、ＩＰに置かれるインデックスは常に最新のインデックスのみが置かれ、ＤＰは既存のインデックスを上書きすることなく、ファイルおよびインデックスを追記していく。
図３の（Ｃ）は、（Ｂ）の状態の後、更にファイル（Ｆｉｌｅ2）を書き込んだ場合のテープメディアに書き込まれる情報を示す。
ディレクトリをテープメディアに書き込んだ後、他のファイルないしディレクトリをテープメディア上に書き込んだ後で、最初に書き込んだディレクトリにファイルを追加すると、に格納されるＦｉｌｅ１,Ｆｉｌｅ２が連続してテープメディアに保管される。
ディレクトリをテープメディアに書き込んだ後、他のファイルないしディレクトリをテープメディア上に書き込んだ後で、最初に書き込んだディレクトリにファイルを追加すると、に格納されるＦｉｌｅ１,Ｆｉｌｅ２が連続してテープメディアに保管される。
図４は、従来のＬＴＦＳフォーマットにより２つのカートリッジ・メディアのＩＰのインデックス（メタデータ）を示す。
従来のＬＴＦＳフォーマットでは、ＩＤがzzzz（file-id=zzzz）のファイルをスパニングした場合のインデックスとファイル本体の配置になっている。これは、インデックスが保管されるテープメディア上に記録されたファイル本体の情報を格納するというＬＴＦＳフォーマットの方針に則ったものである。ＩＰのインデックス（Index）として、メディアのＩＤ（media-id：ＵＵＩＤである）、メディアのファイルＩＤ（file-id）、パスおよびファイル名（path、name）、ファイルのオフセット位置（offset）、ファイルのサイズ（length）、タイムスタンプ（timestamp）、メディアに含まれる他のファイルのＩＤ（file-id: otherfiles）などが含まれる。本発明では、更に、上で説明した他のメディアのＩＤ、アプリケーションが管理する１つのファイル（Ｆ１）のＩＤ、世代情報（generation number）をインデックスに登録する。この要素の登録により、１つのファイルのスパニングの管理が、ホスト側での管理に支障がある場合にメディアのインデックスから容易に可能である。また、ＤＰ内にファイル内容を、そのインデックスを伴って保管される。
従来のＬＴＦＳフォーマットでは、ＩＤがzzzz（file-id=zzzz）のファイルをスパニングした場合のインデックスとファイル本体の配置になっている。これは、インデックスが保管されるテープメディア上に記録されたファイル本体の情報を格納するというＬＴＦＳフォーマットの方針に則ったものである。ＩＰのインデックス（Index）として、メディアのＩＤ（media-id：ＵＵＩＤである）、メディアのファイルＩＤ（file-id）、パスおよびファイル名（path、name）、ファイルのオフセット位置（offset）、ファイルのサイズ（length）、タイムスタンプ（timestamp）、メディアに含まれる他のファイルのＩＤ（file-id: otherfiles）などが含まれる。本発明では、更に、上で説明した他のメディアのＩＤ、アプリケーションが管理する１つのファイル（Ｆ１）のＩＤ、世代情報（generation number）をインデックスに登録する。この要素の登録により、１つのファイルのスパニングの管理が、ホスト側での管理に支障がある場合にメディアのインデックスから容易に可能である。また、ＤＰ内にファイル内容を、そのインデックスを伴って保管される。
図５は、本発明が適用される、複数のテープドライブを含むテープライブラリ・システムの構成例を示す。
ストレージ・システム１００は、３つのテープドライブ６０、テープカートリッジ（メディア）４０、そのテープカートリッジを収納するスロット４５を含む。ストレージ・システム内にはスロット４５に収納された多数のテープカートリッジ４０が存在する。
ストレージ・システム１００は、３つのテープドライブ６０、テープカートリッジ（メディア）４０、そのテープカートリッジを収納するスロット４５を含む。ストレージ・システム内にはスロット４５に収納された多数のテープカートリッジ４０が存在する。
ライブラリ・マネージャ５０は、ホスト３００とストレージ・システム１００との間にあって、複数のドライブ６０及び複数のテープカートリッジ４０を集中管理する。ライブラリ・マネージャは、複数のカートリッジ４０及びドライブ６０を仮想化し、読み書き制御を行う。ライブラリ・マネージャ５０の一例としては、ＩＢＭ社のTape System Library Manager(TSLM)である。ホスト３００のアプリケーション３０は、ライブラリ・マネージャ５０を介して、ストレージ・システム１００にファイルの読み書き要求を行う。ストレージ・システム１００は、アプリケーション３０が発行する各種コマンド（読み書き、位置決めなど）により制御される。ライブラリ・マネージャ５０は、アプリケーションからのコマンドを一時保管し、コマンドに対応したＳＣＳＩコマンドなどをストレージ・システム１００に向けて出力する。専用のソフトウェアとしてのアプリケーションの一例としては、ＩＢＭ社のTivoli Storage Manager が該当する。
ライブラリ・マネージャ５０は、アプリケーションからコマンドとして、ロード要求するコマンドを受け取る。通常はこのコマンドが実行される場合、ライブラリ・マネージャ５０は空ドライブを複数（３つ）のドライブから検索する。ロード要求されたテープカートリッジをロード可能な空ドライブに搭載する。３つのドライブが使用中である場合は空きドライブが発生するまで、ライブラリ・マネージャは待たされる。また、テープライブラリ・システムは、ＨＤＤ等と同様にファイルシステム上でも利用可能である。例えばＬＴＦＳでは、メディア上に書かれたデータをファイルとして見せることができる。
テ−プドライブ（ドライブ）６０について説明する。
テ−プドライブ６０、ホスト３００から送られた複数のデータを固定長のデータセット（ＤａｔａＳｅｔ；ＤＳと言う。）単位でテ−プ記録媒体への書込み読込を行う。ＤＳの典型的な大きさは４ＭＢである。ホスト３００のアプリケーション３０は、１２８ＫＢのブロック単位でファイルシステムを介してテープドライブに書込み／読み出し要求を送る。通信規格としてＳＣＳＩを用いる場合、アプリケーション３０は、書き込み／読取りデータのための要求（Ｗｒｉｔｅ／Ｒｅａｄ）をテープドライブ６０に発行する。なお、テープドライブは、複数のブロックから構築されたＤＳを単位でデータの読み書きを行う。
テ−プドライブ６０、ホスト３００から送られた複数のデータを固定長のデータセット（ＤａｔａＳｅｔ；ＤＳと言う。）単位でテ−プ記録媒体への書込み読込を行う。ＤＳの典型的な大きさは４ＭＢである。ホスト３００のアプリケーション３０は、１２８ＫＢのブロック単位でファイルシステムを介してテープドライブに書込み／読み出し要求を送る。通信規格としてＳＣＳＩを用いる場合、アプリケーション３０は、書き込み／読取りデータのための要求（Ｗｒｉｔｅ／Ｒｅａｄ）をテープドライブ６０に発行する。なお、テープドライブは、複数のブロックから構築されたＤＳを単位でデータの読み書きを行う。
テ−プドライブ６０は、ホスト３００から受取ったコマンドに従って、データのテ−プへの書込みやテ−プからの読出しをする。テ−プドライブ６０は、バッファ、読み書きチャネル、ヘッド、モ−タ、テ−プメディア（メディア、テープカートリッジ）を巻きつけるリ−ルと、読み書き制御と、ヘッド位置制御システムと、モ−タドライバとを含む。テ−プドライブは、テープカートリッジを着脱可能に搭載する。テ−プは、リ−ルの回転に伴い、長手方向に移動する。ヘッドは、テ−プが長手方向に移動してテ−プに対してデータを書き込んだり、テ−プからデータを読出したりする。また、テープカートリッジ４０はカートリッジメモリ（ＣＭ：Cartridge Memory）と呼ばれる非接触不揮発性メモリを備える。テープカートリッジ４０に搭載されたＣＭは、テープドライブ６０により非接触的に読み書きされる。ＣＭはカートリッジ属性を保管する。テープドライブは、読出し及び書込み時に、ＣＭからカートリッジ属性を取り出して最適な読み書きができるようにする。
図６は、本発明の拡張されたＬＴＦＳフォーマットにおけるインデックス更新時のフローチャートを示す。以下の処理を、新たなファイルシステム、例えばＬＴＦＳに実装する。
前提として、ホストのアプリケーション３０（図５）全てのメディアａ，ｂ，ｃを順次ロードして全てのインデックスからファイル部分１，２，３，のメタデータ（インデックス）をホスト３００またはシステム１００のメモリ上にマップする。典型的には、アプリケーションが、ファイルの先頭があるａを含むパスを指定してファイルをＯｐｅｎしにくるタイミングでａから順にｂ，ｃと後続のメディアを辿って、各メディアのインデックスを確保できる。
●（７００）：インデックス更新要求を受取る。
図２（ｂ）において、１つのファイル（Ｆ１）の特定の部分（例えばｂ）を変更するとメディアｂのＤＰにその変更データが保管される。この変更に伴い、メディアｂのインデックスのコピーはシステムのメモリまたはハードディスク上では変更されている。例えば、ファイルの変更回数（世代情報）は現在の最大値３（部分３の世代情報）に１つインクリメントして４としてインデックスは更新されている。しかしながら、メディアｂのＩＰにはこの更新されたインデックスのコピーは登録されていない状態である。システムは、データ内容のメディアｂのＤＰへの更新はされているが、そのデータ内容を反映したコピーをメディアｂのＩＰへ登録が遅れる。システム１００は時間的遅延をできるだけ短くするために所定時間、例えば５分毎に最新のインデックスを登録している。なお、最新のインデックスは、メディアのドライブからのアンマウント時にもＩＰに登録される。
●（７１０）：任意のテープ・メディア上のインデックスにメモリ上の更新されたコピーの内容が登録済みを確認する。
システムのメモリ上の更新されたコピーがドライブにロードされたメディアのインデックスに登録済みの場合（Ｙｅｓ）はステップ７３０の処理となる。更新されたコピーが対象のメディアのインデックスとして登録されていない場合はステップ７２０の処理となる。
●（７２０）：例として図２（ｂ）を参照すると、１つのファイルの複数の部分ｂ１，ｂ２，ｂ３を順にメディアａ，ｂ，ｃにスパニングされる態様を想定する。
・アプリケーション３０（図５）が管理するファイルを一意に指標可能にするためにＩＤ（Ｆ１：ＵＵＩＤである）を、全てのメディアのインデックスのコピーに割り当てる。
・最初のメディアａについて、ファイル（Ｆ１）の最初の部分１の保管について世代情報を１とする。
・直前直後のテープ・メディアのＩＤは無視する。ファイル（Ｆ１）の最初の部分１（ｂ１）の保管開始時点ではメディアａの容量を超える、後続の部分１（ｂ２）、部分２（ｂ３）のデータが来るか定かでない。従って部分ａの保管し始めの段階では想定される直後のメディアｂのＩＤ（ｂ）（ステップ７４０）を想定されない。ただし、メディアａは世代情報１を割り当てられる。
最後は、他のインデックスの処理７７０に移動する。
●（７３０）：ファイル本体を、書き込み中のテープ・メディア上のインデックスに登録済みか確認する。
ファイルの変更の内容がメディアに保管され、その変更内容を反映したインデックスのコピーが、一連の複数のメディアのＩＰに登録されている場合（Ｙｅｓ）はステップ７５０の処理となる。変更されたインデックスのコピーがメディアに登録されていない（Ｎｏ）場合はステップ７４０の処理となる。
メディアｂに部分２に関するインデックスを最初に登録する際には、メディアaの部分１のインデックスに部分２がメディアｂに存在することを登録する必要がある。５分毎のインデックスの更新・登録において、メディアｂにすでに部分２に関する情報が存在する場合には、メディアａの部分１のインデックスに部分２がメディアｂに存在することを登録することをスキップできる。
●（７４０）：図２（ｂ）が示すように、ファイル（Ｆ１）の３つの部分、部分１（ｂ１），部分２（ｂ２），部分３（ｂ３）を３つのメディアにスパニングする過程を考える。
・ファイルＩＤに対応する世代情報が最も高いテープ・メディアを探す。
最初の部分１（ｂ１）をメディアａに保管する場合の世代情報は、ステップ７２０で割り当てられた最大値１である。最大値の世代情報を有するメディアａのインデックスが最新のファイルの更新インデックスを有する。
・当該メディアのインデックスに、 直後のテープ・メディアＩＤとしてファイル本体を書き込み中のテープ・メディアのＩＤを登録する。メディアａに対して、後続の部分２を保管する予定の直後のメディアｂのＩＤ（ｂ）を登録する。メディアｂは、部分２（ｂ２）が保管されるとメディアａの世代情報（１）に対して１つインクリメントされた世代情報（２）を登録する。
最後はステップ７６０の処理となる。
●（７５０）：ファイルＩＤに対応する世代情報を既に利用した最大値よりも１つだけ大きな値とする。
ファイル（Ｆ１）の変更（データの追記、データの一部削除、ファイル名の変更など）が複数の部分１，２，３のどれかが対象である。図２（ｂ）に示すスパニング状態においてメディアｃの世代情報が最大値（３）である。例えば、変更対象が部分２（ｂ２）である場合にメディアｂに保管されている。その変更内容を反映したインデックスのコピーがメディアｂのＩＰに登録されている場合は、メディアｃが保管する世代情報の値に１つインクリメントした値（４）をメディアｂの世代情報として与える。
最後は、他のインデックスの処理７７０に移動する。
●（７６０）
・ファイル本体を書き込み中のテープ・メディアのインデックスに、直前のテープ・メディアのＩＤとしてファイルＩＤに対応する世代情報が最も高いインデックスを持つテープ・メディアのＩＤを登録する。
・当該メディアのインデックスにファイルＩＤに対応する世代情報を既に利用した最大値よりも1つだけ大きな値として、登録する。
メディアｂは、世代情報が最大の部分１（ｂ１）が保管した直前のメディアａのＩＤ（ａ）を登録する。メディアｂは、部分２（ｂ２）が保管されるとメディアａの最大の世代情報（１）に対して１つインクリメントされ、最大の世代情報（２）を有する。更に後続の部分３（ｂ３）はメディアｃに保管され、その世代情報はメディアｂの世代情報（２）に１つインクリメントした世代情報（３）となる。メディアｂは、直後の部分３が保管される予定のメディアＩＤ（ｃ）も保持する（ステップ７３０）。最大値の世代情報（２）を有するメディアｂは、後続の部分３（ｂ３）が保管される予定のメディアｃのＩＤ（ｃ）を登録する。最終的に、メディアｃが、メディアｂの世代情報（２）に１つインクリメントした最大の世代情報（３）を有する。
最後は、他のインデックスの処理７７０に移動する。
●（７７０）：その他のインデックス情報を従来通り更新する。
本発明が設ける新たなインデックスの３つの要素は、従来のインデックスの要素（図４参照）、例えば、自己のメディアＩＤ、メディア内でのfile-id、タイムスタンプ、ファイル・サイズなどにと共にインデックスに含まれる。
●（７８０）：従来の要素と本発明の３要素を含むインデックス更新が終了する。
テープライブラリ・システムまたはドライブのメモリ上において更新されたインデックスをドライブにマウントされているメディアのＩＰのインデックスを書き換える。テープライブラリ・システムは、ファイル部分自体の変更と共に、１つのメディアのインデックスに含まれるタイムスタンプ、１つのファイルのサイズを世代情報が最大のもので特定できる。
前提として、ホストのアプリケーション３０（図５）全てのメディアａ，ｂ，ｃを順次ロードして全てのインデックスからファイル部分１，２，３，のメタデータ（インデックス）をホスト３００またはシステム１００のメモリ上にマップする。典型的には、アプリケーションが、ファイルの先頭があるａを含むパスを指定してファイルをＯｐｅｎしにくるタイミングでａから順にｂ，ｃと後続のメディアを辿って、各メディアのインデックスを確保できる。
●（７００）：インデックス更新要求を受取る。
図２（ｂ）において、１つのファイル（Ｆ１）の特定の部分（例えばｂ）を変更するとメディアｂのＤＰにその変更データが保管される。この変更に伴い、メディアｂのインデックスのコピーはシステムのメモリまたはハードディスク上では変更されている。例えば、ファイルの変更回数（世代情報）は現在の最大値３（部分３の世代情報）に１つインクリメントして４としてインデックスは更新されている。しかしながら、メディアｂのＩＰにはこの更新されたインデックスのコピーは登録されていない状態である。システムは、データ内容のメディアｂのＤＰへの更新はされているが、そのデータ内容を反映したコピーをメディアｂのＩＰへ登録が遅れる。システム１００は時間的遅延をできるだけ短くするために所定時間、例えば５分毎に最新のインデックスを登録している。なお、最新のインデックスは、メディアのドライブからのアンマウント時にもＩＰに登録される。
●（７１０）：任意のテープ・メディア上のインデックスにメモリ上の更新されたコピーの内容が登録済みを確認する。
システムのメモリ上の更新されたコピーがドライブにロードされたメディアのインデックスに登録済みの場合（Ｙｅｓ）はステップ７３０の処理となる。更新されたコピーが対象のメディアのインデックスとして登録されていない場合はステップ７２０の処理となる。
●（７２０）：例として図２（ｂ）を参照すると、１つのファイルの複数の部分ｂ１，ｂ２，ｂ３を順にメディアａ，ｂ，ｃにスパニングされる態様を想定する。
・アプリケーション３０（図５）が管理するファイルを一意に指標可能にするためにＩＤ（Ｆ１：ＵＵＩＤである）を、全てのメディアのインデックスのコピーに割り当てる。
・最初のメディアａについて、ファイル（Ｆ１）の最初の部分１の保管について世代情報を１とする。
・直前直後のテープ・メディアのＩＤは無視する。ファイル（Ｆ１）の最初の部分１（ｂ１）の保管開始時点ではメディアａの容量を超える、後続の部分１（ｂ２）、部分２（ｂ３）のデータが来るか定かでない。従って部分ａの保管し始めの段階では想定される直後のメディアｂのＩＤ（ｂ）（ステップ７４０）を想定されない。ただし、メディアａは世代情報１を割り当てられる。
最後は、他のインデックスの処理７７０に移動する。
●（７３０）：ファイル本体を、書き込み中のテープ・メディア上のインデックスに登録済みか確認する。
ファイルの変更の内容がメディアに保管され、その変更内容を反映したインデックスのコピーが、一連の複数のメディアのＩＰに登録されている場合（Ｙｅｓ）はステップ７５０の処理となる。変更されたインデックスのコピーがメディアに登録されていない（Ｎｏ）場合はステップ７４０の処理となる。
メディアｂに部分２に関するインデックスを最初に登録する際には、メディアaの部分１のインデックスに部分２がメディアｂに存在することを登録する必要がある。５分毎のインデックスの更新・登録において、メディアｂにすでに部分２に関する情報が存在する場合には、メディアａの部分１のインデックスに部分２がメディアｂに存在することを登録することをスキップできる。
●（７４０）：図２（ｂ）が示すように、ファイル（Ｆ１）の３つの部分、部分１（ｂ１），部分２（ｂ２），部分３（ｂ３）を３つのメディアにスパニングする過程を考える。
・ファイルＩＤに対応する世代情報が最も高いテープ・メディアを探す。
最初の部分１（ｂ１）をメディアａに保管する場合の世代情報は、ステップ７２０で割り当てられた最大値１である。最大値の世代情報を有するメディアａのインデックスが最新のファイルの更新インデックスを有する。
・当該メディアのインデックスに、 直後のテープ・メディアＩＤとしてファイル本体を書き込み中のテープ・メディアのＩＤを登録する。メディアａに対して、後続の部分２を保管する予定の直後のメディアｂのＩＤ（ｂ）を登録する。メディアｂは、部分２（ｂ２）が保管されるとメディアａの世代情報（１）に対して１つインクリメントされた世代情報（２）を登録する。
最後はステップ７６０の処理となる。
●（７５０）：ファイルＩＤに対応する世代情報を既に利用した最大値よりも１つだけ大きな値とする。
ファイル（Ｆ１）の変更（データの追記、データの一部削除、ファイル名の変更など）が複数の部分１，２，３のどれかが対象である。図２（ｂ）に示すスパニング状態においてメディアｃの世代情報が最大値（３）である。例えば、変更対象が部分２（ｂ２）である場合にメディアｂに保管されている。その変更内容を反映したインデックスのコピーがメディアｂのＩＰに登録されている場合は、メディアｃが保管する世代情報の値に１つインクリメントした値（４）をメディアｂの世代情報として与える。
最後は、他のインデックスの処理７７０に移動する。
●（７６０）
・ファイル本体を書き込み中のテープ・メディアのインデックスに、直前のテープ・メディアのＩＤとしてファイルＩＤに対応する世代情報が最も高いインデックスを持つテープ・メディアのＩＤを登録する。
・当該メディアのインデックスにファイルＩＤに対応する世代情報を既に利用した最大値よりも1つだけ大きな値として、登録する。
メディアｂは、世代情報が最大の部分１（ｂ１）が保管した直前のメディアａのＩＤ（ａ）を登録する。メディアｂは、部分２（ｂ２）が保管されるとメディアａの最大の世代情報（１）に対して１つインクリメントされ、最大の世代情報（２）を有する。更に後続の部分３（ｂ３）はメディアｃに保管され、その世代情報はメディアｂの世代情報（２）に１つインクリメントした世代情報（３）となる。メディアｂは、直後の部分３が保管される予定のメディアＩＤ（ｃ）も保持する（ステップ７３０）。最大値の世代情報（２）を有するメディアｂは、後続の部分３（ｂ３）が保管される予定のメディアｃのＩＤ（ｃ）を登録する。最終的に、メディアｃが、メディアｂの世代情報（２）に１つインクリメントした最大の世代情報（３）を有する。
最後は、他のインデックスの処理７７０に移動する。
●（７７０）：その他のインデックス情報を従来通り更新する。
本発明が設ける新たなインデックスの３つの要素は、従来のインデックスの要素（図４参照）、例えば、自己のメディアＩＤ、メディア内でのfile-id、タイムスタンプ、ファイル・サイズなどにと共にインデックスに含まれる。
●（７８０）：従来の要素と本発明の３要素を含むインデックス更新が終了する。
テープライブラリ・システムまたはドライブのメモリ上において更新されたインデックスをドライブにマウントされているメディアのＩＰのインデックスを書き換える。テープライブラリ・システムは、ファイル部分自体の変更と共に、１つのメディアのインデックスに含まれるタイムスタンプ、１つのファイルのサイズを世代情報が最大のもので特定できる。
将来には、インデックスの情報は ＬＴＦＳ がメモリないしハードディスク上に保管/管理するため、通常テープメディアからインデックスを読み出す必要はない。例えばメモリやハードディスクのトラブルなどにより、ＬＴＦＳがメモリなど上に保持したインデックスのコピーが失われて、テープメディアからインデックスを読み出す場合に追加要素を確保することは有効である。テープライブラリ内の全てのテープメディアのインデックスを収集し、ファイル毎に持つ世代情報が一番高い情報をそれぞれ採用することにより、ファイルサイズやタイムスタンプの情報を得ることができる。また、そこに登録された直前/直後のテープメディアのＩＤを辿ることにより、各テープメディアに分割して格納されたファイルの断片がそれぞれどのテープメディア上のどこに保管されているかということを知ることができる。
以上より、本発明のスパニング方法は、スパニングされたファイルを作成/更新するにあたり、複数のテープメディアのインデックスを更新することなく、ＬＴＦＳはテープメディアから最新の情報を取得することが可能である。また、本発明の方法は、上記書込みにより発生するアンロード/ロードにかかる時間を短縮し、インデックス更新のパフォーマンスを向上させる。なお、本発明を実施の形態（実施例）を用いて説明したが、本発明の範囲は上記実施例には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。
４０ テープカートリッジ、
４５ スロット、
６０ テープドライブ、
１００ テープライブラリ・システム（ストレージ・システム）、
３００ ホスト（サーバ）
４５ スロット、
６０ テープドライブ、
１００ テープライブラリ・システム（ストレージ・システム）、
３００ ホスト（サーバ）
Claims (8)
- 少なくとも１つのテープドライブを含むテープストレージ・システムにおいて１つのファイルを複数のテープメディアにスパニングする方法であって、
前記システムが、前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管することと、
前記システムが、１つのファイルを分割してシーケンシャルにファイルの部分（ファイル部分）を保管する複数の前記各メディアを指示するＩＤの少なくとも１つを前記ファイルに関連付けてインデックスに保持することと、
前記システムが、複数の前記ファイル部分を後続のメディアに保管し続ける毎に、各メディアに保管される値を前方の値に１つインクリメントされて保管される回数を世代情報と定義し前記各メディアに前記インデックスとして保管することと、
前記システムが、更に特定の前記ファイル部分について変更要求がある場合に、全ての前記メディアの前記世代情報のうち最大値に、１つインクリメントした値を変更ファイル部分を保管する前記特定のメディアの前記世代情報として前記特定のメディアに保管することと、
前記システムは、分割保管された前記ファイルの読み出し要求を受けた場合、前記ファイルに関連する全てのメディアのインデックスを収集しファイル部分毎に保持する前記世代情報の値が最大値を有する当該ファイル部分に関するインデックスにより前記ファイルのメタデータを読み出すことと、を含むスパニングする方法。 - 前記所定のフォーマットは、
前記メディアは、ストレージ・システムのシーケンシャルアクセスのためのファイルシステムにより読み書きを可能にするために、2以上のパーティションに区分され、
前記パーティションは、ファイルのインデックスを保管するインデック・パーティション（ＩＰ）とファイルのデータを保管するデータ・パーティション（ＤＰ）とを含む、請求項１に記載のスパニングする方法。 - 前記ファイル部分を保管する前記各メディアに前記ファイルを指示するＩＤを前記インデックスとして保管することと、を含む請求項１に記載のスパニングする方法。
- 前記１つのファイルの部分を保管する前記メディアが第２のファイル部分を保管する場合に、第２のファイル部分に対して前後する第１及び第３の前記ファイル部分を保管する前記メディアを指示するＩＤの少なくとも１つをインデックスとして保管することと、を含む請求項１に記載のスパニングする方法。
- 第１のファイル部分を保管したメディアに、第１のファイル部分に対して直前のファイル部分を保管する前記メディアのＩＤと、第１のファイル部分の直後のファイル部分を保管する前記メディアのＩＤと、前記インデックスとして更に保管することと、を含む請求項４に記載のスパニングする方法。
- 前記ファイルを変更する要求をテープストレージ・システムが受け取った場合、前記システムは更新に該当する特定の前記ファイル部分を保管する前記メディアのＩＤを特定して前記メディアをドライブにマウントすることと、
前記ＩＤのメディアのインデックスを前記システムのメモリにコピーすることと、
特定の前記ファイル部分の変更に基づいて前記メディアの前記ＤＰのデータを変更すること、
前記ＤＰのデータの変更と同時に、特定の前記ファイル部分の変更内容を反映するように前記メモリ上の前記インデックスを変更することと、
前記変更されたメモリ上の前記インデックスに、前記変更時点で特定の前記ファイル部分の前記最大値にインクリメントされた世代情報を含ませることと、
所定の時点で前記メディアのＩＰに前記インデックスを登録すること、を含む請求項２に記載のスパニングする方法。 - 少なくとも１つのテープドライブを含み、１つのファイルを複数のテープメディアにスパニングするためのテープストレージ・システムであって、
前記システムの読み書き制御は、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管することと、
１つのファイルを分割してシーケンシャルにファイルの部分（ファイル部分）を保管する複数の前記各メディアを指示するＩＤの少なくとも１つを前記ファイルに関連付けてインデックスに保持することと、
複数の前記ファイル部分を後続のメディアに保管し続ける毎に、各メディアに保管される値を前方の値に１つインクリメントされて保管される回数を世代情報と定義し前記各メディアに前記インデックスとして保管することと、
更に特定の前記ファイル部分について変更要求がある場合に、全ての前記メディアの前記世代情報のうち最大のものに、１つインクリメントした値を変更ファイル部分を保管する前記特定のメディアの前記世代情報として前記特定のメディアに保管することと、
分割保管された前記ファイルの読み出し要求を受けた場合、前記ファイルに関連する全てのメディアのインデックスを収集しファイル部分毎に保持する前記世代情報の値が最大値を有する当該ファイル部分に関するインデックスにより前記ファイルのメタデータを読み出すことと、を実行するテープストレージ・システム。 - 少なくとも１つのテープドライブを含むテープストレージ・システムにおいて１つのファイルを複数のテープメディアにスパニングするめのプログラムであって、
前記ファイルのインデックス（メタデータ）および前記ファイルのデータをメディアに所定のフォーマットで保管することと、
１つのファイルを分割してシーケンシャルにファイルの部分（ファイル部分）を保管する複数の前記各メディアを指示するＩＤの少なくとも１つを前記ファイルに関連付けてインデックスに保持することと、
複数の前記ファイル部分を後続のメディアに保管し続ける毎に、各メディアに保管される値を前方の値に１つインクリメントされて保管される回数を世代情報と定義し前記各メディアに前記インデックスとして保管することと、
更に特定の前記ファイル部分について変更要求がある場合に、全ての前記メディアの前記世代情報のうち最大のものに、１つインクリメントした値を変更ファイル部分を保管する前記特定のメディアの前記世代情報として前記特定のメディアに保管することと、
分割保管された前記ファイルの読み出し要求を受けた場合、前記ファイルに関連する全てのメディアのインデックスを収集しファイル部分毎に保持する前記世代情報の値が最大値を有する当該ファイル部分に関するインデックスにより前記ファイルのメタデータを読み出すことと、を前記システムに実行させるプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013167682A JP6005010B2 (ja) | 2013-08-12 | 2013-08-12 | 複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム |
| US14/456,316 US9684454B2 (en) | 2013-08-12 | 2014-08-11 | Method, storage system, and program for spanning single file across plurality of tape media |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013167682A JP6005010B2 (ja) | 2013-08-12 | 2013-08-12 | 複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015036851A JP2015036851A (ja) | 2015-02-23 |
| JP6005010B2 true JP6005010B2 (ja) | 2016-10-12 |
Family
ID=52449623
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013167682A Active JP6005010B2 (ja) | 2013-08-12 | 2013-08-12 | 複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US9684454B2 (ja) |
| JP (1) | JP6005010B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6052812B2 (ja) * | 2014-07-11 | 2016-12-27 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | テープ上のファイルの管理、書き込み、及び読み出し方法 |
| JP6005122B2 (ja) * | 2014-11-17 | 2016-10-12 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 複数のテープカートリッジにファイルをスパニングして書込む方法 |
| JP6482264B2 (ja) | 2014-12-11 | 2019-03-13 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 複数のテープカートリッジにファイルをスパニングして書込む方法 |
| US11204891B2 (en) | 2016-11-04 | 2021-12-21 | International Business Machines Corporation | Identifying partial update for tape file system |
| US10572170B2 (en) | 2016-12-05 | 2020-02-25 | International Business Machines Corporation | Writing file information for tape file systems |
| US10152993B1 (en) * | 2017-11-29 | 2018-12-11 | International Business Machines Corporation | Save block data to tape in a reverse order |
| US11238021B2 (en) * | 2018-12-18 | 2022-02-01 | International Business Machines Corporation | Creating a search index within a data storage library |
| US11748020B2 (en) * | 2020-02-28 | 2023-09-05 | Nebuon, Inc. | Reestablishing redundancy in redundant storage |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05342073A (ja) * | 1992-06-11 | 1993-12-24 | Nec Corp | ファイル記憶媒体およびファイル管理システム |
| JPH0969028A (ja) * | 1995-08-31 | 1997-03-11 | Hitachi Ltd | 磁気テープカートリッジ制御方式 |
| JPH10232800A (ja) * | 1997-02-19 | 1998-09-02 | Hitachi Ltd | 磁気テープ記憶装置 |
| JPH11306190A (ja) | 1998-04-21 | 1999-11-05 | Mitsubishi Electric Corp | ビデオサーバシステム |
| US7107395B1 (en) * | 1998-12-31 | 2006-09-12 | Emc Corporation | Apparatus and methods for operating a computer storage system |
| US20020191311A1 (en) * | 2001-01-29 | 2002-12-19 | Ulrich Thomas R. | Dynamically scalable disk array |
| US8793282B2 (en) * | 2009-04-14 | 2014-07-29 | Disney Enterprises, Inc. | Real-time media presentation using metadata clips |
| US8886896B2 (en) * | 2009-10-30 | 2014-11-11 | Adobe Systems Incorporated | Storage format for media streams |
| US9430155B2 (en) * | 2010-03-25 | 2016-08-30 | International Business Machines Corporation | File index, metadata storage, and file system management for magnetic tape |
| US9378218B2 (en) * | 2011-10-24 | 2016-06-28 | Electronics And Telecommunications Research Institute | Apparatus and method for enabling clients to participate in data storage in distributed file system |
| US8665563B2 (en) * | 2012-04-05 | 2014-03-04 | Oracle International Corporation | Magnetic tape partitioning format for use in linear recording of fixed partitions |
-
2013
- 2013-08-12 JP JP2013167682A patent/JP6005010B2/ja active Active
-
2014
- 2014-08-11 US US14/456,316 patent/US9684454B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20150046645A1 (en) | 2015-02-12 |
| JP2015036851A (ja) | 2015-02-23 |
| US9684454B2 (en) | 2017-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6005010B2 (ja) | 複数のテープメディアに１つのファイルをスパニングする方法、ストレージ・システム、およびプログラム | |
| US10346078B2 (en) | Method of writing a file to a plurality of media and a storage system thereof | |
| JP6124734B2 (ja) | 高速に読み出し可能なテープメディアにファイルを書込む方法 | |
| JP6080799B2 (ja) | テープ記録システム用ファイルシステムを介した読み書きする方法 | |
| JP6041839B2 (ja) | メタ情報を保管する方法、プログラム、及びそのテープ記録システム | |
| US9292227B2 (en) | Method for divisionally managing files on a user basis, and a storage system and computer program product thereof | |
| US7864478B2 (en) | Verification of a tape data storage cartridge | |
| US9098210B2 (en) | Automatically linking partitions on a tape media device | |
| US20150095566A1 (en) | Reading Speed of Updated File by Tape Drive File System | |
| US9852756B2 (en) | Method of managing, writing, and reading file on tape | |
| US9916323B2 (en) | Support for worm cartridges realized by linear tape file system (LTFS) | |
| JP2015005229A (ja) | テープカートリッジのファイルを複製する方法、プログラム及びテープドライブ | |
| JP2016091575A (ja) | テープに書き込されたファイルを消去する方法、プログラム、及びテープ装置 | |
| US8856436B2 (en) | Locating host data records on a physical stacked volume | |
| JP6109012B2 (ja) | テープメディアにおいてフォーマットを初期化する前に書き込まれていたデータのリカバリー | |
| US11163500B2 (en) | Caching files in a directory | |
| JP6482264B2 (ja) | 複数のテープカートリッジにファイルをスパニングして書込む方法 | |
| US11494338B2 (en) | Caching files in a directory | |
| JP2008146760A (ja) | データ書込みパフォーマンスが改善されたテープ記録装置、及びそのデータ書込み制御方法 | |
| US20140247515A1 (en) | Tape drive buffer utilization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20151127 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20160125 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20160218 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160412 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160524 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160621 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160816 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160906 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6005010 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |