テープ媒体にデータを書き込むための装置
【課題】 ＲＡＢＦにおけるリライト時に同期を行えるようにすることにある。
【解決手段】 本発明のテープドライブ１０では、コントローラ１６が、バッファ１２に蓄積されたデータを、テープ１４ａ上のＡＢＦラップへ書き込んだ後に、テープ１４ａ上の通常ラップへリライトする。また、コントローラ１６は、リライトの間にインタフェース１１がホスト２０からデータの同期要求を受け取ると、そのデータを、リライトされているデータと一緒に記録チャネル１３を介してテープ１４ａ上の通常ラップに書き込み、ホスト２０に同期応答を返す。その後、コントローラ１６は、そのデータを通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込む。
【解決手段】 本発明のテープドライブ１０では、コントローラ１６が、バッファ１２に蓄積されたデータを、テープ１４ａ上のＡＢＦラップへ書き込んだ後に、テープ１４ａ上の通常ラップへリライトする。また、コントローラ１６は、リライトの間にインタフェース１１がホスト２０からデータの同期要求を受け取ると、そのデータを、リライトされているデータと一緒に記録チャネル１３を介してテープ１４ａ上の通常ラップに書き込み、ホスト２０に同期応答を返す。その後、コントローラ１６は、そのデータを通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、磁気テープ等のテープ媒体にデータを書き込むための装置等に関する。
【背景技術】
【０００２】
磁気テープ等のテープ媒体にデータを書き込むテープドライブでは、データを一旦バッファに蓄積しておき、所定のタイミングでバッファからテープ媒体へデータを書き込むのが一般的である。このようなバッファからテープ媒体への書込みを、「書込みの同期」又は「バッファフラッシュ」という(以下では、単に「同期」という)。
ところで、テープ媒体を停止させずに同期を行った場合、先行する同期にて書き込まれたデータと、次の同期にて書き込まれたデータとの間に、長いギャップが生じる。その結果、テープ媒体の記録領域が無駄になってしまう。そのため、先行する同期にて書き込まれたデータの後にそれほど長いギャップを伴わずに次の同期にてデータが書き込まれるよう、バックヒッチを行う必要がある。バックヒッチとは、テープ媒体の走行速度を減速して一旦停止し、書き込むべき位置まで戻る、という動作のことである。従って、このバックヒッチのために、同期に多くの時間が費やされるという状況が生じていた。
【０００３】
そこで、かかる状況を回避するための技術として、ＲＡＢＦ(Recursive Accumulating Backhitchless Flush)が提案されている(例えば、特許文献１、２参照)。
この特許文献１、２からも分かるように、ＲＡＢＦは次のような手法と捉えることができる。
即ち、まず、テープドライブが、同期要求を受けた際に、テープにまだ書かれていないバッファ内のデータを、テープ媒体の走行を継続させたまま、テープ媒体上に予約されている一時記録領域(ＡＢＦラップ)に書き出す。尚、この書出しは、先行する同期にて書き込まれたデータと次の同期にて書き込まれたデータとの間のギャップが問題とならないため、バックヒッチを行わないバッファフラッシュ(Backhitchless Flush)である。一方で、テープドライブは、データをバッファに蓄積し(Accumulate)、バッファ又は一時記録領域に空きがなくなった際に通常の記録領域(通常ラップ)に書き戻す(リライトする)動作を反復的に(Recursive)行う。
このように、ＲＡＢＦでは、同期を行う際に、次の同期に備えてバックヒッチを行うことが必要とならないため、同期に要する時間の短縮が図れる。特に、データ量に対する同期要求の頻度が高い場合において、大幅なパフォーマンス向上を実現するものである。
【０００４】
【特許文献１】米国特許第６８５６４７９号明細書
【特許文献２】米国特許第６８６５０４３号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、同期要求に対して直ぐに反応できない状態は依然として存在する。
大別すると、以下の２種類の場合である。
１つは、リニア記録方式に特有の場合であるが、ラップチェンジ、ラップターンと呼ばれる、記録位置(テープ幅方向)の変更や、これに伴う記録方向の変更が行われている場合である。尚、ラップとは、複数(例えば、８つ)のトラックの一まとまりで、ヘッドが同時に読み書きする単位である。
そしてもう１つは、書き戻し(リライト)が行われている場合である。リライト中には同期要求を受け付けられないため、パフォーマンスを伸ばせない原因になる。
ここで、前者の場合においては、ヘッドの移動を伴うため、所定のトラック位置にヘッドがなく、ライトや同期を行うことはできない。一方、後者の場合においては、書き戻し(リライト)の際に同期を受け付けることを可能にすることにより、パフォーマンスを更に向上させる余地はある。
【０００６】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、ＲＡＢＦにおけるパフォーマンスを向上させることにある。
本発明の他の目的は、ＲＡＢＦにおけるリライト時に同期を行えるようにすることにある。
【課題を解決するための手段】
【０００７】
かかる目的のもと、本発明では、リライト中にデータを受けた場合でもバッファの空き領域にデータを受け入れるようにした。即ち、本発明の装置において、バッファは、テープ媒体に書き込むべきデータを蓄積し、コントローラは、バッファに蓄積されたデータのテープ媒体への書込みを制御し、その書込みの間に受け取ったデータをバッファ内の一定の領域に蓄積する。ここで、バッファ内の一定の領域とは、現時点ではアクセスされていないが、そのうちその書込みのためにアクセスされる領域である。具体的には、第一に、バッファを構成する複数のセグメントのうちの任意のセグメントの予めリザーブされた領域であり、第二に、バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントの任意の領域である。
また、この装置において、コントローラが、書込みの間に受け取ったデータを、その書込みのためにアクセスされない領域にコピーするように構成することもできる。
【０００８】
更に、本発明は、リライト中に同期要求されたデータを、リライトを行っているデータと合わせてテープに書き込むための装置として捉えることもできる。その場合、本発明の装置において、バッファは、テープ媒体に書き込むべきデータを蓄積し、コントローラは、バッファに蓄積された第１のデータのテープ媒体上の一時記録領域への第１の書込みの後に、第１のデータのテープ媒体上の通常の記録領域への第２の書込みを制御し、その第２の書込みの間に受け取った第２のデータを、その第２の書込みの対象の一部として通常の記録領域に書き込む。尚、一時記録領域とは、テープ媒体を走行させたままデータを書き込むのに用いられる領域である。
【０００９】
また、この装置において、コントローラが、第１の書込みの後、かつ、第２の書込みの前の所定の時点で、第１の書込みのステータスを出力するように構成することもできる。
更に、コントローラが、第２の書込みの後に第２のデータを受け取った場合と同様の手順で、第２のデータを通常の記録領域に書き込むように構成することもできる。
また、コントローラが、第２のデータの読出し要求に応じて、第２の書込みの対象の一部として通常の記録領域に書き込まれた第２のデータを読み出すように構成することもできる。
【００１０】
更にまた、本発明は、リライト中に同期要求されたデータを、リライトを行っているデータと合わせてテープに書き込むための方法として捉えることもできる。その場合、本発明の方法では、バッファに蓄積された第１のデータをテープ媒体上の一時記録領域に書き込み、第１のデータをテープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、その第２のデータを第１のデータと同じ記録単位に含めて通常の記録領域に書き込む。
【００１１】
一方、本発明は、コンピュータに所定の機能を実現させるコンピュータプログラムとして捉えることもできる。その場合、本発明のコンピュータプログラムは、次の２つの機能をコンピュータに実現させる。１つは、バッファに蓄積された第１のデータのテープ媒体上の一時記録領域への書込みを制御する機能であり、もう１つは、第１のデータをテープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、その第２のデータが第１のデータと同じ記録単位として通常の記録領域に書き込まれるよう制御する機能である。
【発明の効果】
【００１２】
本発明によれば、ＲＡＢＦにおけるパフォーマンスを向上させることができる。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１は、本実施の形態が適用されるテープドライブ１０の構成を示した図である。このテープドライブ１０は、インタフェース１１と、バッファ１２と、記録チャネル１３とを含む。また、テープ１４ａと、ヘッド１４ｂと、リール１４ｃ及び１４ｄと、カートリッジ１４ｅと、モータ１５とを含む。更に、コントローラ１６と、ヘッド位置制御システム１７と、モータドライバ１８とを含む。
【００１４】
このうち、インタフェース１１は、ホスト２０との通信を行う。例えば、ホスト２０から、バッファ１２へのデータの書込みを指示するコマンドや、バッファ１２からテープ１４ａへのデータの書込みを指示するコマンドを受け取る。尚、このインタフェース１１で用いる通信規格としては、ＳＣＳＩ(Small Computer System Interface)が例示される。ＳＣＳＩの場合、前者のコマンドは、Ｗｒｉｔｅコマンドに相当する。また、後者のコマンド(同期コマンド)は、ＷｒｉｔｅＦｉｌｅｍａｒｋ(ＷｒｉｔｅＦＭ)コマンドに相当する。また、インタフェース１１は、ホスト２０に対し、これらのコマンドに応じた処理が成功したのか失敗したのかの応答を返す。
【００１５】
バッファ１２は、テープ１４ａに書き込むべきデータを蓄積するメモリである。例えば、ＤＲＡＭ(Dynamic Random Access Memory)によって構成される。また、バッファ１２は、複数のバッファセグメント(以下、単に「セグメント」という)からなり、各セグメントが、テープ１４ａに対する読み書きの単位であるデータセットを格納している。
記録チャネル１３は、バッファ１２に蓄積されたデータをテープ１４ａに書き出すために用いられる通信経路である。
【００１６】
テープ１４ａは、データの記録手段としてのテープ媒体であり、記録チャネル１３を介して渡されたデータがヘッド１４ｂによりテープ１４ａに書き込まれる。また、テープ１４ａは、リール１４ｃ及び１４ｄに巻かれ、これらの回転に伴い、リール１４ｃからリール１４ｄの方向へ、又は、リール１４ｄからリール１４ｃの方向へ、縦方向に移動する。カートリッジ１４ｅは、テープ１４ａが巻きつけてあるリール１４ｃを収容する容器であるが、リール１４ｄを収容するものを設けてもよい。
また、モータ１５は、リール１４ｃ及び１４ｄを回転させる。尚、図では、１つの矩形でモータ１５を表しているが、モータ１５としては、リール１４ｃ及び１４ｄの各々に１つずつ、合計２個設けるのが好ましい。
【００１７】
一方、コントローラ１６は、テープドライブ１０の全体を制御する。例えば、インタフェース１１で受け付けたコマンドに従って、データのテープ１４ａへの書込みを制御する。また、ヘッド位置制御システム１７やモータドライバ１８の制御も行う。
ヘッド位置制御システム１７は、所望の１つ又は複数のラップを追跡するシステムである。ここで、ラップとは、テープ１４ａ上の複数のトラックのグループである。ラップを切り換える必要が生じると、ヘッド１４ｂを電気的に切り換える必要も生じるので、このような切り換えの制御を、このヘッド位置制御システム１７で行う。
モータドライバ１８は、モータ１５を駆動する。尚、上述したように、モータ１５を２個使用する場合であれば、モータドライバ１８も２個設けられる。また、ここでは、作図の都合上、モータドライバ１８は、ヘッド位置制御システム１７を介してコントローラ１６に接続されているが、直接コントローラ１６に接続されていてもよい。
【００１８】
次に、本実施の形態におけるテープドライブ１０について詳細に説明する。尚、本実施の形態におけるコマンドとしては、ＳＣＳＩのコマンドを例示する。また、本実施の形態では、ＬＴＯ(Linear Tape-Open)規格を例示して説明する。用語についてもＬＴＯ規格に準拠し、例えば、バッファ１２の１つのセグメントに格納されるデータのまとまりを「データセット」とし、データセット中のデータの最後を示すための制御用データを「ＥｎｄＭａｒｋｅｒ」とする。
まず、本実施の形態の概要について説明しておく。
従来のＲＡＢＦでは、リライト時にバッファ１２にデータを受け付ける空きがなかった。また、リライトが行われているため、Ｗｒｉｔｅコマンドで送られたデータをバッファ１２に蓄積し、同期要求に応じてテープ１４ａ上に書き出すことができなかった。
そこで、本実施の形態では、この従来のＲＡＢＦに対し、次のような変更を行った。
【００１９】
・データの蓄積時
従来のＲＡＢＦでは、各セグメントに空きがなくなるまでデータを書き込んでいた。これに対し、本実施の形態では、例えば、セグメントに空きがあるうちに次のセグメントを使い始める。ＩＢＭの３５９２−Ｊ１Ａでは、１つのセグメントは約４００ＫＢであるが、このうち、例えば７／８、つまり約３５０ＫＢに達した時点で、次のセグメントに切り換える。こうすることで、各セグメントに約５０ＫＢの領域がリザーブされ、これをリライト時に受け付けたデータの格納領域として使用することができる。また、３５０ＫＢの領域の最後には、「ＥｎｄＭａｒｋｅｒ」を記録する。これにより、ＡＢＦラップからのリカバリのための読出し時、又は、リライトされたデータの通常の読出し時に、このリザーブされた領域を自動的に読み飛ばすことができる。
或いは、一部のセグメントをリザーブしておき、リライト中に受けたデータをそのリザーブされたセグメントに格納する構成としてもよい。
【００２０】
・同期終了後
従来のＲＡＢＦでは、リライトが完了するまで、直前の同期要求に対するステータスをホスト２０に返さない構成となっていた。これに対し、本実施の形態では、テープドライブ１０にてリライトが行われていてもホスト２０が同期を要求できるようにするために、リライトに移行する直前のデータセットをＡＢＦラップに書き終わった時点でステータスをホスト２０に返すようにした。
【００２１】
・リライト時
リライト中に同期要求が来た場合は、リザーブされた領域にその同期に必要なデータを書き込み、これとリライトを行っているデータとを合わせてテープ１４ａに書き込むようにした。その際、１つのセグメントにリザーブされている領域ではサイズが不十分の場合がある。そのような場合に、自動的に次のセグメントのリザーブされた領域にデータを流し入れることができるようにした。
【００２２】
・リライト終了後
従来のＲＡＢＦには存在しない処理を、本実施の形態では行うようにした。即ち、リザーブされた領域を使って同期が行われたデータを、次にＲＡＢＦが行われるセグメントにコピーする処理である。例えば、約４００ＫＢのセグメントのうち約５０ＫＢをリザーブした場合であれば、次のセグメントの３５０ＫＢの側にコピーを行う。即ち、リライトを行っているデータと合わせてテープ１４ａに書き込まれたデータも、バッファ１２に蓄積された形にしておき、それに続けて次の蓄積処理を行うようにしている。
【００２３】
以下、本実施の形態について、より詳しく説明する。
(第１の実施の形態)
図２〜４は、ホスト２０から送られたデータが一時記録領域に書き込まれ、その後、所定のタイミングで通常の記録領域にリライトされる様子を示した図である。
各図では、中央左寄りに縦長の矩形でバッファ１２が示されている。バッファ１２を構成するセグメントの数は、特に限定されるものではないが、ここでは８個とし、上から順に「Ｓ１」、「Ｓ２」、「Ｓ３」、「Ｓ４」、「Ｓ５」、「Ｓ６」、「Ｓ７」、「Ｓ８」とする。
また、各図において、上側の帯は、通常の記録領域(データが本来記録されるべき領域)を示している。データの記録領域を、テープ１４ａ上の複数のトラックからなるラップと捉えると、この通常の記録領域は、通常ラップである。
一方、各図において、下側の帯は、テープ１４ａを走行させたままデータを記録するのに用いられる一時記録領域を示している。データの記録領域を、テープ１４ａ上の複数のトラックからなるラップと捉えると、この一時記録領域は、ＡＢＦラップである。
【００２４】
図２は、ホスト２０からのＷｒｉｔｅコマンドによりデータがバッファ１２に蓄積され、ホスト２０からのＷｒｉｔｅＦＭコマンドによりデータがバッファ１２からＡＢＦラップへ書き込まれる際の状況を示す。
尚、ここでは、１つのＷｒｉｔｅコマンドにより、１つのデータ要素(斜線を施した最小の単位)がバッファ１２に書き込まれるものとする。また、図示するように、ホスト２０は、３つのＷｒｉｔｅコマンドを送った後、１つのＷｒｉｔｅＦＭコマンドを送るものとする。そして、このＷｒｉｔｅＦＭコマンドによりＡＢＦラップにデータを書き込む際には、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれるものとする。
【００２５】
まず、１番目から３番目までのＷｒｉｔｅコマンドを受けると、１番目から３番目までのデータ要素がバッファに書き込まれる。尚、図２では、この３つのデータ要素をまとめて「Ｄ１」と表示している。その後、ＷｒｉｔｅＦＭコマンドにより、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれる。この場合は、セグメントＳ１内のデータＤ１がＡＢＦラップに書き込まれる。
【００２６】
以下、同様に、４番目から６番目までのＷｒｉｔｅコマンドにより、４番目から６番目までのデータＤ２がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ１及びＳ２内のデータセットがＡＢＦラップに書き込まれる。
また、７番目から９番目までのＷｒｉｔｅコマンドにより、７番目から９番目までのデータＤ３がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２内のデータセットがＡＢＦラップに書き込まれる。
更に、１０番目から１２番目までのＷｒｉｔｅコマンドにより、１０番目から１２番目までのデータＤ４がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２及びＳ３内のデータセットがＡＢＦラップに書き込まれる。
尚、本実施の形態では、各セグメントの一定割合の領域を、リライト中にホスト２０から受けたデータを格納するためのリザーブ領域としている。図２〜４では、バッファ１２の右側の隙間により、このリザーブ領域を表している。
【００２７】
その後、バッファ１２から通常ラップへのリライトが行われる。
図３は、セグメントＳ１内のデータセットが通常ラップにリライトされている際に、ホスト２０からＷｒｉｔｅコマンド及びＷｒｉｔｅＦＭコマンドが送られたときの状態を示している。
この場合、ホスト２０から送られたデータは、リライトのためにアクセスされていないセグメントＳ２のリザーブ領域に格納されている(灰色部分)。
【００２８】
図４は、セグメントＳ２及びＳ３内のデータセットがリライトされる際の状態を示している。
まず、セグメントＳ２内のデータセットは、図示するように、通常ラップのセグメントＳ１の隣に書き込まれている。その際、リライト中に書き込まれたデータ(セグメントＳ２の灰色部分)も、通常ラップに書き込まれる(通常ラップの灰色部分)。
また、セグメントＳ３内のデータセットも、通常ラップのその隣に書き込まれている。
そして、本実施の形態では、リライト中に書き込まれたデータ(セグメントＳ２の灰色部分)を、次にＡＢＦラップに書き込まれるセグメントにコピーしている(セグメントＳ４の灰色部分)。このように、リライト中にリザーブ領域に書かれたデータを、これからＲＡＢＦが行われるセグメントにコピーすることにより、そのデータは、通常のＲＡＢＦの手順に従い、通常ラップに再度書き込まれることになる。
【００２９】
尚、図２〜４では、各セグメント内部の具体的なデータ構造について示していないが、例えば、図５に示すようなデータ構造を前提としている。
即ち、テープ１４ａに記録されるデータとしては、ユーザデータにその誤り訂正のためのＣ１パリティとＣ２パリティが付加された積符号データブロックが採用される。ここで、Ｃ１パリティとは、ユーザデータの行方向の誤りを訂正するために用いられるパリティ符号であり、例えば、図示するように、偶数番目のバイトからなるデータに対するパリティ符号と、奇数番目のバイトからなるデータに対するパリティ符号とを含むものであってもよい。また、Ｃ２パリティとは、ユーザデータの列方向の誤りを訂正するために用いられるパリティ符号である。
【００３０】
このうち、各セグメントには、図５のユーザデータの部分(４６８バイト×５４バイト)が格納される。尚、図２〜４では、各セグメントにおけるリザーブ領域をバッファ１２の右側の隙間で表しているが、これは、リザーブ領域の存在を分かり易くするためであり、実際には、例えば、図５の網掛けの部分がリザーブ領域に相当する。
【００３１】
次に、図６〜８を参照して、本実施の形態におけるテープドライブ１０の動作を説明する。尚、本実施の形態では、リライト中でないときのバッファ１２内のデータの書き込み位置を第１のバッファポインタで指し、リライト中におけるバッファ１２内のデータの書き込み位置を第２のバッファポインタで指すものとする。
【００３２】
まず、ホスト２０からＷｒｉｔｅコマンドを受けたときのコントローラ１６の動作について説明する。
図６は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅコマンドを受け取る(ステップ１０１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１０２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００３３】
その結果、リライト中でないと判定された場合、コントローラ１６は、バッファ１２内の第１のバッファポインタが指す位置にデータを書き込む(ステップ１０３)。そして、現在のセグメントに予め定めた量のデータが書き込まれたかどうかを判定する(ステップ１０４)。ここで、予め定めた量のデータが書き込まれたと判定されれば、「ＥｎｄＭａｒｋｅｒ」を書き込み、第１のバッファポインタを次のセグメントの先頭に進める(ステップ１０５)。また、予め定めた量のデータが書き込まれていないと判定された場合は、第１のバッファポインタを、書き込んだデータの分だけ進める(ステップ１０９)。
【００３４】
一方、ステップ１０２でリライト中と判定された場合、コントローラ１６は、バッファ１２内の第２のバッファポインタが指す位置(リザーブ領域内の位置)にデータを書き込む(ステップ１０６)。そして、セグメントの最後までデータが書き込まれたかどうかを判定する(ステップ１０７)。ここで、最後まで書き込まれたと判定されれば、第２のバッファポインタを次のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１０８)。また、最後まで書き込まれていないと判定されれば、第２のバッファポインタを、書き込んだデータの分だけ進める(ステップ１０９)。
【００３５】
次に、ホスト２０からＷｒｉｔｅＦＭコマンドを受けたときのコントローラ１６の動作について説明する。
図７は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅＦＭコマンドを受け取る(ステップ１１１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１１２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００３６】
その結果、リライト中でないと判定された場合、コントローラ１６は、まず、第１のバッファポインタの位置に「ＦｉｌｅＭａｒｋ」を、コマンドで指定された個数(０個を含む)書き込む(ステップ１１３)。次に、新たにバッファ１２に書き込まれたデータと「ＦｉｌｅＭａｒｋ」とをＡＢＦラップに書き込む(ステップ１１４)。そして、最後に、テープ１４ａに対する書き込みが完了した旨のステータスをホスト２０に返す(ステップ１１５)。
【００３７】
一方、リライト中であると判定された場合、コントローラ１６は、まず、第２のバッファポインタの位置に「ＦｉｌｅＭａｒｋ」を、コマンドで指定された個数(０個を含む)書き込む(ステップ１１６)。次に、「ＦｉｌｅＭａｒｋ」が書き込まれたデータセットがリライトされるのを待つ(ステップ１１７)。そして、最後に、リライト結果に基づいてホスト２０にステータスを返す(ステップ１１８)。
【００３８】
また、このようにＡＢＦラップに書き込まれたデータセットは、その後の所定のタイミングで通常ラップにリライトされる。
図８は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、リライトをすべき旨の指示を受ける(ステップ１２１)。このリライトすべき旨の指示は、例えば、バッファ１２に空き容量がなくなった場合や、ＡＢＦラップを使い切った場合になされる。前者の場合は、バッファ１２の空き容量を監視する手段から指示を受ける。また、後者の場合は、ＡＢＦラップの使用状況を監視する手段から指示を受ける。
【００３９】
リライトの指示を受けると、コントローラ１６は、１番目のセグメント(図２〜４のセグメントＳ１)内のデータセットのリライトの準備をする(ステップ１２２)。ここで、先に述べたように、ホスト２０から送られたデータには、誤り訂正を行うためのパリティ符号を付加してテープ１４ａに記録するので、リライトの準備としては、そのようなパリティ符号の計算等がある。
また、リライト中のセグメントにはホスト２０から送られたデータを書き込むことはできないので、リライト中のデータの書込み位置を指す第２のバッファポインタを、２番目のセグメント(図２〜４のセグメントＳ２)の「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１２３)。尚、図２〜４の例では、この状態でホスト２０からデータが送られ、図６のステップ１０６で、セグメントＳ２のリザーブ領域に書き込まれている。
【００４０】
次いで、コントローラ１６は、次のデータセット、即ち、３番目のセグメント内のデータセットが存在するかどうかを判定する(ステップ１２４)。
その結果、３番目のセグメント内のデータセットが存在すると判定された場合は、リライトの準備ができた１番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、２番目のセグメント内のデータセットのリライトの準備をする(ステップ１２５)。そして、第２のバッファポインタを、３番目のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１２６)。図２〜４の例では、セグメントＳ３にデータが存在するので、セグメントＳ１内のデータを通常ラップに書き込み、セグメントＳ２内のデータのリライトの準備をし、第２のバッファポインタをセグメントＳ３の「ＥｎｄＭａｒｋｅｒ」の直後に進めている。
【００４１】
以下、同様に、(Ｎ＋２)番目のセグメント内にデータが存在すれば、Ｎ番目のセグメント内のデータを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータのリライトの準備をし、第２のバッファポインタを(Ｎ＋２)番目のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める、という処理を繰り返す(Ｎ＝２，３，…)。
【００４２】
一方、(Ｎ＋２)番目のセグメント内にデータセットが存在しないと判定された場合は、Ｎ番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータセットのリライトの準備をし、そして、この(Ｎ＋１)番目のセグメント内のデータセットも通常ラップに書き込む(ステップ１２７)。図２〜４の例の場合、セグメントＳ４内にデータが存在しないので、セグメントＳ２内のデータを通常ラップに書き込んだ後、セグメントＳ３内のデータも通常ラップに書き込んでいる。
【００４３】
その後、このリライト中にホスト２０から送られリザーブ領域に格納されたデータが存在すれば、それらを順次、次のセグメント、即ち、リライト対象となった最後のセグメントの次のセグメントにコピーする(ステップ１２８)。そして、第１のバッファポインタをそのコピーしたデータの直後に進める(ステップ１２９)。図２〜４の例の場合、セグメントＳ２のリザーブ領域に格納されたデータを、セグメントＳ４にコピーしている。
以上により、本実施の形態におけるデータの記録の動作は終了する。
【００４４】
即ち、本実施の形態では、同期要求があった場合にリライト中でなければ、データをＡＢＦラップに書き込んで同期応答を返し、その後、通常ラップにも書き込むようにしている。また、同期要求があった場合にリライト中であれば、送られたデータをリライト中のデータと合わせて通常ラップに書き込んで同期応答を返し、その後、通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込んでいる。
【００４５】
このように、本実施の形態において、ホスト２０から同期要求があった場合、テープ１４ａへの書込みが成功したかどうかは、ホスト２０に報告されるようになっている。
一方、リライトが成功したかどうかは、コントローラ１６は認識しているものの、ＳＣＳＩの仕様により、すぐにはホスト２０に送信されないようになっている。例えば、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来れば、その応答としてリライトの失敗を報告することはできる。しかしながら、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来ないことも考えられる。このような場合、ホスト２０としては、データがその本来記録されるべき通常ラップに書かれたと認識しているにもかかわらず、実際には、通常ラップにデータが正常に記録されていないという事態が生ずる。そこで、このような正常に記録されていないデータの読出し要求があった場合、テープドライブ１０は、本来記録されるべき場所からデータを読み出す代わりに、他の場所に記録されたデータを読み出してホスト２０に返すというリカバリ処理を行う必要がある。
【００４６】
以下、このリカバリ処理を含むＲｅａｄ処理について説明する。
ここでは、テープ１４ａ上に、図９に示すような形式でデータが記録されているものとして説明を行う。尚、データセットＺ及びＥには、既存のアルゴリズムにより、次のデータセットからＲＡＢＦが行われることを示すフラグがセットされているものとする。また、データセットＥには、既存のアルゴリズムにより、リライト単位の最後であることを示すフラグがセットされているものとする。
【００４７】
図１０は、この場合のＲｅａｄ処理の動作を示したフローチャートである。
まず、コントローラ１６は、ホスト２０からＲｅａｄコマンドを受け取る(ステップ１３１)。これにより、コントローラ１６は、記録チャネル１３を介してテープ１４ａから通常のデータの読出しを行う(ステップ１３２)。尚、その際、データセットＢ及びＤの灰色部分のデータは、あくまで同期のために書かれたデータであるので、「ＥｎｄＭａｒｋｅｒ」を検出することで自動的に読み飛ばされるようになっている。
その後、コントローラ１６は、データの読出しに成功したかどうかを判定し(ステップ１３３)、成功していれば、そのまま処理を終了する。
一方、データの読出しに成功していなければ、読出しに失敗したデータセットの種類を判別する(ステップ１３４)。
【００４８】
ここで判別されるデータセットの種類としては、第一に、図９のデータセットＡ〜Ｅのように、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(Ｆの灰色部分)を含まないデータセットがある。このようなデータセットについては、リライトが行われていないときに同期されたデータについて、既存のアルゴリズムによりリカバリを行う(ステップ１３５)。つまり、図９のデータセットＡ〜Ｅの斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。
【００４９】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１３６)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１３７)。つまり、図９のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図９のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００５０】
また、ステップ１３４で判別されるデータセットの種類としては、第二に、図９のデータセットＦのように、リライト中の同期後に通常のＲＡＢＦにより書き込まれたデータ(灰色部分)を含むデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１３８)。つまり、図９のデータセットＦの灰色部分及び斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。そして、特に、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(灰色部分)について、リカバリが成功したかどうかを判定する(ステップ１３９)。その結果、リカバリが成功していれば、そのまま処理を終了し、リカバリが成功していなければ、１つ前のリライト単位のデータを用いてリカバリを行う(ステップ１４０)。つまり、図９のデータセットＦの１番左の灰色部分のデータの読出しに失敗したのであれば、データセットＢの灰色部分のデータを読み出して送信し、図９のデータセットＦのその右隣の灰色部分のデータの読出しに失敗したのであれば、データセットＤの灰色部分のデータを読み出して送信する。
以上により、本実施の形態の動作は終了する。
【００５１】
尚、本実施の形態では、Ｎ番目のセグメント内のデータセットをリライトしている間に、(Ｎ＋１)番目のセグメントについてリライトの準備をし、(Ｎ＋２)番目のセグメントのリザーブ領域にホストからのデータを受け入れるようにしたが、このような形態には限られない。即ち、リライト中にホストから受け付けたデータを格納するセグメントは、リライトのために現にアクセスされているセグメント以外のセグメントで、そのうち今回のリライトのためにアクセスされるセグメントであれば、どの位置にあるセグメントでもよい。
また、本実施の形態では、リライト中に受け付けたデータを、リライト対象のセグメントのリザーブ領域に格納して通常ラップに書き込んだ後、現時点ではリライト対象ではないセグメントにコピーするようにした。しかしながら、リライト中に受け付けたデータを、その時点で、リライト対象のセグメントのリザーブ領域とリライト対象ではないセグメントの両方に格納する構成を採用することも考えられる。
【００５２】
このように、本実施の形態では、リライト中に同期要求が来た場合に、その同期要求に係るデータを各セグメント内のリザーブ領域に格納した後、リライトを行っているデータと合わせてテープに書き込むようにした。これにより、ＲＡＢＦにおけるパフォーマンスを更に向上することができる。
【００５３】
(第２の実施の形態)
図１１〜１３は、ホスト２０から送られたデータが一時記録領域に書き込まれ、その後、所定のタイミングで通常の記録領域にリライトされる様子を示した図である。
これらの図においても、中央左寄りに縦長の矩形でバッファ１２が示されている。バッファ１２を構成するセグメントの数は、特に限定されるものではないが、ここでも８個とし、上から順に「Ｓ１」、「Ｓ２」、「Ｓ３」、「Ｓ４」、「Ｓ５」、「Ｓ６」、「Ｓ７」、「Ｓ８」とする。
また、図２〜４と同様、上側の帯が、データが本来記録されるべき通常の記録領域(通常ラップ)を表し、下側の帯が、テープ１４ａを走行させたままデータを記録するのに用いられる一時記録領域(ＡＢＦラップ)を表している。
【００５４】
図１１は、ホスト２０からのＷｒｉｔｅコマンドによりデータがバッファ１２に蓄積され、ホスト２０からのＷｒｉｔｅＦＭコマンドによりデータがバッファ１２からＡＢＦラップへ書き込まれる際の状況を示す。
尚、ここでも、１つのＷｒｉｔｅコマンドにより、１つのデータ要素(斜線を施した最小の単位)がバッファ１２に書き込まれるものとする。また、図示するように、ホスト２０は、３つのＷｒｉｔｅコマンドを送った後、１つのＷｒｉｔｅＦＭコマンドを送るものとする。そして、このＷｒｉｔｅＦＭコマンドによりＡＢＦラップにデータを書き込む際には、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれるものとする。
【００５５】
まず、１番目から３番目までのＷｒｉｔｅコマンドを受けると、１番目から３番目までのデータ要素がバッファに書き込まれる。尚、図１１でも、この３つのデータ要素をまとめて「Ｄ１」と表示している。その後、ＷｒｉｔｅＦＭコマンドにより、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれる。この場合は、セグメントＳ１内のデータＤ１がＡＢＦラップに書き込まれる。
【００５６】
以下、同様に、４番目から６番目までのＷｒｉｔｅコマンドにより、４番目から６番目までのデータＤ２がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ１及びＳ２内のデータセットがＡＢＦラップに書き込まれる。
また、７番目から９番目までのＷｒｉｔｅコマンドにより、７番目から９番目までのデータＤ３がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２内のデータセットがＡＢＦラップに書き込まれる。
更に、１０番目から１２番目までのＷｒｉｔｅコマンドにより、１０番目から１２番目までのデータＤ４がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２及びＳ３内のデータセットがＡＢＦラップに書き込まれる。
尚、本実施の形態では、バッファ１２を構成する複数のセグメントの一部を、リライト中にホスト２０から受けたデータを格納するためのリザーブセグメントとしている。具体的には、セグメントＳ７及びＳ８をリザーブセグメントとして確保している(図１１〜１３の網掛け部分)。
【００５７】
その後、バッファ１２から通常ラップへのリライトが行われる。
図１２は、セグメントＳ１内のデータセットが通常ラップにリライトされている際に、ホスト２０からＷｒｉｔｅコマンド及びＷｒｉｔｅＦＭコマンドが送られたときの状態を示している。
この場合、ホスト２０から送られたデータは、リザーブセグメントＳ７に格納されている(灰色部分)。
【００５８】
図１３は、セグメントＳ２及びＳ３内のデータセットがリライトされる際の状態を示している。
まず、セグメントＳ２内のデータセットは、図示するように、通常ラップのセグメントＳ１の隣に書き込まれている。
次いで、リザーブセグメントであるセグメントＳ７内のデータセット(セグメントＳ７の灰色部分)が、その隣に書き込まれている(通常ラップの灰色部分)。バッファ１２の上から順にリライトが行われるのであれば、このような順序の逆転は生じないが、本実施の形態では、リライトの準備が整ったものからリライトするようにしているので、リザーブセグメント内のデータセットが先にリライトされることも起こり得るようになっている。
その後、セグメントＳ３内のデータセットが、通常ラップのセグメントＳ７の隣に書き込まれている。
そして、本実施の形態では、リライト中に書き込まれたデータ(セグメントＳ７の灰色部分)を、次にＡＢＦラップに書き込まれるセグメントにコピーしている(セグメントＳ４の灰色部分)。このように、リライト中にリザーブ領域に書かれたデータを、これからＲＡＢＦが行われるセグメントにコピーすることにより、そのデータは、通常のＲＡＢＦの手順に従い、通常ラップに再度書き込まれることになる。
【００５９】
次に、図１４及び１５を参照して、本実施の形態におけるテープドライブ１０の動作を説明する。尚、本実施の形態では、リライト中でないときのデータの書き込み位置も、リライト中におけるデータの書き込み位置も同じバッファポインタで指すものとする。
まず、ホスト２０からＷｒｉｔｅコマンドを受けたときのコントローラ１６の動作について説明する。
図１４は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅコマンドを受け取る(ステップ１４１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１４２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００６０】
その結果、リライト中でないと判定された場合、コントローラ１６は、バッファ１２内のバッファポインタが指す位置にデータを書き込む(ステップ１４３)。そして、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。
一方、リライト中と判定された場合、コントローラ１６は、バッファ１２内のバッファポインタが指す位置(リザーブセグメント内の位置)にデータを書き込む(ステップ１４５)。そして、セグメントの最後までデータが書き込まれたかどうかを判定する(ステップ１４６)。ここで、最後まで書き込まれていないと判定されれば、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。また、最後まで書き込まれたと判定されれば、このリザーブセグメントにリライト可能(リライトされるデータセットと合わせて書き込むことが可能)の印を付け(ステップ１４７)、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。
【００６１】
次に、ホスト２０からＷｒｉｔｅＦＭコマンドを受けると、コントローラ１６は、リライト中でなければ、バッファ１２内のデータをＡＢＦラップに書き込み、ホスト２０にステータスを返す。一方、リライト中であれば、ホスト２０から受け取ったデータが通常ラップにリライトされるのを待ち、リライトのステータスをホスト２０に返す。尚、この動作は、図７と同様であるので、詳細な説明は省略する。但し、本実施の形態では、「ＦｉｌｅＭａｒｋ」をバッファ１２にコマンドで指定された個数(０個を含む)書き込んだ後、そのセグメントに最後までデータが書かれていなくても、リライトされるデータに混ぜて書き出す必要がある。そこで、図７のステップ１１７において、途中まで書かれていたセグメントに、ステップ１４７で付けたのと同様の印を付ける処理も行う。
【００６２】
また、このようにＡＢＦラップに書き込まれたデータセットは、その後の所定のタイミングで通常ラップにリライトされる。
図１５は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、リライトをすべき旨の指示を受ける(ステップ１５１)。このリライトすべき旨の指示は、例えば、バッファ１２に空き容量がなくなった場合や、ＡＢＦラップを使い切った場合になされる。前者の場合は、バッファ１２の空き容量を監視する手段から指示を受ける。また、後者の場合は、ＡＢＦラップの使用状況を監視する手段から指示を受ける。
【００６３】
リライトの指示を受けると、コントローラ１６は、バッファポインタをリザーブセグメント(図１１〜１３のセグメントＳ７)の先頭に切り換える(ステップ１５２)。本実施の形態において、バッファポインタは、通常のセグメントとリザーブセグメントに共通に用いているためである。
また、コントローラ１６は、１番目のセグメント(図１１〜１３のセグメントＳ１)内のデータセットのリライトの準備をする(ステップ１５３)。ここで、先に述べたように、ホスト２０から送られたデータには、誤り訂正を行うためのパリティ符号を付加してテープ１４ａに記録するので、リライトの準備としては、そのようなパリティ符号の計算等がある。
【００６４】
次いで、コントローラ１６は、次のデータセット、即ち、２番目のセグメント内のデータセットが存在するかどうかを判定する(ステップ１５４)。尚、この判定の対象となるセグメントには、リザーブセグメントも含まれる。
その結果、２番目のセグメント内のデータセットが存在すると判定された場合は、リライトの準備ができた１番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、２番目のセグメント内のデータセットのリライトの準備をする(ステップ１５５)。
そして、現在バッファポインタが位置づけられているリザーブセグメントがリライト可能かどうかを、ステップ１４７で付けられた印に基づいて判定する(ステップ１５６)。ここで、リザーブセグメントがリライト可能でなければ、そのまま処理はステップ１５４に進む。また、リザーブセグメントがリライト可能であれば、バッファポインタを次のリザーブセグメント(図１１〜１３のセグメントＳ８)の先頭に進め(ステップ１５７)、処理は１５４に進む。図１１〜１３の例では、セグメントＳ２にデータが存在するので、セグメントＳ１内のデータを通常ラップに書き込み、セグメントＳ２内のデータのリライトの準備をしている。
【００６５】
以下、同様に、(Ｎ＋１)番目のセグメント内にデータが存在すれば、Ｎ番目のセグメント内のデータを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータのリライトの準備をし、リザーブセグメントがリライト可能になっていれば、バッファポインタを次のリザーブセグメントの先頭に進める、という処理を繰り返す(Ｎ＝２，３，…)。図１１〜１４の例では、この時点でセグメントＳ７がリライト可能になっているとし、これを３番目のセグメントとしている。そして、セグメントＳ２内のデータを通常ラップに書き込み、セグメントＳ７内のデータのリライトの準備をしている(Ｎ＝２の場合)。また、４番目のセグメントとなるセグメントＳ３にデータが存在するので、セグメントＳ７内のデータを通常ラップに書き込み、セグメントＳ３内のデータのリライトの準備をしている(Ｎ＝３の場合)。
【００６６】
一方、(Ｎ＋１)番目のセグメント内にデータセットが存在しないと判定された場合は、Ｎ番目のセグメント内のデータセットを通常ラップに書き込む(ステップ１５８)。図１１〜１３の例の場合、セグメントＳ４内にデータが存在しないので、セグメントＳ３内のデータを通常ラップに書き込んでいる。
【００６７】
その後、このリライト中にホスト２０から送られリザーブセグメントに格納されたデータが存在すれば、それらを順次、リライト対象となった最後のセグメント(リザーブセグメントを除く)の次のセグメントにコピーする(ステップ１５９)。そして、バッファポインタをそのコピーしたデータの直後に進める(ステップ１６０)。図１１〜１３の例の場合、セグメントＳ７に格納されたデータを、セグメントＳ４にコピーしている。
以上により、本実施の形態におけるデータの記録の動作は終了する。
【００６８】
即ち、本実施の形態でも、同期要求があった場合にリライト中でなければ、データをＡＢＦラップに書き込んで同期応答を返し、その後、通常ラップにも書き込むようにしている。また、同期要求があった場合にリライト中であれば、送られたデータをリライト中のデータと合わせて通常ラップに書き込んで同期応答を返し、その後、通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込んでいる。
【００６９】
このように、本実施の形態において、ホスト２０から同期要求があった場合、テープ１４ａへの書込みが成功したかどうかは、ホスト２０に報告されるようになっている。
一方、リライトが成功したかどうかは、コントローラ１６は認識しているものの、ＳＣＳＩの仕様により、すぐにはホスト２０に送信されないようになっている。例えば、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来れば、その応答としてリライトの失敗を報告することはできる。しかしながら、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来ないことも考えられる。このような場合、ホスト２０としては、データがその本来記録されるべき通常ラップに書かれたと認識しているにもかかわらず、実際には、通常ラップにデータが正常に記録されていないという事態が生ずる。そこで、このような正常に記録されていないデータの読出し要求があった場合、テープドライブ１０は、本来記録されるべき場所からデータを読み出す代わりに、他の場所に記録されたデータを読み出してホスト２０に返すというリカバリ処理を行う必要がある。
【００７０】
以下、このリカバリ処理を含むＲｅａｄ処理について説明する。
ここでは、テープ１４ａ上に、図１６に示すような形式でデータが記録されているものとして説明を行う。尚、各データセットには、データセット番号及びライトパス番号が付加されているものとする。ここで、データセット番号とは、書かれた順(読み出す順)を示す連続値である。その際、リライト中の同期で書かれたデータセットが読み飛ばされるよう、同期で書かれたデータセットと通常のデータセットとには同じデータセット番号を振っておき、ライトパス番号で区別するようにする。また、データセットＢ及びＤには、リライト中の同期で書かれたデータセットであることを示すフラグがセットされているものとする。
【００７１】
図１７は、この場合のＲｅａｄ処理の動作を示したフローチャートである。
まず、コントローラ１６は、ホスト２０からＲｅａｄコマンドを受け取る(ステップ１６１)。これにより、コントローラ１６は、記録チャネル１３を介して磁気テープから通常のデータの読出しを行う(ステップ１６２)。尚、その際、データセットＢ及びＤは、あくまで同期のために書かれたデータセットであるので、通常は、データセット番号及びライトパス番号を参照することで自動的に読み飛ばされるようになっている。
その後、コントローラ１６は、データの読出しに成功したかどうかを判定し(ステップ１６３)、成功していれば、そのまま処理は終了する。
一方、データの読出しに成功していなければ、読出しに失敗したデータセットの種類を判別する(ステップ１６４)。
【００７２】
ここで判別されるデータセットの種類としては、第一に、図１６のデータセットＡのように、リライト中の同期で書かれたデータセットの直後のデータセット以外のデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１６６)。
【００７３】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１６７)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１６８)。つまり、図１６のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図１６のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００７４】
また、ステップ１６４で判別されるデータセットの種類としては、第二に、図１６のデータセットＣ、Ｅのように、リライト中の同期で書かれたデータセットの直後のデータセットがある。この場合、直前のデータセットＢ、Ｄは、上述したように、通常は、読み飛ばされるのであるが、データセットＣ、Ｅの読出しに失敗したことにより、データセットＢ、ＤをデータセットＣ、Ｅであると誤認してしまうことが考えられる。そこで、コントローラ１６は、リライト中の同期で書かれたデータセットであることを示すフラグを参照して、直前のデータセットが目的のデータセットではないことを判別する(ステップ１６５)。そして、データセットＣ、Ｅについて、既存のアルゴリズムによりリカバリを行う(ステップ１６６)。
【００７５】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１６７)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１６８)。つまり、図１６のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図１６のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００７６】
更に、ステップ１６４で判別されるデータセットの種類としては、第三に、図１６のデータセットＦのように、リライト中の同期後に通常のＲＡＢＦにより書き込まれたデータ(灰色部分)を含むデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１６９)。つまり、図１６のデータセットＦの灰色部分及び斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。そして、特に、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(灰色部分)について、リカバリが成功したかどうかを判定する(ステップ１７０)。その結果、リカバリが成功していれば、そのまま処理を終了し、リカバリが成功していなければ、１つ前のリライト単位のデータを用いてリカバリを行う(ステップ１７１)。つまり、図１６のデータセットＦの１番左の灰色部分のデータの読出しに失敗したのであれば、データセットＢの灰色部分のデータを読み出して送信し、図１６のデータセットＦのその右隣の灰色部分のデータの読出しに失敗したのであれば、データセットＤの灰色部分のデータを読み出して送信する。
以上により、本実施の形態の動作は終了する。
【００７７】
尚、本実施の形態では、リライト中に受け付けたデータを、リザーブセグメントに格納して通常ラップに書き込んだ後、現時点ではリライト対象ではないセグメントにコピーするようにした。しかしながら、リライト中に受け付けたデータを、その時点で、リザーブセグメントとリライト対象ではないセグメントの両方に格納する構成を採用することも考えられる。
【００７８】
このように、本実施の形態では、リライト中に同期要求が来た場合に、その同期要求に係るデータをリザーブセグメントに格納した後、リライトを行っているデータと合わせてテープに書き込むようにした。これにより、ＲＡＢＦにおけるパフォーマンスを更に向上することができる。
【００７９】
尚、同期要求がホストから送られる間隔が長い場合は、リライト中に同期要求が送られる確率も低くなる。従って、本実施の形態は、同期要求の間隔が短い場合において特に有効である。
また、データの読出しの際のレートは、同期のために記録されたデータが読み出されない分、通常の方式で記録した場合よりも悪くなる。例えば、先に述べた、４００ＫＢのうちの５０ＫＢをリザーブ領域として確保する場合であれば、通常の方式で記録した場合のレートが約４０ＭＢ/ｓとすると、本実施の形態の方式を用いた場合、約３５ＭＢ/ｓとなってしまう。従って、本実施の形態は、書込みが読出しよりも多い場合、即ち、データの重要度が高い場合に、特に有効と言える。このようなものとして、例えば、一般的なＢａｃｋｕｐ/Ｒｅｓｔｏｒｅアプリケーションが想定できる。このようなアプリケーションにおいては、通常、バックアップのみが行われ、リストアはまれにしか行われないため、読出しのパフォーマンスの低下はあまり問題とならない。
【００８０】
同じ理由で、カートリッジの容量が減ることになる。しかしながら、現在の製品の使われ方をみると、同期を頻繁に要求するアプリケーションは、従来からの所謂大型機をホストとするものが大半であり、これらのアプリケーションは、カートリッジの容量を使い切らずに、次のカートリッジを利用することが多い。このため、本実施の形態では、カートリッジ容量の減少は問題にはならない。
また、同期の頻度が低い場合にはＲＡＢＦが起動されないので、パフォーマンスの低下やカートリッジ容量の減少は、必ず起こるというものでもない。
【００８１】
このように、本発明では、書込みの際のパフォーマンスが向上する代わりに、キャパシティのロスが発生する可能性がある。
しかしながら、これに対しては、データセットサイズを可変長とする技術(１/Ｎを単位としてデータセットサイズをその１〜Ｎ倍にできる技術)を用いることで、問題を大幅に緩和できる。
【００８２】
具体的には、次のような手法を採用することができる。
第１の実施の形態では、例えば、各セグメントの１/Ｎをリザーブ領域とする。そして、リライト中の同期によるデータの追加が生じなかったデータセットは、(Ｎ−１)/Ｎのサイズとし、リライト中の同期によるデータの追加が生じたデータセットは、Ｎ/Ｎのサイズとする。これにより、キャパシティの減少や、読出し時のデータレートの低下を緩和することができる。
また、第２の実施の形態では、挿入されるデータセット(リザーブセグメントに格納されていたデータセット)のサイズを、同期のためのデータのサイズよりも少し大きなサイズとすればよい。これにより、上記と同様、キャパシティの減少や、読出し時のデータレートの低下を緩和することができる。
【００８３】
尚、モデルによる性能評価を行ったので、以下に記す。
ここでは、セグメントサイズ(データセットサイズ)を４００ＫＢ、バッファ内のセグメント数を１０００、一度に同期するデータの量を４８ＫＢ〜３８４ＫＢとした。
第１の実施の形態の方式を用いた場合、リザーブ領域のサイズを５０ＫＢとすると、最大１２．５％のキャパシティロスはあったものの、従来のＲＡＢＦの１０３％〜１０７％のパフォーマンスが認められた。
また、第２の実施の形態の方式を用いた場合、２４％〜１７％のキャパシティロスはあったものの、従来のＲＡＢＦの１０２％〜１１３％のパフォーマンスが認められた。
【００８４】
ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。
また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム(装置又は機器)、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ(ＲＡＭ)、リードオンリーメモリ(ＲＯＭ)、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ(ＣＤ−ＲＯＭ)、コンパクトディスク−リード/ライト(ＣＤ−Ｒ/Ｗ)及びＤＶＤが含まれる。
【図面の簡単な説明】
【００８５】
【図１】本発明の実施の形態が適用されるテープドライブの構成を示したブロック図である。
【図２】本発明の第１の実施の形態におけるバッファからテープへの書込みの第１段階について説明するための図である。
【図３】本発明の第１の実施の形態におけるバッファからテープへの書込みの第２段階について説明するための図である。
【図４】本発明の第１の実施の形態におけるバッファからテープへの書込みの第３段階について説明するための図である。
【図５】本発明の実施の形態におけるデータセットの構造について説明するための図である。
【図６】本発明の第１の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅコマンド受付け時の動作を示したフローチャートである。
【図７】本発明の第１の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅＦＭコマンド受付け時の動作を示したフローチャートである。
【図８】本発明の第１の実施の形態におけるテープドライブのコントローラのリライト時の動作を示したフローチャートである。
【図９】本発明の第１の実施の形態におけるＲｅａｄ処理の説明に用いるテープ上のデータセットの配置例である。
【図１０】本発明の第１の実施の形態におけるテープドライブのコントローラのＲｅａｄ処理の動作を示したフローチャートである。
【図１１】本発明の第２の実施の形態におけるバッファからテープへの書込みの第１段階について説明するための図である。
【図１２】本発明の第２の実施の形態におけるバッファからテープへの書込みの第２段階について説明するための図である。
【図１３】本発明の第２の実施の形態におけるバッファからテープへの書込みの第３段階について説明するための図である。
【図１４】本発明の第２の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅコマンド受付け時の動作を示したフローチャートである。
【図１５】本発明の第２の実施の形態におけるテープドライブのコントローラのリライト時の動作を示したフローチャートである。
【図１６】本発明の第２の実施の形態におけるＲｅａｄ処理の説明に用いるテープ上のデータセットの配置例である。
【図１７】本発明の第２の実施の形態におけるテープドライブのコントローラのＲｅａｄ処理の動作を示したフローチャートである。
【符号の説明】
【００８６】
１０…テープドライブ、１１…インタフェース、１２…バッファ、１３…記録チャネル、１４ａ…テープ、１４ｂ…ヘッド、１４ｃ，１４ｄ…リール、１４ｅ…カートリッジ、１５…モータ、１６…コントローラ、１７…ヘッド位置制御システム、１８…モータドライバ
【技術分野】
【０００１】
本発明は、磁気テープ等のテープ媒体にデータを書き込むための装置等に関する。
【背景技術】
【０００２】
磁気テープ等のテープ媒体にデータを書き込むテープドライブでは、データを一旦バッファに蓄積しておき、所定のタイミングでバッファからテープ媒体へデータを書き込むのが一般的である。このようなバッファからテープ媒体への書込みを、「書込みの同期」又は「バッファフラッシュ」という(以下では、単に「同期」という)。
ところで、テープ媒体を停止させずに同期を行った場合、先行する同期にて書き込まれたデータと、次の同期にて書き込まれたデータとの間に、長いギャップが生じる。その結果、テープ媒体の記録領域が無駄になってしまう。そのため、先行する同期にて書き込まれたデータの後にそれほど長いギャップを伴わずに次の同期にてデータが書き込まれるよう、バックヒッチを行う必要がある。バックヒッチとは、テープ媒体の走行速度を減速して一旦停止し、書き込むべき位置まで戻る、という動作のことである。従って、このバックヒッチのために、同期に多くの時間が費やされるという状況が生じていた。
【０００３】
そこで、かかる状況を回避するための技術として、ＲＡＢＦ(Recursive Accumulating Backhitchless Flush)が提案されている(例えば、特許文献１、２参照)。
この特許文献１、２からも分かるように、ＲＡＢＦは次のような手法と捉えることができる。
即ち、まず、テープドライブが、同期要求を受けた際に、テープにまだ書かれていないバッファ内のデータを、テープ媒体の走行を継続させたまま、テープ媒体上に予約されている一時記録領域(ＡＢＦラップ)に書き出す。尚、この書出しは、先行する同期にて書き込まれたデータと次の同期にて書き込まれたデータとの間のギャップが問題とならないため、バックヒッチを行わないバッファフラッシュ(Backhitchless Flush)である。一方で、テープドライブは、データをバッファに蓄積し(Accumulate)、バッファ又は一時記録領域に空きがなくなった際に通常の記録領域(通常ラップ)に書き戻す(リライトする)動作を反復的に(Recursive)行う。
このように、ＲＡＢＦでは、同期を行う際に、次の同期に備えてバックヒッチを行うことが必要とならないため、同期に要する時間の短縮が図れる。特に、データ量に対する同期要求の頻度が高い場合において、大幅なパフォーマンス向上を実現するものである。
【０００４】
【特許文献１】米国特許第６８５６４７９号明細書
【特許文献２】米国特許第６８６５０４３号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、同期要求に対して直ぐに反応できない状態は依然として存在する。
大別すると、以下の２種類の場合である。
１つは、リニア記録方式に特有の場合であるが、ラップチェンジ、ラップターンと呼ばれる、記録位置(テープ幅方向)の変更や、これに伴う記録方向の変更が行われている場合である。尚、ラップとは、複数(例えば、８つ)のトラックの一まとまりで、ヘッドが同時に読み書きする単位である。
そしてもう１つは、書き戻し(リライト)が行われている場合である。リライト中には同期要求を受け付けられないため、パフォーマンスを伸ばせない原因になる。
ここで、前者の場合においては、ヘッドの移動を伴うため、所定のトラック位置にヘッドがなく、ライトや同期を行うことはできない。一方、後者の場合においては、書き戻し(リライト)の際に同期を受け付けることを可能にすることにより、パフォーマンスを更に向上させる余地はある。
【０００６】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、ＲＡＢＦにおけるパフォーマンスを向上させることにある。
本発明の他の目的は、ＲＡＢＦにおけるリライト時に同期を行えるようにすることにある。
【課題を解決するための手段】
【０００７】
かかる目的のもと、本発明では、リライト中にデータを受けた場合でもバッファの空き領域にデータを受け入れるようにした。即ち、本発明の装置において、バッファは、テープ媒体に書き込むべきデータを蓄積し、コントローラは、バッファに蓄積されたデータのテープ媒体への書込みを制御し、その書込みの間に受け取ったデータをバッファ内の一定の領域に蓄積する。ここで、バッファ内の一定の領域とは、現時点ではアクセスされていないが、そのうちその書込みのためにアクセスされる領域である。具体的には、第一に、バッファを構成する複数のセグメントのうちの任意のセグメントの予めリザーブされた領域であり、第二に、バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントの任意の領域である。
また、この装置において、コントローラが、書込みの間に受け取ったデータを、その書込みのためにアクセスされない領域にコピーするように構成することもできる。
【０００８】
更に、本発明は、リライト中に同期要求されたデータを、リライトを行っているデータと合わせてテープに書き込むための装置として捉えることもできる。その場合、本発明の装置において、バッファは、テープ媒体に書き込むべきデータを蓄積し、コントローラは、バッファに蓄積された第１のデータのテープ媒体上の一時記録領域への第１の書込みの後に、第１のデータのテープ媒体上の通常の記録領域への第２の書込みを制御し、その第２の書込みの間に受け取った第２のデータを、その第２の書込みの対象の一部として通常の記録領域に書き込む。尚、一時記録領域とは、テープ媒体を走行させたままデータを書き込むのに用いられる領域である。
【０００９】
また、この装置において、コントローラが、第１の書込みの後、かつ、第２の書込みの前の所定の時点で、第１の書込みのステータスを出力するように構成することもできる。
更に、コントローラが、第２の書込みの後に第２のデータを受け取った場合と同様の手順で、第２のデータを通常の記録領域に書き込むように構成することもできる。
また、コントローラが、第２のデータの読出し要求に応じて、第２の書込みの対象の一部として通常の記録領域に書き込まれた第２のデータを読み出すように構成することもできる。
【００１０】
更にまた、本発明は、リライト中に同期要求されたデータを、リライトを行っているデータと合わせてテープに書き込むための方法として捉えることもできる。その場合、本発明の方法では、バッファに蓄積された第１のデータをテープ媒体上の一時記録領域に書き込み、第１のデータをテープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、その第２のデータを第１のデータと同じ記録単位に含めて通常の記録領域に書き込む。
【００１１】
一方、本発明は、コンピュータに所定の機能を実現させるコンピュータプログラムとして捉えることもできる。その場合、本発明のコンピュータプログラムは、次の２つの機能をコンピュータに実現させる。１つは、バッファに蓄積された第１のデータのテープ媒体上の一時記録領域への書込みを制御する機能であり、もう１つは、第１のデータをテープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、その第２のデータが第１のデータと同じ記録単位として通常の記録領域に書き込まれるよう制御する機能である。
【発明の効果】
【００１２】
本発明によれば、ＲＡＢＦにおけるパフォーマンスを向上させることができる。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。
図１は、本実施の形態が適用されるテープドライブ１０の構成を示した図である。このテープドライブ１０は、インタフェース１１と、バッファ１２と、記録チャネル１３とを含む。また、テープ１４ａと、ヘッド１４ｂと、リール１４ｃ及び１４ｄと、カートリッジ１４ｅと、モータ１５とを含む。更に、コントローラ１６と、ヘッド位置制御システム１７と、モータドライバ１８とを含む。
【００１４】
このうち、インタフェース１１は、ホスト２０との通信を行う。例えば、ホスト２０から、バッファ１２へのデータの書込みを指示するコマンドや、バッファ１２からテープ１４ａへのデータの書込みを指示するコマンドを受け取る。尚、このインタフェース１１で用いる通信規格としては、ＳＣＳＩ(Small Computer System Interface)が例示される。ＳＣＳＩの場合、前者のコマンドは、Ｗｒｉｔｅコマンドに相当する。また、後者のコマンド(同期コマンド)は、ＷｒｉｔｅＦｉｌｅｍａｒｋ(ＷｒｉｔｅＦＭ)コマンドに相当する。また、インタフェース１１は、ホスト２０に対し、これらのコマンドに応じた処理が成功したのか失敗したのかの応答を返す。
【００１５】
バッファ１２は、テープ１４ａに書き込むべきデータを蓄積するメモリである。例えば、ＤＲＡＭ(Dynamic Random Access Memory)によって構成される。また、バッファ１２は、複数のバッファセグメント(以下、単に「セグメント」という)からなり、各セグメントが、テープ１４ａに対する読み書きの単位であるデータセットを格納している。
記録チャネル１３は、バッファ１２に蓄積されたデータをテープ１４ａに書き出すために用いられる通信経路である。
【００１６】
テープ１４ａは、データの記録手段としてのテープ媒体であり、記録チャネル１３を介して渡されたデータがヘッド１４ｂによりテープ１４ａに書き込まれる。また、テープ１４ａは、リール１４ｃ及び１４ｄに巻かれ、これらの回転に伴い、リール１４ｃからリール１４ｄの方向へ、又は、リール１４ｄからリール１４ｃの方向へ、縦方向に移動する。カートリッジ１４ｅは、テープ１４ａが巻きつけてあるリール１４ｃを収容する容器であるが、リール１４ｄを収容するものを設けてもよい。
また、モータ１５は、リール１４ｃ及び１４ｄを回転させる。尚、図では、１つの矩形でモータ１５を表しているが、モータ１５としては、リール１４ｃ及び１４ｄの各々に１つずつ、合計２個設けるのが好ましい。
【００１７】
一方、コントローラ１６は、テープドライブ１０の全体を制御する。例えば、インタフェース１１で受け付けたコマンドに従って、データのテープ１４ａへの書込みを制御する。また、ヘッド位置制御システム１７やモータドライバ１８の制御も行う。
ヘッド位置制御システム１７は、所望の１つ又は複数のラップを追跡するシステムである。ここで、ラップとは、テープ１４ａ上の複数のトラックのグループである。ラップを切り換える必要が生じると、ヘッド１４ｂを電気的に切り換える必要も生じるので、このような切り換えの制御を、このヘッド位置制御システム１７で行う。
モータドライバ１８は、モータ１５を駆動する。尚、上述したように、モータ１５を２個使用する場合であれば、モータドライバ１８も２個設けられる。また、ここでは、作図の都合上、モータドライバ１８は、ヘッド位置制御システム１７を介してコントローラ１６に接続されているが、直接コントローラ１６に接続されていてもよい。
【００１８】
次に、本実施の形態におけるテープドライブ１０について詳細に説明する。尚、本実施の形態におけるコマンドとしては、ＳＣＳＩのコマンドを例示する。また、本実施の形態では、ＬＴＯ(Linear Tape-Open)規格を例示して説明する。用語についてもＬＴＯ規格に準拠し、例えば、バッファ１２の１つのセグメントに格納されるデータのまとまりを「データセット」とし、データセット中のデータの最後を示すための制御用データを「ＥｎｄＭａｒｋｅｒ」とする。
まず、本実施の形態の概要について説明しておく。
従来のＲＡＢＦでは、リライト時にバッファ１２にデータを受け付ける空きがなかった。また、リライトが行われているため、Ｗｒｉｔｅコマンドで送られたデータをバッファ１２に蓄積し、同期要求に応じてテープ１４ａ上に書き出すことができなかった。
そこで、本実施の形態では、この従来のＲＡＢＦに対し、次のような変更を行った。
【００１９】
・データの蓄積時
従来のＲＡＢＦでは、各セグメントに空きがなくなるまでデータを書き込んでいた。これに対し、本実施の形態では、例えば、セグメントに空きがあるうちに次のセグメントを使い始める。ＩＢＭの３５９２−Ｊ１Ａでは、１つのセグメントは約４００ＫＢであるが、このうち、例えば７／８、つまり約３５０ＫＢに達した時点で、次のセグメントに切り換える。こうすることで、各セグメントに約５０ＫＢの領域がリザーブされ、これをリライト時に受け付けたデータの格納領域として使用することができる。また、３５０ＫＢの領域の最後には、「ＥｎｄＭａｒｋｅｒ」を記録する。これにより、ＡＢＦラップからのリカバリのための読出し時、又は、リライトされたデータの通常の読出し時に、このリザーブされた領域を自動的に読み飛ばすことができる。
或いは、一部のセグメントをリザーブしておき、リライト中に受けたデータをそのリザーブされたセグメントに格納する構成としてもよい。
【００２０】
・同期終了後
従来のＲＡＢＦでは、リライトが完了するまで、直前の同期要求に対するステータスをホスト２０に返さない構成となっていた。これに対し、本実施の形態では、テープドライブ１０にてリライトが行われていてもホスト２０が同期を要求できるようにするために、リライトに移行する直前のデータセットをＡＢＦラップに書き終わった時点でステータスをホスト２０に返すようにした。
【００２１】
・リライト時
リライト中に同期要求が来た場合は、リザーブされた領域にその同期に必要なデータを書き込み、これとリライトを行っているデータとを合わせてテープ１４ａに書き込むようにした。その際、１つのセグメントにリザーブされている領域ではサイズが不十分の場合がある。そのような場合に、自動的に次のセグメントのリザーブされた領域にデータを流し入れることができるようにした。
【００２２】
・リライト終了後
従来のＲＡＢＦには存在しない処理を、本実施の形態では行うようにした。即ち、リザーブされた領域を使って同期が行われたデータを、次にＲＡＢＦが行われるセグメントにコピーする処理である。例えば、約４００ＫＢのセグメントのうち約５０ＫＢをリザーブした場合であれば、次のセグメントの３５０ＫＢの側にコピーを行う。即ち、リライトを行っているデータと合わせてテープ１４ａに書き込まれたデータも、バッファ１２に蓄積された形にしておき、それに続けて次の蓄積処理を行うようにしている。
【００２３】
以下、本実施の形態について、より詳しく説明する。
(第１の実施の形態)
図２〜４は、ホスト２０から送られたデータが一時記録領域に書き込まれ、その後、所定のタイミングで通常の記録領域にリライトされる様子を示した図である。
各図では、中央左寄りに縦長の矩形でバッファ１２が示されている。バッファ１２を構成するセグメントの数は、特に限定されるものではないが、ここでは８個とし、上から順に「Ｓ１」、「Ｓ２」、「Ｓ３」、「Ｓ４」、「Ｓ５」、「Ｓ６」、「Ｓ７」、「Ｓ８」とする。
また、各図において、上側の帯は、通常の記録領域(データが本来記録されるべき領域)を示している。データの記録領域を、テープ１４ａ上の複数のトラックからなるラップと捉えると、この通常の記録領域は、通常ラップである。
一方、各図において、下側の帯は、テープ１４ａを走行させたままデータを記録するのに用いられる一時記録領域を示している。データの記録領域を、テープ１４ａ上の複数のトラックからなるラップと捉えると、この一時記録領域は、ＡＢＦラップである。
【００２４】
図２は、ホスト２０からのＷｒｉｔｅコマンドによりデータがバッファ１２に蓄積され、ホスト２０からのＷｒｉｔｅＦＭコマンドによりデータがバッファ１２からＡＢＦラップへ書き込まれる際の状況を示す。
尚、ここでは、１つのＷｒｉｔｅコマンドにより、１つのデータ要素(斜線を施した最小の単位)がバッファ１２に書き込まれるものとする。また、図示するように、ホスト２０は、３つのＷｒｉｔｅコマンドを送った後、１つのＷｒｉｔｅＦＭコマンドを送るものとする。そして、このＷｒｉｔｅＦＭコマンドによりＡＢＦラップにデータを書き込む際には、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれるものとする。
【００２５】
まず、１番目から３番目までのＷｒｉｔｅコマンドを受けると、１番目から３番目までのデータ要素がバッファに書き込まれる。尚、図２では、この３つのデータ要素をまとめて「Ｄ１」と表示している。その後、ＷｒｉｔｅＦＭコマンドにより、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれる。この場合は、セグメントＳ１内のデータＤ１がＡＢＦラップに書き込まれる。
【００２６】
以下、同様に、４番目から６番目までのＷｒｉｔｅコマンドにより、４番目から６番目までのデータＤ２がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ１及びＳ２内のデータセットがＡＢＦラップに書き込まれる。
また、７番目から９番目までのＷｒｉｔｅコマンドにより、７番目から９番目までのデータＤ３がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２内のデータセットがＡＢＦラップに書き込まれる。
更に、１０番目から１２番目までのＷｒｉｔｅコマンドにより、１０番目から１２番目までのデータＤ４がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２及びＳ３内のデータセットがＡＢＦラップに書き込まれる。
尚、本実施の形態では、各セグメントの一定割合の領域を、リライト中にホスト２０から受けたデータを格納するためのリザーブ領域としている。図２〜４では、バッファ１２の右側の隙間により、このリザーブ領域を表している。
【００２７】
その後、バッファ１２から通常ラップへのリライトが行われる。
図３は、セグメントＳ１内のデータセットが通常ラップにリライトされている際に、ホスト２０からＷｒｉｔｅコマンド及びＷｒｉｔｅＦＭコマンドが送られたときの状態を示している。
この場合、ホスト２０から送られたデータは、リライトのためにアクセスされていないセグメントＳ２のリザーブ領域に格納されている(灰色部分)。
【００２８】
図４は、セグメントＳ２及びＳ３内のデータセットがリライトされる際の状態を示している。
まず、セグメントＳ２内のデータセットは、図示するように、通常ラップのセグメントＳ１の隣に書き込まれている。その際、リライト中に書き込まれたデータ(セグメントＳ２の灰色部分)も、通常ラップに書き込まれる(通常ラップの灰色部分)。
また、セグメントＳ３内のデータセットも、通常ラップのその隣に書き込まれている。
そして、本実施の形態では、リライト中に書き込まれたデータ(セグメントＳ２の灰色部分)を、次にＡＢＦラップに書き込まれるセグメントにコピーしている(セグメントＳ４の灰色部分)。このように、リライト中にリザーブ領域に書かれたデータを、これからＲＡＢＦが行われるセグメントにコピーすることにより、そのデータは、通常のＲＡＢＦの手順に従い、通常ラップに再度書き込まれることになる。
【００２９】
尚、図２〜４では、各セグメント内部の具体的なデータ構造について示していないが、例えば、図５に示すようなデータ構造を前提としている。
即ち、テープ１４ａに記録されるデータとしては、ユーザデータにその誤り訂正のためのＣ１パリティとＣ２パリティが付加された積符号データブロックが採用される。ここで、Ｃ１パリティとは、ユーザデータの行方向の誤りを訂正するために用いられるパリティ符号であり、例えば、図示するように、偶数番目のバイトからなるデータに対するパリティ符号と、奇数番目のバイトからなるデータに対するパリティ符号とを含むものであってもよい。また、Ｃ２パリティとは、ユーザデータの列方向の誤りを訂正するために用いられるパリティ符号である。
【００３０】
このうち、各セグメントには、図５のユーザデータの部分(４６８バイト×５４バイト)が格納される。尚、図２〜４では、各セグメントにおけるリザーブ領域をバッファ１２の右側の隙間で表しているが、これは、リザーブ領域の存在を分かり易くするためであり、実際には、例えば、図５の網掛けの部分がリザーブ領域に相当する。
【００３１】
次に、図６〜８を参照して、本実施の形態におけるテープドライブ１０の動作を説明する。尚、本実施の形態では、リライト中でないときのバッファ１２内のデータの書き込み位置を第１のバッファポインタで指し、リライト中におけるバッファ１２内のデータの書き込み位置を第２のバッファポインタで指すものとする。
【００３２】
まず、ホスト２０からＷｒｉｔｅコマンドを受けたときのコントローラ１６の動作について説明する。
図６は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅコマンドを受け取る(ステップ１０１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１０２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００３３】
その結果、リライト中でないと判定された場合、コントローラ１６は、バッファ１２内の第１のバッファポインタが指す位置にデータを書き込む(ステップ１０３)。そして、現在のセグメントに予め定めた量のデータが書き込まれたかどうかを判定する(ステップ１０４)。ここで、予め定めた量のデータが書き込まれたと判定されれば、「ＥｎｄＭａｒｋｅｒ」を書き込み、第１のバッファポインタを次のセグメントの先頭に進める(ステップ１０５)。また、予め定めた量のデータが書き込まれていないと判定された場合は、第１のバッファポインタを、書き込んだデータの分だけ進める(ステップ１０９)。
【００３４】
一方、ステップ１０２でリライト中と判定された場合、コントローラ１６は、バッファ１２内の第２のバッファポインタが指す位置(リザーブ領域内の位置)にデータを書き込む(ステップ１０６)。そして、セグメントの最後までデータが書き込まれたかどうかを判定する(ステップ１０７)。ここで、最後まで書き込まれたと判定されれば、第２のバッファポインタを次のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１０８)。また、最後まで書き込まれていないと判定されれば、第２のバッファポインタを、書き込んだデータの分だけ進める(ステップ１０９)。
【００３５】
次に、ホスト２０からＷｒｉｔｅＦＭコマンドを受けたときのコントローラ１６の動作について説明する。
図７は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅＦＭコマンドを受け取る(ステップ１１１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１１２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００３６】
その結果、リライト中でないと判定された場合、コントローラ１６は、まず、第１のバッファポインタの位置に「ＦｉｌｅＭａｒｋ」を、コマンドで指定された個数(０個を含む)書き込む(ステップ１１３)。次に、新たにバッファ１２に書き込まれたデータと「ＦｉｌｅＭａｒｋ」とをＡＢＦラップに書き込む(ステップ１１４)。そして、最後に、テープ１４ａに対する書き込みが完了した旨のステータスをホスト２０に返す(ステップ１１５)。
【００３７】
一方、リライト中であると判定された場合、コントローラ１６は、まず、第２のバッファポインタの位置に「ＦｉｌｅＭａｒｋ」を、コマンドで指定された個数(０個を含む)書き込む(ステップ１１６)。次に、「ＦｉｌｅＭａｒｋ」が書き込まれたデータセットがリライトされるのを待つ(ステップ１１７)。そして、最後に、リライト結果に基づいてホスト２０にステータスを返す(ステップ１１８)。
【００３８】
また、このようにＡＢＦラップに書き込まれたデータセットは、その後の所定のタイミングで通常ラップにリライトされる。
図８は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、リライトをすべき旨の指示を受ける(ステップ１２１)。このリライトすべき旨の指示は、例えば、バッファ１２に空き容量がなくなった場合や、ＡＢＦラップを使い切った場合になされる。前者の場合は、バッファ１２の空き容量を監視する手段から指示を受ける。また、後者の場合は、ＡＢＦラップの使用状況を監視する手段から指示を受ける。
【００３９】
リライトの指示を受けると、コントローラ１６は、１番目のセグメント(図２〜４のセグメントＳ１)内のデータセットのリライトの準備をする(ステップ１２２)。ここで、先に述べたように、ホスト２０から送られたデータには、誤り訂正を行うためのパリティ符号を付加してテープ１４ａに記録するので、リライトの準備としては、そのようなパリティ符号の計算等がある。
また、リライト中のセグメントにはホスト２０から送られたデータを書き込むことはできないので、リライト中のデータの書込み位置を指す第２のバッファポインタを、２番目のセグメント(図２〜４のセグメントＳ２)の「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１２３)。尚、図２〜４の例では、この状態でホスト２０からデータが送られ、図６のステップ１０６で、セグメントＳ２のリザーブ領域に書き込まれている。
【００４０】
次いで、コントローラ１６は、次のデータセット、即ち、３番目のセグメント内のデータセットが存在するかどうかを判定する(ステップ１２４)。
その結果、３番目のセグメント内のデータセットが存在すると判定された場合は、リライトの準備ができた１番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、２番目のセグメント内のデータセットのリライトの準備をする(ステップ１２５)。そして、第２のバッファポインタを、３番目のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める(ステップ１２６)。図２〜４の例では、セグメントＳ３にデータが存在するので、セグメントＳ１内のデータを通常ラップに書き込み、セグメントＳ２内のデータのリライトの準備をし、第２のバッファポインタをセグメントＳ３の「ＥｎｄＭａｒｋｅｒ」の直後に進めている。
【００４１】
以下、同様に、(Ｎ＋２)番目のセグメント内にデータが存在すれば、Ｎ番目のセグメント内のデータを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータのリライトの準備をし、第２のバッファポインタを(Ｎ＋２)番目のセグメントの「ＥｎｄＭａｒｋｅｒ」の直後に進める、という処理を繰り返す(Ｎ＝２，３，…)。
【００４２】
一方、(Ｎ＋２)番目のセグメント内にデータセットが存在しないと判定された場合は、Ｎ番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータセットのリライトの準備をし、そして、この(Ｎ＋１)番目のセグメント内のデータセットも通常ラップに書き込む(ステップ１２７)。図２〜４の例の場合、セグメントＳ４内にデータが存在しないので、セグメントＳ２内のデータを通常ラップに書き込んだ後、セグメントＳ３内のデータも通常ラップに書き込んでいる。
【００４３】
その後、このリライト中にホスト２０から送られリザーブ領域に格納されたデータが存在すれば、それらを順次、次のセグメント、即ち、リライト対象となった最後のセグメントの次のセグメントにコピーする(ステップ１２８)。そして、第１のバッファポインタをそのコピーしたデータの直後に進める(ステップ１２９)。図２〜４の例の場合、セグメントＳ２のリザーブ領域に格納されたデータを、セグメントＳ４にコピーしている。
以上により、本実施の形態におけるデータの記録の動作は終了する。
【００４４】
即ち、本実施の形態では、同期要求があった場合にリライト中でなければ、データをＡＢＦラップに書き込んで同期応答を返し、その後、通常ラップにも書き込むようにしている。また、同期要求があった場合にリライト中であれば、送られたデータをリライト中のデータと合わせて通常ラップに書き込んで同期応答を返し、その後、通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込んでいる。
【００４５】
このように、本実施の形態において、ホスト２０から同期要求があった場合、テープ１４ａへの書込みが成功したかどうかは、ホスト２０に報告されるようになっている。
一方、リライトが成功したかどうかは、コントローラ１６は認識しているものの、ＳＣＳＩの仕様により、すぐにはホスト２０に送信されないようになっている。例えば、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来れば、その応答としてリライトの失敗を報告することはできる。しかしながら、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来ないことも考えられる。このような場合、ホスト２０としては、データがその本来記録されるべき通常ラップに書かれたと認識しているにもかかわらず、実際には、通常ラップにデータが正常に記録されていないという事態が生ずる。そこで、このような正常に記録されていないデータの読出し要求があった場合、テープドライブ１０は、本来記録されるべき場所からデータを読み出す代わりに、他の場所に記録されたデータを読み出してホスト２０に返すというリカバリ処理を行う必要がある。
【００４６】
以下、このリカバリ処理を含むＲｅａｄ処理について説明する。
ここでは、テープ１４ａ上に、図９に示すような形式でデータが記録されているものとして説明を行う。尚、データセットＺ及びＥには、既存のアルゴリズムにより、次のデータセットからＲＡＢＦが行われることを示すフラグがセットされているものとする。また、データセットＥには、既存のアルゴリズムにより、リライト単位の最後であることを示すフラグがセットされているものとする。
【００４７】
図１０は、この場合のＲｅａｄ処理の動作を示したフローチャートである。
まず、コントローラ１６は、ホスト２０からＲｅａｄコマンドを受け取る(ステップ１３１)。これにより、コントローラ１６は、記録チャネル１３を介してテープ１４ａから通常のデータの読出しを行う(ステップ１３２)。尚、その際、データセットＢ及びＤの灰色部分のデータは、あくまで同期のために書かれたデータであるので、「ＥｎｄＭａｒｋｅｒ」を検出することで自動的に読み飛ばされるようになっている。
その後、コントローラ１６は、データの読出しに成功したかどうかを判定し(ステップ１３３)、成功していれば、そのまま処理を終了する。
一方、データの読出しに成功していなければ、読出しに失敗したデータセットの種類を判別する(ステップ１３４)。
【００４８】
ここで判別されるデータセットの種類としては、第一に、図９のデータセットＡ〜Ｅのように、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(Ｆの灰色部分)を含まないデータセットがある。このようなデータセットについては、リライトが行われていないときに同期されたデータについて、既存のアルゴリズムによりリカバリを行う(ステップ１３５)。つまり、図９のデータセットＡ〜Ｅの斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。
【００４９】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１３６)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１３７)。つまり、図９のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図９のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００５０】
また、ステップ１３４で判別されるデータセットの種類としては、第二に、図９のデータセットＦのように、リライト中の同期後に通常のＲＡＢＦにより書き込まれたデータ(灰色部分)を含むデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１３８)。つまり、図９のデータセットＦの灰色部分及び斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。そして、特に、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(灰色部分)について、リカバリが成功したかどうかを判定する(ステップ１３９)。その結果、リカバリが成功していれば、そのまま処理を終了し、リカバリが成功していなければ、１つ前のリライト単位のデータを用いてリカバリを行う(ステップ１４０)。つまり、図９のデータセットＦの１番左の灰色部分のデータの読出しに失敗したのであれば、データセットＢの灰色部分のデータを読み出して送信し、図９のデータセットＦのその右隣の灰色部分のデータの読出しに失敗したのであれば、データセットＤの灰色部分のデータを読み出して送信する。
以上により、本実施の形態の動作は終了する。
【００５１】
尚、本実施の形態では、Ｎ番目のセグメント内のデータセットをリライトしている間に、(Ｎ＋１)番目のセグメントについてリライトの準備をし、(Ｎ＋２)番目のセグメントのリザーブ領域にホストからのデータを受け入れるようにしたが、このような形態には限られない。即ち、リライト中にホストから受け付けたデータを格納するセグメントは、リライトのために現にアクセスされているセグメント以外のセグメントで、そのうち今回のリライトのためにアクセスされるセグメントであれば、どの位置にあるセグメントでもよい。
また、本実施の形態では、リライト中に受け付けたデータを、リライト対象のセグメントのリザーブ領域に格納して通常ラップに書き込んだ後、現時点ではリライト対象ではないセグメントにコピーするようにした。しかしながら、リライト中に受け付けたデータを、その時点で、リライト対象のセグメントのリザーブ領域とリライト対象ではないセグメントの両方に格納する構成を採用することも考えられる。
【００５２】
このように、本実施の形態では、リライト中に同期要求が来た場合に、その同期要求に係るデータを各セグメント内のリザーブ領域に格納した後、リライトを行っているデータと合わせてテープに書き込むようにした。これにより、ＲＡＢＦにおけるパフォーマンスを更に向上することができる。
【００５３】
(第２の実施の形態)
図１１〜１３は、ホスト２０から送られたデータが一時記録領域に書き込まれ、その後、所定のタイミングで通常の記録領域にリライトされる様子を示した図である。
これらの図においても、中央左寄りに縦長の矩形でバッファ１２が示されている。バッファ１２を構成するセグメントの数は、特に限定されるものではないが、ここでも８個とし、上から順に「Ｓ１」、「Ｓ２」、「Ｓ３」、「Ｓ４」、「Ｓ５」、「Ｓ６」、「Ｓ７」、「Ｓ８」とする。
また、図２〜４と同様、上側の帯が、データが本来記録されるべき通常の記録領域(通常ラップ)を表し、下側の帯が、テープ１４ａを走行させたままデータを記録するのに用いられる一時記録領域(ＡＢＦラップ)を表している。
【００５４】
図１１は、ホスト２０からのＷｒｉｔｅコマンドによりデータがバッファ１２に蓄積され、ホスト２０からのＷｒｉｔｅＦＭコマンドによりデータがバッファ１２からＡＢＦラップへ書き込まれる際の状況を示す。
尚、ここでも、１つのＷｒｉｔｅコマンドにより、１つのデータ要素(斜線を施した最小の単位)がバッファ１２に書き込まれるものとする。また、図示するように、ホスト２０は、３つのＷｒｉｔｅコマンドを送った後、１つのＷｒｉｔｅＦＭコマンドを送るものとする。そして、このＷｒｉｔｅＦＭコマンドによりＡＢＦラップにデータを書き込む際には、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれるものとする。
【００５５】
まず、１番目から３番目までのＷｒｉｔｅコマンドを受けると、１番目から３番目までのデータ要素がバッファに書き込まれる。尚、図１１でも、この３つのデータ要素をまとめて「Ｄ１」と表示している。その後、ＷｒｉｔｅＦＭコマンドにより、前回のＡＢＦラップへの書込み以降にデータが蓄積されたセグメント内の全てのデータがＡＢＦラップに書き込まれる。この場合は、セグメントＳ１内のデータＤ１がＡＢＦラップに書き込まれる。
【００５６】
以下、同様に、４番目から６番目までのＷｒｉｔｅコマンドにより、４番目から６番目までのデータＤ２がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ１及びＳ２内のデータセットがＡＢＦラップに書き込まれる。
また、７番目から９番目までのＷｒｉｔｅコマンドにより、７番目から９番目までのデータＤ３がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２内のデータセットがＡＢＦラップに書き込まれる。
更に、１０番目から１２番目までのＷｒｉｔｅコマンドにより、１０番目から１２番目までのデータＤ４がバッファ１２に書き込まれ、ＷｒｉｔｅＦＭコマンドにより、セグメントＳ２及びＳ３内のデータセットがＡＢＦラップに書き込まれる。
尚、本実施の形態では、バッファ１２を構成する複数のセグメントの一部を、リライト中にホスト２０から受けたデータを格納するためのリザーブセグメントとしている。具体的には、セグメントＳ７及びＳ８をリザーブセグメントとして確保している(図１１〜１３の網掛け部分)。
【００５７】
その後、バッファ１２から通常ラップへのリライトが行われる。
図１２は、セグメントＳ１内のデータセットが通常ラップにリライトされている際に、ホスト２０からＷｒｉｔｅコマンド及びＷｒｉｔｅＦＭコマンドが送られたときの状態を示している。
この場合、ホスト２０から送られたデータは、リザーブセグメントＳ７に格納されている(灰色部分)。
【００５８】
図１３は、セグメントＳ２及びＳ３内のデータセットがリライトされる際の状態を示している。
まず、セグメントＳ２内のデータセットは、図示するように、通常ラップのセグメントＳ１の隣に書き込まれている。
次いで、リザーブセグメントであるセグメントＳ７内のデータセット(セグメントＳ７の灰色部分)が、その隣に書き込まれている(通常ラップの灰色部分)。バッファ１２の上から順にリライトが行われるのであれば、このような順序の逆転は生じないが、本実施の形態では、リライトの準備が整ったものからリライトするようにしているので、リザーブセグメント内のデータセットが先にリライトされることも起こり得るようになっている。
その後、セグメントＳ３内のデータセットが、通常ラップのセグメントＳ７の隣に書き込まれている。
そして、本実施の形態では、リライト中に書き込まれたデータ(セグメントＳ７の灰色部分)を、次にＡＢＦラップに書き込まれるセグメントにコピーしている(セグメントＳ４の灰色部分)。このように、リライト中にリザーブ領域に書かれたデータを、これからＲＡＢＦが行われるセグメントにコピーすることにより、そのデータは、通常のＲＡＢＦの手順に従い、通常ラップに再度書き込まれることになる。
【００５９】
次に、図１４及び１５を参照して、本実施の形態におけるテープドライブ１０の動作を説明する。尚、本実施の形態では、リライト中でないときのデータの書き込み位置も、リライト中におけるデータの書き込み位置も同じバッファポインタで指すものとする。
まず、ホスト２０からＷｒｉｔｅコマンドを受けたときのコントローラ１６の動作について説明する。
図１４は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、インタフェース１１からＷｒｉｔｅコマンドを受け取る(ステップ１４１)。そして、バッファ１２から記録チャネル１３へリライトのためのデータ転送が行われているかどうかを判定する(ステップ１４２)。尚、ここでの判定は、例えば、コントローラ１６が参照可能なメモリにリライト中かどうかのフラグを保持しておくことで実現できる。
【００６０】
その結果、リライト中でないと判定された場合、コントローラ１６は、バッファ１２内のバッファポインタが指す位置にデータを書き込む(ステップ１４３)。そして、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。
一方、リライト中と判定された場合、コントローラ１６は、バッファ１２内のバッファポインタが指す位置(リザーブセグメント内の位置)にデータを書き込む(ステップ１４５)。そして、セグメントの最後までデータが書き込まれたかどうかを判定する(ステップ１４６)。ここで、最後まで書き込まれていないと判定されれば、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。また、最後まで書き込まれたと判定されれば、このリザーブセグメントにリライト可能(リライトされるデータセットと合わせて書き込むことが可能)の印を付け(ステップ１４７)、バッファポインタを、書き込んだデータの分だけ進める(ステップ１４４)。
【００６１】
次に、ホスト２０からＷｒｉｔｅＦＭコマンドを受けると、コントローラ１６は、リライト中でなければ、バッファ１２内のデータをＡＢＦラップに書き込み、ホスト２０にステータスを返す。一方、リライト中であれば、ホスト２０から受け取ったデータが通常ラップにリライトされるのを待ち、リライトのステータスをホスト２０に返す。尚、この動作は、図７と同様であるので、詳細な説明は省略する。但し、本実施の形態では、「ＦｉｌｅＭａｒｋ」をバッファ１２にコマンドで指定された個数(０個を含む)書き込んだ後、そのセグメントに最後までデータが書かれていなくても、リライトされるデータに混ぜて書き出す必要がある。そこで、図７のステップ１１７において、途中まで書かれていたセグメントに、ステップ１４７で付けたのと同様の印を付ける処理も行う。
【００６２】
また、このようにＡＢＦラップに書き込まれたデータセットは、その後の所定のタイミングで通常ラップにリライトされる。
図１５は、そのときのコントローラ１６の動作を示したフローチャートである。
まず、コントローラ１６は、リライトをすべき旨の指示を受ける(ステップ１５１)。このリライトすべき旨の指示は、例えば、バッファ１２に空き容量がなくなった場合や、ＡＢＦラップを使い切った場合になされる。前者の場合は、バッファ１２の空き容量を監視する手段から指示を受ける。また、後者の場合は、ＡＢＦラップの使用状況を監視する手段から指示を受ける。
【００６３】
リライトの指示を受けると、コントローラ１６は、バッファポインタをリザーブセグメント(図１１〜１３のセグメントＳ７)の先頭に切り換える(ステップ１５２)。本実施の形態において、バッファポインタは、通常のセグメントとリザーブセグメントに共通に用いているためである。
また、コントローラ１６は、１番目のセグメント(図１１〜１３のセグメントＳ１)内のデータセットのリライトの準備をする(ステップ１５３)。ここで、先に述べたように、ホスト２０から送られたデータには、誤り訂正を行うためのパリティ符号を付加してテープ１４ａに記録するので、リライトの準備としては、そのようなパリティ符号の計算等がある。
【００６４】
次いで、コントローラ１６は、次のデータセット、即ち、２番目のセグメント内のデータセットが存在するかどうかを判定する(ステップ１５４)。尚、この判定の対象となるセグメントには、リザーブセグメントも含まれる。
その結果、２番目のセグメント内のデータセットが存在すると判定された場合は、リライトの準備ができた１番目のセグメント内のデータセットを通常ラップに書き込み、それと並行して、２番目のセグメント内のデータセットのリライトの準備をする(ステップ１５５)。
そして、現在バッファポインタが位置づけられているリザーブセグメントがリライト可能かどうかを、ステップ１４７で付けられた印に基づいて判定する(ステップ１５６)。ここで、リザーブセグメントがリライト可能でなければ、そのまま処理はステップ１５４に進む。また、リザーブセグメントがリライト可能であれば、バッファポインタを次のリザーブセグメント(図１１〜１３のセグメントＳ８)の先頭に進め(ステップ１５７)、処理は１５４に進む。図１１〜１３の例では、セグメントＳ２にデータが存在するので、セグメントＳ１内のデータを通常ラップに書き込み、セグメントＳ２内のデータのリライトの準備をしている。
【００６５】
以下、同様に、(Ｎ＋１)番目のセグメント内にデータが存在すれば、Ｎ番目のセグメント内のデータを通常ラップに書き込み、それと並行して、(Ｎ＋１)番目のセグメント内のデータのリライトの準備をし、リザーブセグメントがリライト可能になっていれば、バッファポインタを次のリザーブセグメントの先頭に進める、という処理を繰り返す(Ｎ＝２，３，…)。図１１〜１４の例では、この時点でセグメントＳ７がリライト可能になっているとし、これを３番目のセグメントとしている。そして、セグメントＳ２内のデータを通常ラップに書き込み、セグメントＳ７内のデータのリライトの準備をしている(Ｎ＝２の場合)。また、４番目のセグメントとなるセグメントＳ３にデータが存在するので、セグメントＳ７内のデータを通常ラップに書き込み、セグメントＳ３内のデータのリライトの準備をしている(Ｎ＝３の場合)。
【００６６】
一方、(Ｎ＋１)番目のセグメント内にデータセットが存在しないと判定された場合は、Ｎ番目のセグメント内のデータセットを通常ラップに書き込む(ステップ１５８)。図１１〜１３の例の場合、セグメントＳ４内にデータが存在しないので、セグメントＳ３内のデータを通常ラップに書き込んでいる。
【００６７】
その後、このリライト中にホスト２０から送られリザーブセグメントに格納されたデータが存在すれば、それらを順次、リライト対象となった最後のセグメント(リザーブセグメントを除く)の次のセグメントにコピーする(ステップ１５９)。そして、バッファポインタをそのコピーしたデータの直後に進める(ステップ１６０)。図１１〜１３の例の場合、セグメントＳ７に格納されたデータを、セグメントＳ４にコピーしている。
以上により、本実施の形態におけるデータの記録の動作は終了する。
【００６８】
即ち、本実施の形態でも、同期要求があった場合にリライト中でなければ、データをＡＢＦラップに書き込んで同期応答を返し、その後、通常ラップにも書き込むようにしている。また、同期要求があった場合にリライト中であれば、送られたデータをリライト中のデータと合わせて通常ラップに書き込んで同期応答を返し、その後、通常のＲＡＢＦの手順に従い、ＡＢＦラップに書き込んだ後、通常ラップに書き込んでいる。
【００６９】
このように、本実施の形態において、ホスト２０から同期要求があった場合、テープ１４ａへの書込みが成功したかどうかは、ホスト２０に報告されるようになっている。
一方、リライトが成功したかどうかは、コントローラ１６は認識しているものの、ＳＣＳＩの仕様により、すぐにはホスト２０に送信されないようになっている。例えば、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来れば、その応答としてリライトの失敗を報告することはできる。しかしながら、リライトの失敗後にホスト２０からＷｒｉｔｅコマンドやＷｒｉｔｅＦＭコマンドが来ないことも考えられる。このような場合、ホスト２０としては、データがその本来記録されるべき通常ラップに書かれたと認識しているにもかかわらず、実際には、通常ラップにデータが正常に記録されていないという事態が生ずる。そこで、このような正常に記録されていないデータの読出し要求があった場合、テープドライブ１０は、本来記録されるべき場所からデータを読み出す代わりに、他の場所に記録されたデータを読み出してホスト２０に返すというリカバリ処理を行う必要がある。
【００７０】
以下、このリカバリ処理を含むＲｅａｄ処理について説明する。
ここでは、テープ１４ａ上に、図１６に示すような形式でデータが記録されているものとして説明を行う。尚、各データセットには、データセット番号及びライトパス番号が付加されているものとする。ここで、データセット番号とは、書かれた順(読み出す順)を示す連続値である。その際、リライト中の同期で書かれたデータセットが読み飛ばされるよう、同期で書かれたデータセットと通常のデータセットとには同じデータセット番号を振っておき、ライトパス番号で区別するようにする。また、データセットＢ及びＤには、リライト中の同期で書かれたデータセットであることを示すフラグがセットされているものとする。
【００７１】
図１７は、この場合のＲｅａｄ処理の動作を示したフローチャートである。
まず、コントローラ１６は、ホスト２０からＲｅａｄコマンドを受け取る(ステップ１６１)。これにより、コントローラ１６は、記録チャネル１３を介して磁気テープから通常のデータの読出しを行う(ステップ１６２)。尚、その際、データセットＢ及びＤは、あくまで同期のために書かれたデータセットであるので、通常は、データセット番号及びライトパス番号を参照することで自動的に読み飛ばされるようになっている。
その後、コントローラ１６は、データの読出しに成功したかどうかを判定し(ステップ１６３)、成功していれば、そのまま処理は終了する。
一方、データの読出しに成功していなければ、読出しに失敗したデータセットの種類を判別する(ステップ１６４)。
【００７２】
ここで判別されるデータセットの種類としては、第一に、図１６のデータセットＡのように、リライト中の同期で書かれたデータセットの直後のデータセット以外のデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１６６)。
【００７３】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１６７)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１６８)。つまり、図１６のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図１６のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００７４】
また、ステップ１６４で判別されるデータセットの種類としては、第二に、図１６のデータセットＣ、Ｅのように、リライト中の同期で書かれたデータセットの直後のデータセットがある。この場合、直前のデータセットＢ、Ｄは、上述したように、通常は、読み飛ばされるのであるが、データセットＣ、Ｅの読出しに失敗したことにより、データセットＢ、ＤをデータセットＣ、Ｅであると誤認してしまうことが考えられる。そこで、コントローラ１６は、リライト中の同期で書かれたデータセットであることを示すフラグを参照して、直前のデータセットが目的のデータセットではないことを判別する(ステップ１６５)。そして、データセットＣ、Ｅについて、既存のアルゴリズムによりリカバリを行う(ステップ１６６)。
【００７５】
その後、ホスト２０に送るべき全てのデータの送信が完了しかたどうかを判定する(ステップ１６７)。その結果、送るべき全てのデータの送信が完了していると判定されれば、そのまま処理を終了する。一方、送るべき全てのデータの送信が完了していないと判定されれば、リライト中の同期要求により通常ラップに書き込まれたデータのリカバリを行う(ステップ１６８)。つまり、図１６のデータセットＢ及びＤの灰色部分のデータを読み出してホスト２０に送信する。テープドライブ１０は、図１６のデータセットＢ及びＤの灰色部分のデータについて、通常ラップに書き込むことで同期が成功した旨をホスト２０に返しているため、ホスト２０からの読出し要求に対し、これらのデータも読み出して返す必要があるからである。
【００７６】
更に、ステップ１６４で判別されるデータセットの種類としては、第三に、図１６のデータセットＦのように、リライト中の同期後に通常のＲＡＢＦにより書き込まれたデータ(灰色部分)を含むデータセットがある。このようなデータセットについては、既存のアルゴリズムによりリカバリを行う(ステップ１６９)。つまり、図１６のデータセットＦの灰色部分及び斜線部分のデータをＡＢＦラップから読み出してホスト２０に送信する。そして、特に、リライト中の同期後の通常のＲＡＢＦにより書き込まれたデータ(灰色部分)について、リカバリが成功したかどうかを判定する(ステップ１７０)。その結果、リカバリが成功していれば、そのまま処理を終了し、リカバリが成功していなければ、１つ前のリライト単位のデータを用いてリカバリを行う(ステップ１７１)。つまり、図１６のデータセットＦの１番左の灰色部分のデータの読出しに失敗したのであれば、データセットＢの灰色部分のデータを読み出して送信し、図１６のデータセットＦのその右隣の灰色部分のデータの読出しに失敗したのであれば、データセットＤの灰色部分のデータを読み出して送信する。
以上により、本実施の形態の動作は終了する。
【００７７】
尚、本実施の形態では、リライト中に受け付けたデータを、リザーブセグメントに格納して通常ラップに書き込んだ後、現時点ではリライト対象ではないセグメントにコピーするようにした。しかしながら、リライト中に受け付けたデータを、その時点で、リザーブセグメントとリライト対象ではないセグメントの両方に格納する構成を採用することも考えられる。
【００７８】
このように、本実施の形態では、リライト中に同期要求が来た場合に、その同期要求に係るデータをリザーブセグメントに格納した後、リライトを行っているデータと合わせてテープに書き込むようにした。これにより、ＲＡＢＦにおけるパフォーマンスを更に向上することができる。
【００７９】
尚、同期要求がホストから送られる間隔が長い場合は、リライト中に同期要求が送られる確率も低くなる。従って、本実施の形態は、同期要求の間隔が短い場合において特に有効である。
また、データの読出しの際のレートは、同期のために記録されたデータが読み出されない分、通常の方式で記録した場合よりも悪くなる。例えば、先に述べた、４００ＫＢのうちの５０ＫＢをリザーブ領域として確保する場合であれば、通常の方式で記録した場合のレートが約４０ＭＢ/ｓとすると、本実施の形態の方式を用いた場合、約３５ＭＢ/ｓとなってしまう。従って、本実施の形態は、書込みが読出しよりも多い場合、即ち、データの重要度が高い場合に、特に有効と言える。このようなものとして、例えば、一般的なＢａｃｋｕｐ/Ｒｅｓｔｏｒｅアプリケーションが想定できる。このようなアプリケーションにおいては、通常、バックアップのみが行われ、リストアはまれにしか行われないため、読出しのパフォーマンスの低下はあまり問題とならない。
【００８０】
同じ理由で、カートリッジの容量が減ることになる。しかしながら、現在の製品の使われ方をみると、同期を頻繁に要求するアプリケーションは、従来からの所謂大型機をホストとするものが大半であり、これらのアプリケーションは、カートリッジの容量を使い切らずに、次のカートリッジを利用することが多い。このため、本実施の形態では、カートリッジ容量の減少は問題にはならない。
また、同期の頻度が低い場合にはＲＡＢＦが起動されないので、パフォーマンスの低下やカートリッジ容量の減少は、必ず起こるというものでもない。
【００８１】
このように、本発明では、書込みの際のパフォーマンスが向上する代わりに、キャパシティのロスが発生する可能性がある。
しかしながら、これに対しては、データセットサイズを可変長とする技術(１/Ｎを単位としてデータセットサイズをその１〜Ｎ倍にできる技術)を用いることで、問題を大幅に緩和できる。
【００８２】
具体的には、次のような手法を採用することができる。
第１の実施の形態では、例えば、各セグメントの１/Ｎをリザーブ領域とする。そして、リライト中の同期によるデータの追加が生じなかったデータセットは、(Ｎ−１)/Ｎのサイズとし、リライト中の同期によるデータの追加が生じたデータセットは、Ｎ/Ｎのサイズとする。これにより、キャパシティの減少や、読出し時のデータレートの低下を緩和することができる。
また、第２の実施の形態では、挿入されるデータセット(リザーブセグメントに格納されていたデータセット)のサイズを、同期のためのデータのサイズよりも少し大きなサイズとすればよい。これにより、上記と同様、キャパシティの減少や、読出し時のデータレートの低下を緩和することができる。
【００８３】
尚、モデルによる性能評価を行ったので、以下に記す。
ここでは、セグメントサイズ(データセットサイズ)を４００ＫＢ、バッファ内のセグメント数を１０００、一度に同期するデータの量を４８ＫＢ〜３８４ＫＢとした。
第１の実施の形態の方式を用いた場合、リザーブ領域のサイズを５０ＫＢとすると、最大１２．５％のキャパシティロスはあったものの、従来のＲＡＢＦの１０３％〜１０７％のパフォーマンスが認められた。
また、第２の実施の形態の方式を用いた場合、２４％〜１７％のキャパシティロスはあったものの、従来のＲＡＢＦの１０２％〜１１３％のパフォーマンスが認められた。
【００８４】
ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。
また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム(装置又は機器)、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ(ＲＡＭ)、リードオンリーメモリ(ＲＯＭ)、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ(ＣＤ−ＲＯＭ)、コンパクトディスク−リード/ライト(ＣＤ−Ｒ/Ｗ)及びＤＶＤが含まれる。
【図面の簡単な説明】
【００８５】
【図１】本発明の実施の形態が適用されるテープドライブの構成を示したブロック図である。
【図２】本発明の第１の実施の形態におけるバッファからテープへの書込みの第１段階について説明するための図である。
【図３】本発明の第１の実施の形態におけるバッファからテープへの書込みの第２段階について説明するための図である。
【図４】本発明の第１の実施の形態におけるバッファからテープへの書込みの第３段階について説明するための図である。
【図５】本発明の実施の形態におけるデータセットの構造について説明するための図である。
【図６】本発明の第１の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅコマンド受付け時の動作を示したフローチャートである。
【図７】本発明の第１の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅＦＭコマンド受付け時の動作を示したフローチャートである。
【図８】本発明の第１の実施の形態におけるテープドライブのコントローラのリライト時の動作を示したフローチャートである。
【図９】本発明の第１の実施の形態におけるＲｅａｄ処理の説明に用いるテープ上のデータセットの配置例である。
【図１０】本発明の第１の実施の形態におけるテープドライブのコントローラのＲｅａｄ処理の動作を示したフローチャートである。
【図１１】本発明の第２の実施の形態におけるバッファからテープへの書込みの第１段階について説明するための図である。
【図１２】本発明の第２の実施の形態におけるバッファからテープへの書込みの第２段階について説明するための図である。
【図１３】本発明の第２の実施の形態におけるバッファからテープへの書込みの第３段階について説明するための図である。
【図１４】本発明の第２の実施の形態におけるテープドライブのコントローラのＷｒｉｔｅコマンド受付け時の動作を示したフローチャートである。
【図１５】本発明の第２の実施の形態におけるテープドライブのコントローラのリライト時の動作を示したフローチャートである。
【図１６】本発明の第２の実施の形態におけるＲｅａｄ処理の説明に用いるテープ上のデータセットの配置例である。
【図１７】本発明の第２の実施の形態におけるテープドライブのコントローラのＲｅａｄ処理の動作を示したフローチャートである。
【符号の説明】
【００８６】
１０…テープドライブ、１１…インタフェース、１２…バッファ、１３…記録チャネル、１４ａ…テープ、１４ｂ…ヘッド、１４ｃ，１４ｄ…リール、１４ｅ…カートリッジ、１５…モータ、１６…コントローラ、１７…ヘッド位置制御システム、１８…モータドライバ
【特許請求の範囲】
【請求項１】
テープ媒体にデータを書き込むための装置であって、
前記テープ媒体に書き込むべきデータを蓄積するバッファと、
前記バッファに蓄積されたデータの前記テープ媒体への書込みを制御し、当該書込みの間に受け取ったデータを、当該バッファ内の、現時点ではアクセスされていないが、そのうち当該書込みのためにアクセスされる領域に蓄積するコントローラと
を含む、装置。
【請求項２】
前記領域は、前記バッファを構成する複数のセグメントのうちの任意のセグメントの予めリザーブされた領域である、請求項１記載の装置。
【請求項３】
前記領域は、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントの任意の領域である、請求項１記載の装置。
【請求項４】
前記書込みは、前記テープ媒体を走行させたままデータを書き込むのに用いられる一時記録領域に前記バッファに蓄積されたデータを書き込んだ後になされる、通常の記録領域への書込みである、請求項１記載の装置。
【請求項５】
前記コントローラは、前記バッファに蓄積されたデータを前記一時記録領域に書き込んだ際に、書込みのステータスを出力する、請求項４記載の装置。
【請求項６】
前記コントローラは、前記書込みの間に受け取ったデータを、当該書込みのためにアクセスされない領域にコピーする、請求項１記載の装置。
【請求項７】
テープ媒体にデータを書き込むための装置であって、
前記テープ媒体に書き込むべきデータを蓄積するバッファと、
前記バッファに蓄積された第１のデータの前記テープ媒体上の一時記録領域への第１の書込みの後に、当該第１のデータの当該テープ媒体上の通常の記録領域への第２の書込みを制御し、当該第２の書込みの間に受け取った第２のデータを、当該第２の書込みの対象の一部として当該通常の記録領域に書き込むコントローラと
を含む、装置。
【請求項８】
前記一時記録領域は、前記テープ媒体を走行させたままデータを書き込むのに用いられる領域である、請求項７記載の装置。
【請求項９】
前記コントローラは、前記第２のデータを、前記バッファを構成する複数のセグメントのうちの所定のセグメントの予めリザーブされた領域を経由して、前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１０】
前記コントローラは、前記第２のデータを、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントを経由して、前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１１】
前記コントローラは、前記第１の書込みの後、かつ、前記第２の書込みの前の所定の時点で、当該第１の書込みのステータスを出力する、請求項７記載の装置。
【請求項１２】
前記コントローラは、前記第２の書込みの後に前記第２のデータを受け取った場合と同様の手順で、当該第２のデータを前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１３】
前記コントローラは、前記第２のデータの読出し要求に応じて、前記第２の書込みの対象の一部として前記通常の記録領域に書き込まれた当該第２のデータを読み出す、請求項７記載の装置。
【請求項１４】
テープ媒体にデータを書き込むための方法であって、
バッファに蓄積された第１のデータを前記テープ媒体上の一時記録領域に書き込み、
前記第１のデータを前記テープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、当該第２のデータを当該第１のデータと同じ記録単位に含めて当該通常の記録領域に書き込む、方法。
【請求項１５】
前記第２のデータは、前記バッファを構成する複数のセグメントのうちの所定のセグメントの予めリザーブされた領域を経由して、前記通常の記録領域に書き込まれる、請求項１４記載の方法。
【請求項１６】
前記第２のデータは、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントを経由して、前記通常の記録領域に書き込まれる、請求項１４記載の方法。
【請求項１７】
前記第１のデータを前記一時記録領域に書き込んだ際に、書込みのステータスを出力する、請求項１４記載の方法。
【請求項１８】
前記第１のデータの前記通常の記録領域への書込みの後に前記第２のデータを受け取った場合と同様の手順で、当該第２のデータを前記通常の記録領域に書き込む、請求項１４記載の方法。
【請求項１９】
前記第２のデータの読出し要求に応じて、前記第１のデータと同じ記録単位に含めて前記通常の記録領域に書き込まれた当該第２のデータを読み出す、請求項１４記載の方法。
【請求項２０】
テープ媒体へのデータの書込みを制御するためのコンピュータプログラムであって、コンピュータに、
バッファに蓄積された第１のデータの前記テープ媒体上の一時記録領域への書込みを制御する機能と、
前記第１のデータを前記テープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、当該第２のデータが当該第１のデータと同じ記録単位として当該通常の記録領域に書き込まれるよう制御する機能と
を実現させるためのコンピュータプログラム。
【請求項１】
テープ媒体にデータを書き込むための装置であって、
前記テープ媒体に書き込むべきデータを蓄積するバッファと、
前記バッファに蓄積されたデータの前記テープ媒体への書込みを制御し、当該書込みの間に受け取ったデータを、当該バッファ内の、現時点ではアクセスされていないが、そのうち当該書込みのためにアクセスされる領域に蓄積するコントローラと
を含む、装置。
【請求項２】
前記領域は、前記バッファを構成する複数のセグメントのうちの任意のセグメントの予めリザーブされた領域である、請求項１記載の装置。
【請求項３】
前記領域は、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントの任意の領域である、請求項１記載の装置。
【請求項４】
前記書込みは、前記テープ媒体を走行させたままデータを書き込むのに用いられる一時記録領域に前記バッファに蓄積されたデータを書き込んだ後になされる、通常の記録領域への書込みである、請求項１記載の装置。
【請求項５】
前記コントローラは、前記バッファに蓄積されたデータを前記一時記録領域に書き込んだ際に、書込みのステータスを出力する、請求項４記載の装置。
【請求項６】
前記コントローラは、前記書込みの間に受け取ったデータを、当該書込みのためにアクセスされない領域にコピーする、請求項１記載の装置。
【請求項７】
テープ媒体にデータを書き込むための装置であって、
前記テープ媒体に書き込むべきデータを蓄積するバッファと、
前記バッファに蓄積された第１のデータの前記テープ媒体上の一時記録領域への第１の書込みの後に、当該第１のデータの当該テープ媒体上の通常の記録領域への第２の書込みを制御し、当該第２の書込みの間に受け取った第２のデータを、当該第２の書込みの対象の一部として当該通常の記録領域に書き込むコントローラと
を含む、装置。
【請求項８】
前記一時記録領域は、前記テープ媒体を走行させたままデータを書き込むのに用いられる領域である、請求項７記載の装置。
【請求項９】
前記コントローラは、前記第２のデータを、前記バッファを構成する複数のセグメントのうちの所定のセグメントの予めリザーブされた領域を経由して、前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１０】
前記コントローラは、前記第２のデータを、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントを経由して、前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１１】
前記コントローラは、前記第１の書込みの後、かつ、前記第２の書込みの前の所定の時点で、当該第１の書込みのステータスを出力する、請求項７記載の装置。
【請求項１２】
前記コントローラは、前記第２の書込みの後に前記第２のデータを受け取った場合と同様の手順で、当該第２のデータを前記通常の記録領域に書き込む、請求項７記載の装置。
【請求項１３】
前記コントローラは、前記第２のデータの読出し要求に応じて、前記第２の書込みの対象の一部として前記通常の記録領域に書き込まれた当該第２のデータを読み出す、請求項７記載の装置。
【請求項１４】
テープ媒体にデータを書き込むための方法であって、
バッファに蓄積された第１のデータを前記テープ媒体上の一時記録領域に書き込み、
前記第１のデータを前記テープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、当該第２のデータを当該第１のデータと同じ記録単位に含めて当該通常の記録領域に書き込む、方法。
【請求項１５】
前記第２のデータは、前記バッファを構成する複数のセグメントのうちの所定のセグメントの予めリザーブされた領域を経由して、前記通常の記録領域に書き込まれる、請求項１４記載の方法。
【請求項１６】
前記第２のデータは、前記バッファを構成する複数のセグメントのうちの予めリザーブされたセグメントを経由して、前記通常の記録領域に書き込まれる、請求項１４記載の方法。
【請求項１７】
前記第１のデータを前記一時記録領域に書き込んだ際に、書込みのステータスを出力する、請求項１４記載の方法。
【請求項１８】
前記第１のデータの前記通常の記録領域への書込みの後に前記第２のデータを受け取った場合と同様の手順で、当該第２のデータを前記通常の記録領域に書き込む、請求項１４記載の方法。
【請求項１９】
前記第２のデータの読出し要求に応じて、前記第１のデータと同じ記録単位に含めて前記通常の記録領域に書き込まれた当該第２のデータを読み出す、請求項１４記載の方法。
【請求項２０】
テープ媒体へのデータの書込みを制御するためのコンピュータプログラムであって、コンピュータに、
バッファに蓄積された第１のデータの前記テープ媒体上の一時記録領域への書込みを制御する機能と、
前記第１のデータを前記テープ媒体上の通常の記録領域に書き込む際に第２のデータを受け取ると、当該第２のデータが当該第１のデータと同じ記録単位として当該通常の記録領域に書き込まれるよう制御する機能と
を実現させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２００７−７３１０８（Ｐ２００７−７３１０８Ａ）
【公開日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願番号】特願２００５−２５７３８８（Ｐ２００５−２５７３８８）
【出願日】平成１７年９月６日（２００５．９．６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１００１０４８８０
【弁理士】
【氏名又は名称】古部 次郎
【復代理人】
【識別番号】１００１１８２０１
【弁理士】
【氏名又は名称】千田 武
【復代理人】
【識別番号】１００１１８１０８
【弁理士】
【氏名又は名称】久保 洋之
【Ｆターム（参考）】
【公開日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願日】平成１７年９月６日（２００５．９．６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１００１０４８８０
【弁理士】
【氏名又は名称】古部 次郎
【復代理人】
【識別番号】１００１１８２０１
【弁理士】
【氏名又は名称】千田 武
【復代理人】
【識別番号】１００１１８１０８
【弁理士】
【氏名又は名称】久保 洋之
【Ｆターム（参考）】
[ Back to top ]