JP2008217860A - 一連の処理を所定の順序で行うための処理システム、ストレージ装置、及び方法 - Google Patents

Abstract

【課題】ハードウェア各ブロックの処理状況を少ない数のレジスタにより管理することが可能な技術を提供
【解決手段】処理システムは、処理システムに入力されるデータを入力順に処理単位でそれぞれ格納する複数のセグメントからなるバッファと、データに対し、一連の処理を所定の順序で施す複数の処理部と、複数の処理部にそれぞれ対応する複数の第１テーブルであって、対応する処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する前記処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する複数の第１テーブルと、複数の第１テーブルにより保持される一連の処理の処理状況に基づき、一連の処理が所定の順序で行われるようにバッファと複数の処理部の間のデータ転送を管理する管理部とを含む。
【選択図】 図３

Description

本発明はシステムに入力されるデータに対し、一連の処理を所定の順序で行う方法に関し、特にバッファを構成する複数セグメントにそれぞれ格納される単位データについて、一連の処理の処理状況を管理する技術に関する。

テープドライブ等のストレージ装置では、ホスト装置からの入力データを所定の単位で記憶媒体に記録するまでに、単位データに対しＩＤ情報やエラー訂正コードの付加等の多数の処理を行う。一連の処理はハードウェアにより所定の順序で行われ、ハードウェアの各ブロックは処理の作業領域として共通のバッファを使用する。バッファは複数の領域（以下、セグメントという）からなるリングバッファとして使用され、各セグメントには単位データが格納される。各ブロックは独立して動作するが、それ自体で次のセグメントに対する処理の開始時を判断できるよう、それぞれの処理状況がレジスタにより管理されブロック間で共有される。

一連の処理を所定の順序で行う処理システムにおいて、複数の処理回路と複数のメモリを含むメモリ部との間のデータ転送をステート情報に基づいて管理する従来技術として、例えば特許文献１がある。特許文献１は、複数の処理回路とメモリ部の複数のメモリとのデータ経路を、所定のステート情報に応じて切り替え、パイプラインステージ間のデータの受け渡しを行う技術を開示する。ステート情報としては、複数の処理回路のうち少なくとも一つの処理回路の処理状況より遷移する情報が用いられる。

特開２００５−７８１２０

特許文献１において、複数の処理回路とメモリ部の複数のメモリとのデータ経路は、ある処理回路が、その１つ前のパイプラインステージである処理回路が１クロック前にデータ読出しまたはデータ書込みを行ったメモリをアクセスするよう形成される。従って特許文献１が開示するステート情報は、処理回路に対し次に処理すべきデータを格納するメモリを示すといえるが、しかしこれは個々の単位データに対する各処理回路の処理状況を提供するものではない。

そこで従来技術において、セグメントの単位データごとに各ブロックの処理状況をレジスタにより管理する方法が提案されている。ここで１セグメントに対するレジスタのサイズは、例えばハードウェア各ブロックの処理の終了を１ビットのフラグにより表すとすると、ブロック数に等しいビット数である。一方単位データごとに処理状況を管理するために必要となるレジスタ数は、バッファのセグメント数に等しい。そのためストレージ装置とホスト装置のそれぞれの転送レートの差を吸収するのに必要なバッファのサイズが大きくなるとセグメント数が増加し、それに比例して処理状況を管理するのに必要なレジスタ数も増加する。動作中のレジスタ数の増加は消費電力の増加につながる。また、レジスタ数が増加すると回路全体に占めるレジスタ回路の割合も増加する。

そこで本発明は、バッファを用いて一連の処理を所定の順序で行う場合において、バッファの容量が大きくセグメント数が増加しても、セグメントに格納される単位データごとのハードウェア各ブロックの処理状況を少ない数のレジスタにより管理することが可能な、処理システム、ストレージ装置及び方法を提供することを目的とする。

上記目的を達成する本発明は、次のような処理システムによって実現される。この処理システムは、処理システムに入力されるデータを入力順に処理単位でそれぞれ格納する複数のセグメントからなるバッファと、データに対し、一連の処理を所定の順序で施す複数の処理部と、複数の処理部にそれぞれ対応する複数の第１テーブルであって、対応する処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する複数の第１テーブルと、複数の第１テーブルにより保持される一連の処理の処理状況に基づき、一連の処理が所定の順序で行われるようにバッファと複数の処理部の間のデータ転送を管理する管理部とを含む。

好ましくは、処理システムは、セグメントを指定した一連の処理の処理状況の問い合わせに応答して、複数の第１テーブルを参照して指定されたセグメントに対する処理状況を生成するステータス生成部を含む。そして管理部は、複数の処理部のそれぞれについて、次に処理対象となるセグメントを指定してステータス生成部に処理状況を問い合わせ、当該処理状況が処理部の処理の開始条件を満たすか否かを判断することにより、バッファと複数の処理部の間のデータ転送を管理する。

更に好ましくは、管理部は、次に処理対象となるセグメントに対する処理状況が、開始条件を判断する対象の処理部による処理が終了しておらず、かつ１つ前の処理部による処理が終了していることを示すこと条件に、開始条件を判断する対象の処理部へ上記セグメントの単位データを転送する。

また好ましくは、管理部は、各処理部による処理の終了に応答して対応する第１テーブルを更新する。そして上記処理システムは、任意の第１テーブルの先頭情報により示される先頭のセグメントと末尾情報により示される末尾のセグメントの間に、対応する処理部による処理が未処理のセグメントが存在することになるような更新を検知しエラー信号を生成するアクセス制御部を含む。

更に好ましくは、上記アクセス制御部は、任意の第１テーブルの更新の前後で先頭情報及び末尾情報が変化しないような更新を検知しエラー信号を生成する。

好ましくは、前記バッファはリングバッファであり、上記処理システムは制御部を含む。そして制御部は、リングバッファのすべてのセグメントにデータが書き込まれる前に、複数の第１テーブルのそれぞれの先頭情報を、先頭のセグメントの１以上先のセグメントを示すように変更する。

上記目的を達成する本発明はまた、次のようなストレージ装置によって実現される。このストレージ装置は、データを所定の単位で書込み及び読出し可能な記憶媒体と、記憶媒体への書込み前及び記憶媒体からの読出し後に、所定の単位の単位データを書込み順又は読出し順にそれぞれ格納する複数のセグメントからなるバッファと、単位データに対し一連の処理を所定の順序で施す複数の処理部と、複数の処理部にそれぞれ対応する複数の第１テーブルであって、対応する処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する複数の第１テーブルと、複数の第１テーブルにより保持される一連の処理の処理状況に基づき、一連の処理が所定の順序で行われるようにバッファと複数の処理部の間のデータ転送を管理する管理部とを含む。

好ましくは、ストレージ装置は、セグメントを指定した一連の処理の処理状況の問い合わせに応答して、複数の第１テーブルを参照して指定されたセグメントに対する処理状況を生成するステータス生成部を含む。そして管理部は、複数の処理部のそれぞれについて、次に処理対象となるセグメントを指定してステータス生成部に処理状況を問い合わせ、当該処理状況が処理部の処理の開始条件を満たすか否かを判断することにより、バッファと複数の処理部の間のデータ転送を管理する。

好ましくは、上記ストレージ装置は、複数の処理部による処理が１つも終了していない連続するアドレスの複数のセグメントにおいて、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報、及び複数の処理部による処理が１つも終了していないセグメントの有無を示す存在情報を格納する第２テーブルと、第２テーブルを参照して記憶媒体へのデータ書込み又はデータ読出しのスピードを調整する調整部と含む。

好ましくは、上記管理部は、バッファにデータを書き込む前にデータに行誤り訂正符号を付加するエンコーダと、当該行誤り訂正符号を付加する単位データであるコードワードを格納するエンコーダ用バッファと、記憶媒体に記憶されたコードワードに対しその途中から上書きを行う場合に、途中から上書きされるコードワードが当該コードワードを格納するリングバッファのあるセグメントからエンコーダ用バッファに転送されるまでの間信号を生成する上書きステートマシーンとを含む。そして上記ストレージ装置は、信号が生成されている間、ステータス生成部より出力される上書き処理のため初期化されたあるセグメントの処理状況をデータ読み出し用の処理状況でマスクするマスク部を含む。

以上、バッファを用いて一連の処理を所定の順序で実行する処理システム、またそのような処理システムを実装するストレージ装置として本発明を説明したが、本発明はそのような処理システム及びストレージ装置における方法、すなわちバッファの各セグメントに格納される単位データに対し一連の処理を所定の順序で行うための方法として把握することもできる。

本発明によれば、単位データに対する各処理回路の処理状況を提供するために、一連の処理を行う複数の処理部の数に等しいレジスタを用意すればよく、セグメント数に等しい数のレジスタを用意する必要がない。その結果、リングバッファの容量が増えセグメント数が増加しても、レジスタ数の増加による消費電力の増加や、回路全体に占めるレジスタ回路の割合の増加の問題がなくなる。

以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下では、Ｌｉｎｅａｒ Ｔａｐｅ Ｏｐｅｎ(ＬＴＯ)規格に従うテープドライブを例に本発明を説明する。なお、ＬＴＯ規格とは、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社、ＩＢＭ 社、Ｓｅａｇａｔｅ Ｔｅｃｈｎｏｌｏｇｙ社の３社が共同で開発したオープンフォーマットの規格である。そこで本発明の具体的な説明に入る前に、図１及び図２を参照して、ＬＴＯテープドライブにおけるデータ書込み前の一連の処理と、従来のセグメント数に等しい数のレジスタを用いた一連の処理の処理状況の管理方法について説明する。

ＬＴＯテープドライブにおけるデータ書込み前の処理は、ホスト装置からのデータをＬＴＯテープドライブで扱う単位データであるデータセットに加工するバッグエンドの処理と、データセットを実際にテープに書き込むビットストリームに変調するフロントエンドの処理とに分けられる。ここでは、バックエンドにおける一連の処理を説明する。

図１は、一連の処理の各ステージにおけるデータのフォーマットを示す。ホスト装置からユーザデータが送られるとまず、ユーザデータに対しエラー訂正コード（以下、ＣＲＣという）が計算されユーザデータに付加される（図１のＡ参照）。その後ＣＲＣが付加されたユーザデータに対し圧縮処理が施される（図１のＢ参照）。圧縮されたデータはＬＴＯテープドライブで扱う単位のデータにまとめられ、バッファに格納される（図１のＣ参照）。なおＬＴＯテープドライブでは、データはデータセットと呼ばれる単位でテープ媒体に記録される。そのためバッファはデータセットのサイズ、すなわち約２メガバイトの大きさのセグメントに分けられリングバッファとして使用される。

次に各セグメントのデータに対し、ＤａｔａＳｅｔ ＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ(ＤＳＩＴ)と呼ばれる、データセットの内容を示す情報が作成され、対応するデータと同じセグメントに格納される（図１のＤ参照）。なお、ＤＳＩＴはデータセット番号やそれに含まれるユーザデータの数など様々な情報を含んでいるので、ＤＳＩＴの作成はハードウェアを直接管理するマイクロコードまたはファームウェアにより行われる。最後にＤＳＩＴが付加されデータに対し、誤り訂正符号（以下、ＥＣＣという）が計算され付加される（図１のＥ参照）。この時点でデータセットが完成する。その後完成したデータセットはフロントエンドに送られる。

図２(a)は、セグメント数に等しい数のレジスタを用いた従来の一連の処理の処理状況の管理方法を示す。ここでは１つのセグメントに対し４ビット幅のレジスタを用意し、４つの処理それぞれの終了ステータスを保持する。４つの処理とは、１．ホスト装置から送信されたデータを処理単位にまとめてバッファに格納するまでの処理、２．ＤＳＩＴを作成しデータに付加する処理、３．ＥＣＣを計算しデータに付加する処理、そして４．完成したデータセットをテープに記録するためフロントエンドへ転送する処理である。

図２（ｂ）に、４つの処理に対するビットの割り当てを示す。左端のビット（ＭＳＢ）から順に、１のホスト転送、２のＤＳＩＴ付加、３のＥＣＣ付加、４のテープ転送が割り当てられる。各ビットは初期状態で０であり、対応する処理が終了するとハードウェアにより１にセットされる。但し、２のＤＳＩＴ付加についてはマイクロコードによりビットのセットがなされる。全てのビットがセットされたレジスタは、対応するセグメントに新しくデータが書き込まれる前にマイクロコードによりクリアされる。

図２(a)では、上記１から４の処理がリングバッファのセグメントＮに格納されるデータセットから順に行われている。全ての処理が終了しているセグメントＮとセグメントＮ＋１に対応する各レジスタは、全てのビットが１にセットされている。セグメントＮ＋２は３のＥＣＣ付加まで処理が終了しており、従って対応するレジスタは最上位ビットからビット１まで１がセットされている。他のセグメントについても同様、対応するセグメントに対し一連の処理がどこまで終了したかを示すようにレジスタの各ビットがセットされている。

このように、一連の処理の各ステージの処理状況をセグメントごと管理するために、従来はセグメント数に等しい数のレジスタが必要とされた。そこで本発明は同じ情報をより少ない数のレジスタで管理することを目的とする。上述したように一連の処理はセグメントＮからセグメントＮ＋５まで順に行われる。そのため各セグメントのレジスタを同じ処理についてみてみると、対応するビットは連続して変化している。

例えば２のＤＳＩＴ付加の処理についてみると、対応するレジスタのビット２は、セグメントＮからセグメントＮ＋３まで連続１であり、セグメントＮ＋４からセグメント＋５まで連続０である。３のＥＣＣ付加の処理についても、対応するレジスタのビット１は、セグメントＮからセグメントＮ＋２まで連続１であり、セグメントＮ＋３からセグメント＋５まで連続０である。従ってフラグが立っている先頭のセグメントと末尾のセグメントの情報を保持すれば、一連の処理の各ステージの処理状況をセグメントごと管理する場合と同じ内容の情報を得ることができることが分かる。従来のセグメントごとのレジスタに代わる本発明の新しいレジスタの詳細は図４を参照して後述する。

図３は、本発明の第１実施形態に係る、一連の処理を所定の順序で実行する処理システム１００の構成の一例を示す。本実施形態では一連の処理の共通の作業領域としてリングバッファを用いる。処理システム１００は、リングバッファ１０５、管理部１１０、処理システム１００に入力されるデータに対し一連の処理を所定の順序で行う、第１処理部１４５、第２処理部１５０、第３処理部１６５及び第４処理部１７０、仮想リングバッファ・ステータス・レジスタ（以下、ＶＲＢＳＲという）１７５を含む。本実施形態に係る処理システム１００はストレージ装置に実装されるものとし、図３には更にストレージ装置全体を制御する制御部１６０と、記憶媒体１４０を示す。ここでストレージ装置はＬＴＯテープドライブであるとして一連の処理を４つの処理部による処理により構成する。しかし、処理部の数はこの分野の当業者に明らかなように４つに制限されない。

なおＬＴＯテープドライブ６０５は、図２２に示すように、ＳＣＳＩインターフェース、ファイバーチャネル、ＳＡＳ等のインターフェースを介してホスト装置６３０に接続される。また、ＬＴＯテープドライブ６０５とホスト装置６３０とは、専用線またはインターネット等のネットワーク６２０を介して接続されてもよい。なお、ＬＴＯテープドライブ６０５は、ＳＣＳＩインターフェース等の通信インターフェースによってパーソナルコンピュータ等の情報処理装置に接続され、情報処理装置を介してネットワーク６２０に接続されてもよい。

このような処理システム１００においてデータは、データ書込み時は、ホスト装置から送信されＬＴＯテープドライブにおいて受信された後、リングバッファ１０５を作業領域として使用する第１処理部１４５、第２処理部１５０、第３処理部１６５、及び第４処理部１７０による処理をこの順に経て最終的に記憶媒体１４０に記録される。また、データ読出し時は、データは記憶媒体１４０から読み出され、リングバッファ１０５を作業領域として使用する上記複数の処理部による処理を、書込み時とは逆の順に経て最終的にホスト装置へ送信される。

第１処理部１４５は通信インターフェース１４６と圧縮部１４８を含む。データ書込み時において、通信インターフェース１４６はホスト装置からユーザデータを受信し、ＣＲＣを付加した後ユーザデータを圧縮部１４８へ送る。そして圧縮部１４８は、ＣＲＣが付加されたユーザデータを圧縮し、リングバッファ１０５に格納するため、圧縮したデータを管理部１１０へ送る。データ読出し時において、圧縮部１４８は管理部１１０を介してリングバッファ１０５から転送された圧縮データを伸張し、通信インターフェース１４６へ送る。そして通信インターフェース１４６は、圧縮部１４８からデータを受け取り、ＣＲＣチェック後ユーザデータをホスト装置へ送信する。

第２処理部１５０はデータ書込み時においてＤＳＩＴ作成部として機能し、管理部１１０を介してリングバッファ１０５から読み出された処理単位のデータに対しＤＳＩＴを作成する。作成されたＤＳＩＴは管理部１１０を介して対応するデータが格納されるリングバッファ１０５のセグメントに追加される。また第２処理部１５０はデータ読出し時において、管理部１１０を介してリングバッファ１０５のセグメントから転送されるデータに付加されているＤＳＩＴをチェックする。上述したようにＤＳＩＴの処理は、ハードウェアとして実現される第１処理部１４５、第３処理部１６５及び第４処理部１７０と異なり、マイクロコードにより行われる。すなわち、第２処理部１５０は、後述するＬＴＯテープドライブ全体を制御する制御部１６０に含まれ、制御部１６０が提供する機能として実現される。

第３処理部１６５は、データ書込み時においてＥＣＣ計算部として機能し、管理部１１０を介してリングバッファ１０５から読み出された、第２処理部１５０による処理が終了したデータに対してＥＣＣを計算する。計算されたＥＣＣは管理部１１０を介して対応するデータが格納されるリングバッファ１０５のセグメントに追加される。また第３処理部１６５はデータ読出し時において、管理部１１０を介してリングバッファ１０５のセグメントから転送されるデータに付加されているＥＣＣを用いてエラー訂正を行う。エラー訂正後のデータは、再び管理部１１０を介してリングバッファ１０５の対応するセグメントに格納される。

第４処理部１７０は、データ書込み時において変調部として機能し、管理部１１０を介してリングバッファ１０５から読み出された、第３処理部１６５による処理が終了したデータセットを、記憶媒体１４０に書き込むビットストリームに変調する。また第４処理部１７０はデータ読出し時において、記憶媒体１４０からデータを読み出し、リングバッファ１０５に格納する。

記憶媒体１４０は、本実施形態ではＬＴＯ規格のテープ媒体であり、第４処理部１７０から送られたデータをデータセットと呼ばれる単位で記録する。データセットはデータ領域とＤＳＩＴの２つの領域からなり、ホスト装置から送られるユーザデータはデータ領域に格納される。リングバッファ１０５は、処理単位にまとめられたユーザデータを入力順にそれぞれ格納する複数のセグメントからなる。リングバッファ１０５はユーザデータをデータセットに加工するまでの作業領域として使用されるため、各セグメントはデータセットと同じ約２メガバイトのサイズをもつ。

ＶＲＢＳＲ１７５は、リングバッファ１０５のセグメントごと一連の処理の各段階の処理状況を管理する。より詳細には、ＶＲＢＳＲ１７５は、複数の処理部（１４５、１５０、１６５、１７０）にそれぞれ対応する複数の第１テーブル（１８１、１８２、１８３、１８４）を含む。第１テーブルの各々は、対応する処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する。

図４（ａ）は、図２（ａ）に示す一連の処理の処理状況を表す複数の第１テーブルの一例を示す。図４の第１テーブル１８１は第１処理部１４５に、第１テーブル１８２は第２処理部１５０に、第１テーブル１８３は第３処理部１６５に、第１テーブル１８４は第１処理部１７０にそれぞれ対応する。図２（ａ）においてＮを３とすると、１．ホスト転送に相当する第１処理部１４５による処理はセグメント３からセグメント８まで終了している。従って第１テーブル１７１は、先頭情報としてセグメント３の識別情報、末尾情報としてセグメント８の識別情報、及び値１の存在情報を格納する。識別情報としては、セグメントのインデックスやアドレスを指すポインタを使用できる。また存在情報は、対応する処理部による処理が終了したセグメントが１つでも存在すれば１がセットされ、そうでなければ０がセットされる。

また２．ＤＳＩＴ付加に相当する第２処理部１５０による処理はセグメント３からセグメント６まで終了している。従って第１テーブル１８２は、先頭情報としてセグメント３の識別情報、末尾情報としてセグメント６の識別情報、及び値１の存在情報を格納する。第１テーブル１８３、第１テーブル１８４についても同様にして値が設定される。比較しやすいよう、図４（ｂ）に、従来の一連の処理の処理状況の管理方法によるセグメント数に等しいレジスタを示した。ここでは理解容易なように、セグメントはセグメント０からセグメント９まで１０個存在するものとしている。

ＶＲＢＳＲ１７５はまた、複数の処理部（１４５、１５０、１６５、１７０）による処理が１つも終了していない連続するアドレスの複数のセグメントにおいて、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報、及び複数の処理部による処理が１つも終了していないセグメントの有無を示す存在情報を格納する第２テーブル１８５を含む。図４（ｃ）は、図４（ｂ）に示す一連の処理の処理状況における第２テーブルの一例を示す。図４（ｂ）では、一連の処理は９から２のセグメントに対しまだ開始されておらず、従って第２テーブルの先頭情報はセグメント９、末尾情報はセグメント２、存在情報は１となる。なお存在情報は、一連の処理が開始されていないセグメントが１つでも存在すれば１がセットされ、そうでなければ０がセットされる。

ＶＲＢＳＲ１７５はまた、アクセス制御部１９０を含む。アクセス制御部１９０は、任意の第１テーブル（１８１、１８２、１８３又は１８４）の先頭情報により示される先頭のセグメントと末尾情報により示される末尾のセグメントの間に、対応する処理部（１４５、１５０、１６５又は１７０）による処理が未処理のセグメントが存在することになるような更新を検知しエラー信号を生成する。アクセス制御部１９０はまた、任意の第１テーブル（１８１、１８２、１８３又は１８４）の更新の前後で先頭情報及び末尾情報が変化しないような更新を検知しエラー信号を生成する。なお、エラー信号の生成方法の詳細は図８乃至図１１を参照して後述する。

ＶＲＢＳＲ１７５は更に、セグメント・ステータス生成部１９２を含む。セグメント・ステータス生成部１９２は、対象セグメントを指定した管理部１１０からの処理状況の問い合わせに応答して、複数の第１テーブル（１８１、１８２、１８３、１８４）を参照して指定されたセグメントについての一連の処理の処理状況を生成する。生成された処理状況は管理部１１０へ返される。

一例として管理部１１０へ返される処理状況は３ビットの信号からなり、各ビットはそれぞれ対象ステージ、及びその前後のステージによる処理が終了したか否かを示す。対象ステージの１つ後のステージに関する処理状況が含まれるのは、データ書込み時と読出し時では一連の処理の処理方向が逆になるからである。例えばあるステージのデータ書込み時における１つ後のステージは、データ読出し時においては１つ前のステージとなる。なお、処理状況の生成方法の詳細は図７を参照して後述する。

ＶＲＢＳＲ１７５は更にまた、ポインタビュー・レジスタ１９４とセグメントビュー・レジスタ１９６とを含む。これは後述する制御部１６０により一連の処理全体を制御するためアクセスされるレジスタである。ポインタビュー・レジスタ１９４は、処理部ごと処理状況を示すビューを提供し、複数の第１テーブル（１８１，１８２，１８３，１８４）及び第２テーブル１８５のそれぞれと同じ内容を保持する５つのレジスタからなる。

図５に示す表の下段に、セグメント数を１０２４個とした場合のポインタビュー・レジスタ１９４の一例を示す。レジスタＶＲＢＳＲＥは第１テーブル１８１に、レジスタＶＲＢＳＲＭは第１テーブル１８２に、レジスタＶＲＢＳＲＣは第１テーブル１８３に、レジスタＶＲＢＳＲＩは第１テーブル１８４に、レジスタＶＲＢＳＲＺは第２テーブル１８５にそれぞれ対応する。第１テーブルに対応する各レジスタは、ビット０からビット９の１０ビットに末尾情報、ビット１６からビット２５の１０ビットに先頭情報、ビット３１の１ビットに存在情報を保持する。また、第２テーブル１８５に対応するレジスタは、ビット０からビット１０の１１ビットに、初期ステータスをもつセグメントの数、すなわち複数の処理部（１４５、１５０、１６５、１７０）による処理が１つも終了していないセグメントの数、ビット３１の１ビットに存在情報を保持する。このように第２テーブル１８５に対応するレジスタは第２テーブル１８５と一対一に対応させる必要はなく、その場合実装が容易になる。

セグメントビュー・レジスタ１９６は、セグメントごと一連の処理の処理状況を示すビューを提供し、回路規模に影響を与えない程度の数の複数のレジスタからなる。セグメントビュー・レジスタ１９６により一度に処理状況が提供される複数のセグメントの集まりを１ウィンドウと呼ぶことにする。制御部１６０は、ウィンドウを適宜切り替えて目的のセグメントの処理状況を示すレジスタをアクセスする。ウィンドウの指定はレジスタによりなされ、制御部１６０がそのレジスタにアクセスを希望するウィンドウを設定すると、設定されたレジスタの値は、セグメント・ステータス生成部１９２に対して指定されるセグメントのアドレスの一部となる。

図５に示す表の上段に、セグメント数を１０２４個とした場合のセグメントビュー・レジスタ１９６の一例を示す。セグメントビュー・レジスタ１９６は２バイト幅の８つのレジスタからなり、２個のセグメントに対し１つのレジスタが割り当てられる。従ってこの例では１ウィンドウで１６個のセグメントの処理状況を確認できる。そして、制御部１６０がウィンドウを指定するために設定したレジスタの値は、セグメント・ステータス生成部１９２に対して指定されるセグメントのアドレスの上位６ビットとなる。各レジスタは、ビット０からビット７の１バイトを１つのセグメントに、またビット８からビット１５の１バイトを他のセグメントに割り当てる。そして各バイトのビット０からビット４の４ビットに、複数の処理部（１４５、１５０、１６５、１７０）による処理の終了ステータスがそれぞれ保持される。なお１ウィンドウに含まれる複数のレジスタは必ずしも同時に更新される必要はなく、ある１つのレジスタのみ更新されてよい。またレジスタは、当該レジスタに割り当てられる２個のセグメントをアクセスするようにアクセスすることも、または片方の１個のセグメントにアクセスするようにアクセスすることもできる。

制御部１６０は目的に適したビューを使用して一連の処理の処理状況を読み出し、または変更する。例えば、ある処理について複数のセグメントの処理状況をクリアする場合、制御部１６０はポインタビュー・レジスタ１９４をアクセスする。また、あるセグメントについて一連の処理の処理状況をクリアする場合、制御部１６０はセグメントビュー・レジスタ１９６をアクセスする。このように本実施形態では一連の処理の処理状況について制御部１６０に対し２種類のビューを用意する。

管理部１１０は、複数の第１テーブルにより保持される一連の処理の処理状況に基づき、一連の処理が所定の順序で行われるようにリングバッファ１０５と複数の処理部（１４５、１６５、１７０）の間のデータ転送を管理する。データ転送は、複数の処理部のそれぞれについて、次に処理対象となるセグメントの一連の処理の処理状況をセグメント・ステータス生成部１９２に問い合わせ、当該処理状況がその処理部の処理の開始条件を満たすか否かを判断することによりなされる。より具体的には、管理部１１０は、次に処理対象となるセグメントに対する処理状況が、開始条件を判断する対象の処理部による処理が終了しておらず、かつその１つ前の処理部による処理が終了していることを示すこと条件に、開始条件を判断する対象の処理部へ次に処理対象となるセグメントの単位データを転送する。

そこで管理部１１０は、一連の処理を所定の順序で行う複数の処理部のそれぞれについて、次に処理対象となるセグメントを示すカウンタ（第１カウンタ１１２、第２カウンタ１２０、第３カウンタ１２２、第４カウンタ１３０）、処理部の処理の開始条件をカウンタが示すセグメントに対する一連の処理の処理状況が満たすか否かを判断する開始判断部（第１開始判断部１１４、第３開始判断部１２４、第４開始判断部１３２）、リングバッファ１０５と処理部との間のデータ転送を行う転送部（第１データ転送部１１６、第２データ転送部１２１、第３データ転送部１２６、第４データ転送部１３４）、及びデータ転送処理後対応する第１テーブル（１８１、１８３、１８４）を更新する更新部（第１更新部１１８、第３更新部１２８、第４更新部１３６）を含む。

なお第２処理部１５０はＬＴＯテープドライブ全体を制御する制御部１６０に含まれ、制御部１６０が提供する機能として実現されるため、リングバッファ１０５と第２処理部１５０の間のデータ転送は基本的に制御部１６０により管理される。従って第２処理部１５０に対する開始判断部（第２開始判断部１５２）、更新部（第２更新部１５６）は制御部１６０に含まれ、カウンタ（第２カウンタ１２０）及び第２データ転送部１２１のみが管理部１１０に含まれる。

データ書込み時における管理部１１０のデータ転送管理方法を、リングバッファ１０５と第３処理部１６５の間のデータ転送を例として具体的に説明する。まず、第３カウンタ１２２の値がＶＲＢＳＲ１７５へ送られ、セグメント・ステータス生成部１９２により受け取られる。このとき複数の第１テーブルは図４（ａ）に示す状態にあるとする。詳細は後述するがセグメント・ステータス生成部１９２は、複数の第１テーブル（１８１、１８２、１８３、１８４）を参照して第３カウンタ１２２の値が示すセグメント（ここではセグメント６とする）の一連の処理の処理状況を生成する。

セグメント６に対する処理は、第１処理部１４５と第２処理部１５０による処理が終了しており、第３処理部１６５と第４処理部１７０による処理はまだなされていない（図４（ａ）、及び図４（ｂ）の番号４０５参照）。そこでセグメント・ステータス生成部１９２により一連の処理の処理状況として最終的に３ビット信号“１００”が生成され、管理部１１０へ返される。３ビット信号は、左端のビットから順に、第２処理部１５０、第３処理部１６５、第４処理部１７０に対応する。第３開始判断部１２４は、受け取ったセグメント６に対する処理状況“１００”が、第３処理部１６５による処理の開始条件を満たすかどうか、すなわち、第３処理部１６５による処理が終了しておらず、かつ第２処理部１５０による処理が終了していることを示すかどうか判断する。条件が満たされていない場合、第３開始判断部１２４は、条件を満たす信号を待ち続ける。

受け取った３ビット信号は、第２処理部１５０に対応する左端のビットのみが値１となっているので条件を満たしており、従って第３開始判断部１２４はデータ転送の開始を第３データ転送部１２６に伝える。第３データ転送部１２６は、リングバッファ１０５からセグメント６の単位データを読み出し第３処理部１６５へ転送する。そして第３更新部１２８は、データ転送を待って第１テーブル１８３を更新する。本実施の形態では、第３更新部１２８はセグメント６による第１テーブル１８３の更新をＶＲＢＳＲ１７５にリクエストし、実際の更新はアクセス制御部１９０が行う。また、データ転送後、第３カウンタの値は次のセグメントを示すようインクリメントされる。

なお、上記ではデータ書込み時の一連の処理を例に説明したため、第３開始判断部１２４において、処理状況を示す３ビット信号のうち第４処理部に対応する右端のビットは無視された。しかしデータ読み出し時の一連の処理では、第３処理部１６５の１つ前のステージは第４処理部１７０となり、一連の処理の処理状況を示す３ビット信号のうち第２処理部に対応する左端のビットが無視される。

制御部１６０により管理されるリングバッファ１０５と第２処理部１５０の間のデータ転送の方法も基本的に管理部１１０による方法と同じである。但し、制御部１６０による場合、セグメント・ステータス生成部１９２により生成される、第２カウンタ１２０が示すセグメントの一連の処理の処理状況は、セグメントビュー・レジスタ１９６に書き込まれる。従って制御部１６０は、第２カウンタ１２０が示すセグメントに対応するセグメントビュー・レジスタ１９６のレジスタ値を読み出し第２開始判断部１５２へ伝える必要がある。

また、第２更新部１５６による第１テーブル１８２の更新は、ポインタビュー・レジスタ１９４を介して行われる。すなわち、第２更新部１５６はアクセス制御部１９０が更新するように第１テーブル１８２に対応するポインタビュー・レジスタ１９４を更新する。更新されたポインタビュー・レジスタ１９４の内容は即座に第１テーブル１８２に反映される。

制御部１６０は、処理システム１００を含むストレージ装置全体を制御する。制御部１６０は、第２処理部１５０、第２開始判断部１５２、第２更新部１５６を含み、これらについては上述したとおりである。制御部１６０は更に初期化部１５８を含む。初期化部１５８は、リングバッファ１０５のすべてのセグメントにデータが書き込まれる前に、一例として、リングバッファ１０５がＦＵＬＬになる数個前のセグメントに対しデータが書き込まれると、複数の第１テーブル（１８１、１８２、１８３、１８４）のそれぞれの先頭情報を、先頭のセグメントの次のセグメントを示すように変更する。これにより、データ転送が中断することがなくなり、かつリングバッファを最大限有効に使用することができる。初期化部１５８に対するＦＵＬＬの通知は一例としてステータスレジスタを用いて行うことができる。

図４に示す一連の処理の処理状況を例にデータ書込み時における初期化部１５８の処理を説明する。ここで図４（ａ）及び（ｂ）に示すように、データはセグメント３から順に書き込まれ最後にデータが書き込まれるセグメントをセグメント２とする。この場合、リングバッファ１０５のすべてのセグメント３乃至セグメント２にデータが書き込まれる前に、先頭情報をセグメント３からセグメント４に変更する。その結果、図４（ｂ）に斜線で示すセグメント３に対する一連の処理の処理状況は０に初期化され、セグメント３に対しデータ上書きが可能となる。なお、先頭情報は、先頭のセグメントの次のセグメントではなく、先頭セグメントの２個先、又は３個先のセグメント等、数個先のセグメントを指すように変更してもよい。

制御部１６０はまた、第２テーブル１８５を参照して記憶媒体１４０への又はからのデータ書込み及びデータ読出しのスピードを調整する調整部１５９を含む。通常ストレージ装置には、ホスト装置とストレージ装置のそれぞれのデータ転送速度をみてストレージ装置すなわち記憶媒体１４０のデータ転送速度を調整する機能がある。上述したように第２テーブル１８５は、一連の処理が開始されていない連続するアドレスの複数のセグメントにおいて、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報を格納する。そこで本発明に係る制御部１６０は、第２テーブル１８５を参照して一連の処理が開始されていない残りのセグメント数とそのリングバッファ１０５上の位置とに基づき、記憶媒体１４０のデータ転送速度をより細かく調整する。なお、制御部１６０の他の機能については当業者に良く知られており、本発明に直接関係しないため説明を省略する。

次に、図６乃至図８のフローチャートを参照して、本実施形態に係る処理システム１００のデータ書込み時の動作を説明する。図６（ａ）は第１処理部１４５に対する管理部１１０のデータ書込み時の処理の流れを示す。処理はステップ１００で開始し、管理部１１０は、ホスト装置から送られてきたユーザデータを第１処理部１４５から受け取る。管理部１１０は、受け取ったユーザデータを処理単位にまとめ、リングバッファ１０５のセグメントに順次格納する（ステップ１０５）。次に管理部１１０は、データを格納したセグメントの識別情報を用いて第１処理部１４５に対応する第１テーブル１８１を更新する（ステップ１１０）。なお、上述したように本実施形態では管理部１１０は更新をＶＲＢＳＴにリクエストし、実際の更新はアクセス制御部１９０によりなされる。

図６（ｂ）は、第３処理部１６５及び第４処理部１７０に対する管理部１１０のデータ書込み時の処理、または第２処理部１５０に対する制御部１６０のデータ書込み時の処理の流れを示す。ここでは第３処理部１６５に対する管理部１１０の処理として図６（ｂ）のフローチャートを説明する。処理はステップ１２０で開始し、管理部１１０は、第３カウンタ１２２の値をＶＢＲＳＲ１７５へ送り、次のセグメントに対する一連の処理の処理状況を問い合わせる。ＶＢＲＳＲ１７５から次のセグメントに対する処理状況を受け取ると、管理部１１０は次のセグメントに対し第３処理部１６５による処理を開始することが可能か否か判断する（ステップ１２５）。ステップ１２５のＮＯの場合、処理は１２０へ戻り条件を満たす処理状況を待ち続ける。

一方ステップ１２５でＹＥＳの場合、管理部１１０は、第３カウンタ１２２が示すバッファリング１０５の次のセグメントから単位データを読出し第３処理部１６５へ転送する（ステップ１３０）。データを転送後、管理部１１０は第３カウンタ１２２の値を用いて第３テーブル１８３を更新する（ステップ１３５）。そして第３処理部１６５において処理が終了し処理結果が送られると、管理部１１０は受け取った処理結果を第３カウンタ１２２が示すセグメントに格納し追加する（ステップ１４０）。最後に管理部１１０は第３カウンタ１２２を次のセグメントを示すようにインクリメントする（ステップ１４５）。

なお、第４処理部１７０に対する管理部１１０の処理の場合、ステップ１４０は存在しない。これは、第４処理部１７０はデータ書込み時において一連の処理の最後の処理であるからである。また第２処理部１５０に対する制御部１６０の処理では、次のセグメントに対する一連の処理の処理状況は、上述したように対応するセグメントビュー・レジスタ１９６から読み出される。

図７は、ＶＢＲＳＲ１７５のセグメント・ステータス生成部１９２のデータ書込み時の処理の流れを示す。処理はステップ１５０で開始し、セグメント・ステータス生成部１９２は、管理部１１０からカウンタの値Ｎが送られ一連の処理の処理状況の問い合わせを受けると、受け取った情報から対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）と対象ステージの情報を取得する。次にセグメント・ステータス生成部１９２は、各ステージについて処理状況を示す１ビットを設定するために以下のステップ１６０からステップ２１０までの処理を、複数の第１テーブルのそれぞれについて並列に行う。なお１ビットの値０は処理が終了していないことを示し、値１は処理が終了していることを示すものとする。

最初に第１テーブルから存在情報の値ＥＸＩＳＴが取得される（ステップ１６０）。そして値ＥＸＩＳＴが０であるか否か判断される（ステップ１６５）。値ＥＸＩＳＴが０の場合（ステップ１６５：ＹＥＳ）、対応するビットが０にセットされる（ステップ１７０）。これは、存在情報が０を示すということは、現在対象とするステージの処理が終了したセグメントが存在しないことを意味するからである。

一方ステップ１６５でＮＯの場合、先ほどの第１テーブルから先頭情報（ｓｅｇｍｅｎｔ(Ｂ)）と末尾情報（ｓｅｇｍｅｎｔ(Ｅ)）を取得する（ステップ１７５）。そしてリングバッファ１０５上、処理が終了している先頭のセグメント（ｓｅｇｍｅｎｔ(Ｂ)）と末尾のセグメント（ｓｅｇｍｅｎｔ(Ｅ)）の間に対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）が位置するかどうかを、次のようにして判断する。

まず値Ｂが値Ｅ以下であるか否か判断する（ステップ１８０）。ステップ１８０でＹＥＳの場合、次にＮがＢ以上かつＥ以下であるか否か判断する（ステップ１８５）。ステップ１８５でＹＥＳの場合、対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）は先頭のセグメント（ｓｅｇｍｅｎｔ(Ｂ)）と末尾のセグメント（ｓｅｇｍｅｎｔ(Ｅ)）の間に含まれるので、対応ビットを１にセットする（ステップ１９０）。一方値Ｎが値Ｂ以上かつ値Ｅ以下でない場合（ステップ１８５：ＮＯ）、対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）は処理が終了しているセグメントの範囲に含まれないので、対応ビットを０にセットする（ステップ１９５）。

一方値Ｂが値Ｅより大きい場合（ステップ１８０：ＮＯ）、次に値Ｎが値Ｅより大きくかつＢより小さいか否か判断する（ステップ２００）。ステップ２００でＮＯの場合、対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）は先頭のセグメント（ｓｅｇｍｅｎｔ(Ｂ)）と末尾のセグメント（ｓｅｇｍｅｎｔ(Ｅ)）の間に含まれるので、対応ビットを１にセットする（ステップ２０５）。一方ステップ２００でＹＥＳの場合、対象セグメント（ｓｅｇｍｅｎｔ(Ｎ)）は処理が終了しているセグメントの範囲に含まれないので、対応ビットを０にセットする（ステップ２１０）。

ステップ１７０、１９０、１９５、２０５、又は２１０から処理はステップ２１５へ進み、セグメント・ステータス生成部１９２は、対象ステージの１つ前のステージに対応するビットを左端のビットとして、対象ステージに対応するビット、対象ステージの１つ後のステージに対応するビットを順次結合する。そしてセグメント・ステータス生成部１９２は、生成した３ビット信号を処理状況として管理部１１０へ返し（ステップ２２０）、処理は終了する。

なお、上記では管理部１１０のカウンタにより１つのセグメントを指定された場合のセグメント・ステータス生成部１９２の処理の流れを説明した。しかし制御部１６０によりウィンドウを指定されて複数のセグメントの処理状況を求める場合も、セグメント・ステータス生成部１９２の処理の流れは同じである。すなわちこの場合は複数のセグメントについて図７を参照して説明した処理が並列に実行される。

図８は、管理部１１０の任意の更新部（第１更新部１１８、第３更新部１２８、第４更新部１３６）に対するアクセス制御部１９０のデータ書込み時の処理の流れを示す。処理はステップ２４０で開始し、アクセス制御部１９０は管理部１１０の任意の更新部から、更新対象の第１テーブル情報とセグメント情報（ｓｅｇｍｅｎｔ(Ｎ)）を取得する。アクセス制御部１９０は、更新対象の第１テーブルから存在情報（値ＥＸＩＳＴ）を取得し（ステップ２４５）、処理が終了したセグメントが存在するかどうか、すなわち値ＥＸＩＳＴが０に等しいか否か判断する（ステップ２５０）。ステップ２５０でＹＥＳの場合、処理が終了したセグメントは存在しないので、アクセス制御部１９０は存在情報に１をセットし（ステップ２５５）、更新対象の第１テーブルの先頭情報と末尾情報をｓｅｇｍｅｎｔ(Ｎ)で更新する（ステップ２６０）。

図９に、任意の処理部についてのセグメントの処理状況（図９（ａ））と、その処理部に対応する更新前後の第１テーブル（図９（ｂ)、（ｃ））を示す。図８（ａ）において、「-」は処理が終わっていないセグメントであること、「Ｂ」は処理が終わった先頭セグメントであること、「×」は処理が終わったセグメントであること、「Ｅ」は処理が終わった末尾のセグメントであること、斜線は新たに処理が終わったセグメントであることを示す。

図９において、最初に処理が終わったセグメントについて第１テーブルを更新するケースはケース１として示されている。図９（ａ）のケース１をみると、セグメント２について新たに処理が終わっている。更新前は処理が終了したセグメントはまだ存在しないため、図９（ｂ) のケース１の存在情報は０となっている。更新後はセグメント２の処理が終了しているため図９（ｃ)のケース１の先頭情報と末尾情報はセグメント２を示し、存在情報も１となっている。

図８（ａ）のステップ２５０に戻って、一方値ＥＸＩＳＴが１の場合、これは処理が終了したセグメントが存在することを示すので、リクエストされた第１テーブルの更新が第１テーブルを不連続とするような、又は上書きするような更新でないことを確認する必要がある。そこで値ＥＸＩＳＴが１に等しい場合（ステップ２５０：ＮＯ）、アクセス制御部１９０は、更新対象の第１テーブルから先頭情報（ｓｅｇｍｅｎｔ(Ｂ)）を取得する（ステップ２６５）。そしてアクセス制御部１９０は、リングバッファ上ｓｅｇｍｅｎｔ(Ｎ)がｓｅｇｍｅｎｔ(Ｂ)よりも１つ前に位置するかどうか、すなわち値Ｎが値Ｂ−１に等しいか否か判断する（ステップ２７０）。値Ｎが値Ｂ−１に等しい場合（ステップ２７０：ＹＥＳ）、アクセス制御部１９０は、更新対象の第１テーブルの先頭情報をｓｅｇｍｅｎｔ(Ｎ)で更新する（ステップ２７５）。

図９において、処理が終わったセグメントが存在する場合に新たに処理が終了したセグメントについて第１テーブルを更新する第１のケースがケース２として示されている。図９（ａ）のケース２では、セグメント１について新たに処理が終わっている。更新前はセグメント２からセグメント５まで処理が終了しているため、図９（ｂ) のケース２の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。更新後はセグメント１の処理が新たに終了するため図９（ｃ)のケース２の先頭情報は１に更新されている。なおケース２は、リングバッファ上セグメントが順次処理されている限り起こりえないケースである。しかしケース２において第１テーブルはセグメントが連続して変化するように更新されるため本実施形態ではこのような更新も許可している。

図８に戻りステップ２７０でＮＯの場合、アクセス制御部１９０は、更新対象の第１テーブルから末尾情報（ｓｅｇｍｅｎｔ(Ｅ)）を取得する（ステップ２８０）。そしてアクセス制御部１９０は、リングバッファ上ｓｅｇｍｅｎｔ(Ｎ)がｓｅｇｍｅｎｔ(Ｂ)よりも１つ後ろに位置するかどうか、すなわち値Ｎが値Ｅ＋１に等しいか否か判断する（ステップ２８５）。ステップ２８５でＹＥＳの場合、アクセス制御部１９０は、更新対象の第１テーブルの末尾情報をｓｅｇｍｅｎｔ(Ｎ)で更新する（ステップ２９０）。

図９において、処理が終わったセグメントが存在する場合に新たに処理が終了したセグメントについて第１テーブルを更新する第２のケースがケース３として示されている。図９（ａ）のケース３では、セグメント６に対し新たに処理が終わっている。更新前はセグメント２からセグメント５まで処理が終了しているため、図９（ｂ) のケース３の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。更新後はセグメント６の処理が新たに終了するため図９（ｃ)のケース３の末尾情報は６に更新されている。なおケース３は最も起こりえる通常のケースである。

図８に戻りステップ２６０、ステップ２７５、又はステップ２９０から処理はステップ２９２へ進み、
アクセス制御部１９０は他の第１テーブルを確認して、当該更新がｓｅｇｍｅｎｔ(Ｎ)について最初の更新であるかどうか、すなわちｓｅｇｍｅｎｔ(Ｎ)について他の処理部による処理が終了しているか否か判断する。ステップ２９２でＹＥＳの場合、アクセス制御部１９０は第２テーブル１８５をｓｅｇｍｅｎｔ(Ｎ)で更新する（ステップ２９４）。ステップ２９２でＮＯの場合又はステップ２９２の後処理は終了する。

一方ステップ２８５でＮＯの場合、すなわち値Ｎが値Ｅ＋１に等しくない場合、アクセス制御部１９０はエラー信号を生成する（ステップ２９６）。これは、リクエストされた第１テーブルの更新が、処理が終了したセグメントが不連続に並ぶような、又は既に終了したセグメントを上書きするような更新であるからである。その後処理は終了する。なおエラー信号は、インターラプトまたはステータスレジスタとして制御部１６０へ伝えられる。

図９において、処理が終わったセグメントが存在する場合に新たに処理が終了したセグメントについて第１テーブルを更新する第３のケースがケース４及びケース５として示されている。図９（ａ）のケース４では、セグメント０（又はセグメント７）に対し新たに処理が終わっている。更新前はセグメント２からセグメント５まで処理が終了しているため、図９（ｂ) のケース４の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。ここで、先頭情報をセグメント０で更新すると、実際は処理が終了していないセグメント１を処理が終了したセグメントとして示してしまう。同様に末尾情報をセグメント７で更新すると、実際は処理が終了していないセグメント６を処理が終了したセグメントとして示してしまう。そのためケース４では第１テーブルの更新は許可されない。

また図９（ａ）に示すようにケース５では、セグメント２（又はセグメント３、４、５のいずれか）に対し新たに処理が終わっている。更新前はセグメント２からセグメント５まで処理が終了しているため、図９（ｂ) のケース５の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。ここで、更新を許可すると、見かけ上第１テーブルは変化せず処理が終了したセグメントは連続して並んだままであるが、セグメント２（又はセグメント３、４、５のいずれか）に対するデータの上書きを許可してしまうことになる。そのためケース５では第１テーブルの更新は許可されない。但し第１テーブルにおける処理済のセグメントに対する上書きが、リングバッファ１０５のセグメントに対するデータの上書きとなるのは、シーケンスを必ず守る必要があるハードウェアに対してのみ当てはまることである。従って、制御部１６０による第１テーブルの更新については、ケース５の場合を許可する構成としてもよい。

図１０（ａ）は、セグメントビュー・レジスタ１９６を使用して特定のセグメントの終了ステータスをクリアする制御部１６０の処理の流れを示す。処理はステップ３００で開始し、制御部１６０は一連の処理の処理状況をクリアすべきセグメントを含むウィンドウを指定する。そして目的のセグメントに対応するセグメントビュー・レジスタ１９６をアクセスし、全ビットに０を設定する（ステップ３０５）。その後処理は終了する。

図１０（ｂ）は、セグメントビュー・レジスタ１９６を使用して第１テーブルをクリアするアクセス制御部１９０の処理の流れを示す。図１０（ｂ）に示すフローチャートは図１０（ａ）のフローチャートに続くものである。処理はステップ３１０で開始し、アクセス制御部１９０はまず、クリアされたセグメントビュー・レジスタ１９６に対応するセグメント情報（ｓｅｇｍｅｎｔ(Ｎ)）を取得する。ｓｅｇｍｅｎｔ(Ｎ)は新たに一連の処理が開始されていないセグメントとなるため、アクセス制御部１９０は第２テーブル１８５をｓｅｇｍｅｎｔ(Ｎ)で更新する（ステップ３１２）。次にアクセス制御部１９０は、複数の第１テーブル（１８１、１８２、１８３、１８４）の各々について以下のステップ３１５からステップ３６０までの処理を並列に行う。

ステップ３１５においてアクセス制御部１９０は、第１テーブルから先頭情報（ｓｅｇｍｅｎｔ(Ｂ)）と末尾情報（ｓｅｇｍｅｎｔ(Ｅ)）を取得する。そしてアクセス制御部１９０は、ｓｅｇｍｅｎｔ(Ｎ)、ｓｅｇｍｅｎｔ(Ｂ)、ｓｅｇｍｅｎｔ(Ｅ)がみな同一セグメントであるか否か判断し（ステップ３２０）、ステータスをクリアしようとするセグメントが、当該第１テーブルにおいて終了ステータスをもつ唯一のセグメントであるかどうかを確認する。ステップ３２０でＹＥＳの場合、アクセス制御部１９０は、第１テーブルの存在情報（ＥＸＥＳＩＴ）に０をセットする（ステップ３２５）。そしてアクセス制御部１９０は、第１テーブルの先頭情報と末尾情報に０をセットしクリアする（ステップ３３０）。その後処理は終了する。

図１１に、任意の処理部についてのセグメントの処理状況（図１１（ａ））と、その処理部に対応する更新前後の第１テーブル（図１１（ｂ)、（ｃ））を示す。図１１（ａ）において、「-」は処理が終わっていないセグメントであること、「Ｂ」は処理が終わった先頭セグメントであること、「×」は処理が終わったセグメントであること、「Ｅ」は処理が終わった末尾のセグメントであること、斜線は終了ステータスをクリアすべきセグメントであることを示す。

図１１において、ステータスをクリアしようとするセグメントが、終了ステータスをもつ唯一のセグメントであるケースはケース１として示されている。図１１（ａ）のケース１をみると、セグメント２がステータスをクリアしようとするセグメントである。更新前は処理が終了したセグメントはセグメント２だけであるため、図１１（ｂ) のケース１の先頭情報と末尾情報はどちらもセグメント２を示している。更新後はセグメント２の終了ステータスがクリアされるため図１１（ｃ)のケース１の先頭情報と末尾情報は０を示し、存在情報も０となっている。

図１０（ｂ）に戻ってステップ３２０でＮＯの場合、アクセス制御部１９０はｓｅｇｍｅｎｔ(Ｎ)がｓｅｇｍｅｎｔ(Ｂ)に等しいか否か判断する（ステップ３３５）。ＮがＢに等しい場合（ステップ３３５：ＹＥＳ）、アクセス制御部１９０は、第１テーブルの先頭情報にｓｅｇｍｅｎｔ(Ｂ＋１)をセットする（ステップ３４０）。その後処理は終了する。ＮがＢに等しくない場合（ステップ３３５：ＮＯ）、アクセス制御部１９０はｓｅｇｍｅｎｔ(Ｎ)がｓｅｇｍｅｎｔ(Ｅ)に等しいか否か判断する（ステップ３４５）。ＮがＥに等しい場合（ステップ３４５：ＹＥＳ）、アクセス制御部１９０は、第１テーブルの末尾情報にｓｅｇｍｅｎｔ(Ｅ−１)をセットする（ステップ３５０）。その後処理は終了する。

図１１において、ステータスをクリアしようとするセグメントが、終了ステータスをもつ連続するセグメントのうち先頭セグメントであるケースはケース２として示されている。図１１（ａ）のケース２をみると、セグメント２がステータスをクリアしようとするセグメントである。更新前はセグメント２からセグメント５まで処理が終了しているため、図１１（ｂ) のケース２の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。更新後はセグメント２の終了ステータスがクリアされるため図１１（ｃ)のケース２の先頭情報は３に更新されている。

また図１１において、ステータスをクリアしようとするセグメントが、終了ステータスをもつ連続するセグメントのうち末尾セグメントである場合はケース３として示されている。図１１（ａ）のケース３をみると、セグメント５がステータスをクリアしようとするセグメントである。更新前はセグメント２からセグメント５まで処理が終了しているため、図１１（ｂ) のケース３の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。更新後はセグメント５の終了ステータスがクリアされるため図１１（ｃ)のケース３の末尾情報は４に更新されている。

図１０（ｂ）に戻ってステップ３４５でＮＯの場合、アクセス制御部１９０はＮがＢより小さいか又はＮがＥより大きいか、すなわち、ｓｅｇｍｅｎｔ(Ｎ)がｓｅｇｍｅｎｔ(Ｂ)からｓｅｇｍｅｎｔ(Ｅ)の範囲外であるか否か判断する（ステップ３５５）。範囲外である場合（ステップ３５５：ＹＥＳ）、ｓｅｇｍｅｎｔ(Ｎ)はもともと終了ステータスをもっていないため、アクセス制御部１９０は当該テーブルに対し何ら処理を行わない。一方ステップ３５５でＮＯの場合、アクセス制御部１９０はエラー信号を生成する（ステップ３６０）。これは、セグメントビュー・レジスタ１９６を介してリクエストされた第１テーブルの更新が、処理が終了したセグメントが不連続に並ぶような更新であるからである。その後処理は終了する。なお、エラー信号は、インターラプトまたはステータスレジスタとして制御部１６０へ伝えられる。

図１１において、ステータスをクリアしようとするセグメントが、終了ステータスをもたないセグメントである場合はケース４として示されている。図１１（ａ）のケース４をみると、セグメント０（又は１、６、７のいずれか）がステータスをクリアしようとするセグメントである。更新前はセグメント２からセグメント５まで処理が終了しているため、図１１（ｂ) のケース４の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。ケース４では第１テーブルの更新は行われないため、図１１（ｃ)のケース３は図１１（ｂ）のケース３と変わりない。

また図１１において、ステータスをクリアしようとするセグメントが、終了ステータスをもつ連続するセグメントの途中のセグメントである場合はケース５として示されている。図１１（ａ）のケース５をみると、セグメント４がステータスをクリアしようとするセグメントである。更新前はセグメント２からセグメント５まで処理が終了しているため、図１１（ｂ) のケース５の先頭情報は２、末尾情報は５を示し、存在情報は１となっている。ここでセグメント４の終了ステータスのクリアを許可すると、終了ステータスをもつセグメントが不連続に並ぶことになるため、ケース５では第１テーブルの更新は許可されない。

図１２は、ポインタビュー・レジスタ１９４を使用して特定の第１テーブルの終了ステータスをクリアする制御部１６０の処理の流れを示す。処理はステップ４００で開始し、制御部１６０は初期化を希望する第１テーブルの内容と同じ内容を保持するポインタビュー・レジスタ１９４から、先頭情報と末尾情報を取得する（ステップ４００）。そして制御部１６０は終了ステータスをクリアしようとする１以上のセグメントが、現在終了ステータスをもつセグメント全てであるか否か判断する（ステップ４１０）。ステップ４１０でＹＥＳの場合、制御部１６０は先頭情報、末尾情報及び存在情報のすべてに０をセットする（ステップ４２０）。

一方終了ステータスをもつセグメントの一部をクリアしようする場合（ステップ４１０：ＮＯ）、制御部１６０はまずクリアしようとする１以上のセグメントが、現在終了ステータスをもつセグメントの先頭部分であるか否か判断する（ステップ４２５）。ステップ４２５でＹＥＳの場合、制御部１６０は先頭情報を更新して、終了ステータスをもつ先頭部分のセグメントのステータスをクリアする（ステップ４３０）。

一方クリアしようとするセグメントが現在終了ステータスをもつセグメントの先頭部分でない場合（ステップ４２５：ＮＯ）、制御部１６０は更にクリアしようとする１以上のセグメントが、現在終了ステータスをもつセグメントの末尾部分であるか否か判断する（ステップ４３５）。ステップ４３５でＹＥＳの場合、制御部１６０は末尾情報を更新して、終了ステータスをもつ末尾部分のセグメントのステータスをクリアする（ステップ４４０）。

ステップ４２０、４３０又は４４０から処理はステップ４４５へ進み、制御部１６０は終了ステータスをクリアしたセグメントについて、更新した第１テーブルが終了ステータスをもつ唯一の第１テーブルであったか否か判断する。ステップ４４５でＹＥＳの場合、制御部１６０は、第２テーブルに対応するポインタビュー・レジスタ１９４を更新する（ステップ４５０）。ステップ４３５またはステップ４４５でＮＯの場合、またステップ４５０の後処理は終了する。なお、更新されたポインタビュー・レジスタ１９４の値は、対応する第１テーブル及び第２テーブルに即座に反映される。

図１３は、初期化部１５８による処理の流れを示す。上述したように初期化部１５８はリングバッファ１０５のすべてのセグメントにデータが書き込まれる前に、終了ステータスをもつ先頭セグメントのステータスをクリアしてリングバッファ１０５がＦＵＬＬになるのを防ぐ。処理はステップ５００で開始し、初期化部１５８はもうすぐリングバッファ１０５がＦＵＬＬになることを知らせる通知を受け取る。ＦＵＬＬの通知は一例として、末尾情報がさすセグメントの２個先のセグメントが、先頭情報がさすセグメントになるときをハードウェアにより検知し、信号を出すことによりなされる。通知に応答して初期化部１５８は、第１テーブルに対応するポインタビュー・レジスタ１９４から先頭情報を保持するレジスタの値（ｓｅｇｍｅｎｔ（Ｂ））を読み出す（ステップ５０５）。

そして初期化部１５８は、読み出したレジスタの値をｓｅｇｍｅｎｔ（Ｂ＋１）で更新し、先頭情報が先頭セグメントの次のセグメントを示すように変更する（ステップ５１０）。次に初期化部１５８は先頭情報を変更した第１テーブルが最後の第１テーブルか否か、すなわち先頭情報を変更していない第１テーブルが他に残っていないか確認する（ステップ５１５）。ステップ５１５でＮＯの場合処理はステップ５０５に戻る。一方第１テーブルの対応する全てのポインタビュー・レジスタ１９４について処理を終えた場合（ステップ５１５：ＹＥＳ）、初期化部１５８は、第２テーブル１８５に対応するポインタビュー・レジスタ１９４を更新する（ステップ５２０）。そして処理は終了する。なお先頭情報は先頭セグメントの数個先のセグメントを示すよう変更してもよい。

次に、本発明の第２実施形態に係る処理システムを含むストレージ装置を説明する。第２実施形態に係る処理システムは、第１実施形態に係る処理システムに新たな機能を追加したものである。追加される機能は、データの途中から上書きを行う場合に起こりえる、第１テーブルの終了ステータスの不連続を防ぐためのものである。そこでまず始めに上書き処理の際に起こりえる第１テーブルの終了ステータスの不連続について図１４及び図１５を参照して説明する。

図１４は上書き処理を行う場合に終了ステータスが不連続となる場合の一例を示す。上述したように本願発明の初期化部１５８は、リングバッファ１０５がＦＵＬＬになる前に、複数の第１テーブルのそれぞれの先頭情報を、先頭のセグメントの次のセグメント又は数個先のセグメントを示すように変更し、先頭部分のいくつかのセグメントのステータスをクリアする。図１４（ａ）は、直前の書込み又は読み出し処理によりセグメントＮ−２までデータが転送されてリングバッファ１０５がＦＵＬＬに近くなり、そのためセグメントＮ−１及びセグメントＮのステータスがクリアされた状態を示す。

ここでセグメントＮ−２へのデータ転送により書込み又は読み出し処理が終了し、次に上書きが行われるとする。上書きを行う場合、ホスト装置はストレージ装置に上書きのための位置合わせ（Ｌｏｃａｔｅ）コマンドを送信する。Ｌｏｃａｔｅコマンドを受信したストレージ装置の制御部１６０は、リングバッファ１０５上で上書き位置を探し、上書き処理を行う。上書き位置として例えばセグメントＮが決定されると、新たに書込み処理を開始するためセグメントＮ＋１以降のステータスが初期化される（図１４（ｂ）参照）。ところが、理由は図１５を参照して後述するが、上書きの開始位置によってはセグメントＮのステータスを一時的に図１４（ｃ）に示すように変更しなければならない。しかし図１４（ｃ）をみるとわかるように、このようなセグメントＮのステータスの変更は、一時的であれ終了ステータスの不連続をもたらす。

ところでストレージ装置では、ホスト装置から送信されたデータをリングバッファ１０５に格納する前にＥＣＣを付加しデータを保護することが多い。図１５（ａ）に、２次元のＥＣＣで保護されるデータを示す。データはｍ行×ｎ列に配列され、行方向には行誤り訂正符号（以下Ｃ１ＥＣＣと呼ぶ）が、列方向には列誤り訂正符号（以下、Ｃ２ＥＣＣと呼ぶ）が付加される。ところが上書き処理は上述したようにリングバッファ１０５上で行われるため、リングバッファ１０５に格納される前に付加されるＣ１ＥＣＣとの関係で上書きの開始位置が問題となる。なお、Ｃ２ＥＣＣの計算は、上述した第３処理部１６５により上書き処理後に行われるため問題ない。

上書き開始位置が、Ｃ１ＥＣＣが付加される単位データ（以下Ｃ１ＥＣＣコードワードと呼ぶ）４２０の先頭である場合（図１５（ａ）の番号４２５参照）、Ｃ１ＥＣＣは上書きデータのみを用いて計算すればよいので問題ない。しかし上書き開始位置がＣ１ＥＣＣコードワード４３０の途中である場合（図１５（ａ）の番号４３５参照）、本来であればＣ１ＥＣＣは上書き開始位置までの既存のデータとそれ以降の上書きデータとを用いて計算するべきであるが、上述したようにＣ１ＥＣＣの計算及び付加は上書き処理の前に行われる。その結果Ｃ１ＥＣＣの不整合がおきる。

そこでこのようなＣ１ＥＣＣの不整合を防ぐために、上書き開始位置がＣ１ＥＣＣコードワードの途中となる場合は次のような処理を行う。すなわち、本来データの上書きは書き込みの一種であるが、図１５（ｂ）に示すように上書き開始位置を含むＣ１ＥＣＣコードワード４３０を一旦読み出し方向４４５に戻し、Ｃ１ＥＣＣエンコーダ４４０の手前ＳＲＡＭに読み出す。そして図１５（ｃ）に示すように、ＳＲＡＭ上で第１処理部（図３参照）から管理部４５５へ送られたデータを用いてＣ１ＥＣＣコードワード４３０に対し上書き処理を行う。Ｃ１ＥＣＣエンコーダ４４０には上書き処理後のＣ１ＥＣＣコードワード４６０を入力する。このように途中に上書き開始位置をもつＣ１ＥＣＣコードワードについてはＣ１ＥＣＣを計算しなおすことでＣ１ＥＣＣの不整合を防ぐ。

ところでリングバッファ４５０に格納されているＣ１ＥＣＣコードワード４３０を、一旦Ｃ１ＥＣＣエンコーダ４４０手前のＳＲＡＭまで読み戻すためには、Ｃ１ＥＣＣコードワード４３０を含むセグメントの終了ステータスを第４処理部１７０、第３処理部１６５、第２処理部１５０（各々図３参照）について立てる必要がある。これは一連の処理の処理状況を示すステータスによってハードウェアの動きが制御されるからである。そのため、図１４を参照して説明した状況において、上書きの開始位置がセグメントＮに含まれるＣ１ＥＣＣコードワードの途中であるような場合は、セグメントＮのステータスを一時的に「００００」から「０１１１」に変更する必要がある。しかしこの変更は、上述したように終了ステータスの不連続をもたらす。そこで本発明の第２実施形態に係る処理システムは、このような終了ステータスの不連続をなくすための新たな機能を追加する。

図１６は、本発明の第２実施形態に係る処理システム５００の構成の一例を示す。上述したように
第２実施形態に係る処理システム５００は、第１実施形態に係る処理システム１００に新たな機能を提供する構成要素を追加したものである。そこで図１６には新規に追加した構成要素とその構成要素に直接関係する構成要素のみを示した。説明もこれらについてのみ行う。なお同じ構成要素であっても図１６では図３また図１５とは異なる番号を付けた。第２実施形態に係る処理システム５００の管理部５１０は、更にＣ１エンコーダ５２５と、Ｃ１エンコーダ用バッファ５３０と、上書きステートマシーン５２０とを含む。また第２実施形態に係る処理システム５００の管理部５１０は、ＶＲＢＳＲ５３５は、マスク部５５５を更に含む。

Ｃ１エンコーダ５２５は、第１処理部（図３参照）による処理を経て管理部５１０へ送られるホスト装置からのデータをリングバッファ５０５に格納する前に、データにＣ１ＥＣＣを付加する。Ｃ１エンコーダ用バッファ５３０は、第１処理部（図３参照）とＣ１エンコーダ５２５の間に位置し、Ｃ１ＥＣＣを付加する単位データであるコードワードを格納する。コードワードの途中からデータを上書きする場合、上書き開始位置を含むコードワードは、一旦リングバッファ５０５からＣ１エンコーダ用バッファ５３０へ読み戻され、Ｃ１エンコーダ用バッファ５３０上でホスト装置から送信された新しいデータを用いて上書き処理される。

上書きステートマシーン５２０は、記憶媒体（図３参照）に記憶されたデータに上書きを行う場合であって、上書き開始位置がコードワードの途中となる場合に、上書き開始位置を含むコードワードが当該コードワードを格納するリングバッファ５０５のあるセグメントからＣ１エンコーダ用バッファ５３０に転送されるまでの間、上記あるセグメントのステータスをマスクするためのＳｅｔ＿Ｍａｓｋ信号を生成する。マスク部５５５は、Ｓｅｔ＿Ｍａｓｋ信号が生成されている間、セグメント・ステータス生成部５５０により出力される上書き処理のため初期化された上記あるセグメントのステータスを、データ読み出し用のステータスでマスクする。なお、上書き開始位置がコードワードの先頭であるかどうかの判断は、第１カウンタ５１２が現在示しているセグメントに対し、リングバッファのアドレスに基づいてなされる。

上書きステートマシーン５２０はまた、マスク部５５５によるステータスの変更により上書き開始位置を含むコードワードがＣ１エンコーダ用バッファ５３０へ読み戻されると、上記あるセグメントのステータスを元に戻すＣｌｅａｒ＿Ｍａｓｋ信号を生成する。マスク部５５５は、Ｃｌｅａｒ＿Ｍａｓｋ信号に応答してステータスのＭａｓｋを解除する。Ｍａｓｋが解除されると、セグメント・ステータス生成部５５０により出力される初期化された書込み用のステータスに基づき、上書き開始位置を含むコードワードに対し上書き処理が開始される。

図１７は、上述した上書きステートマシーン５２０の各状態とその遷移を示す。Ｑ０の「アイドル」状態は、上書きステートマシーン５２０の通常の状態である。上書き処理以外の処理が行われている場合、または上書き処理が行われている場合であっても上書き開始位置がコードワードの先頭であるときは、上書きステートマシーン５２０はこの状態にある。

上書き処理が開始され、かつ上書き開始位置がコードワードの途中となる場合、上書きステートマシーン５２０はＱ０からＱ１の「読出し方向切り替え」状態へ遷移する。Ｑ１状態の上書きステートマシーン５２０は、管理部５１０の内部ロジックの方向を書込みから読み出し方向に切り替えると同時に、第１カウンタ５１２が現在示しているセグメントに対し、ステータスを読み出し用のステータスでマスクするためのＳｅｔ＿Ｍａｓｋ信号を生成する。

図１８（ａ）に、上書きステートマシーン５２０がＱ１の状態にあるときの処理システム５００の一部を示す。上書きは書き込みの一種であるため上書き処理が開始されると、複数の第１テーブルは、上書き開始位置以降のデータを含むセグメントのステータスを初期化するように更新される。そのため複数の第１テーブルに基づいてステータスを生成するセグメント・ステータス生成部５５０は、第１カウンタ５１２が示すセグメントに対し“００００”のステータスを生成する。

一方、上書きステートマシーン５２０が生成するＳｅｔ＿Ｍａｓｋ信号は、ＶＲＢＳＲ５３５のマスク部５５５に入力される。マスク部５５５はＳｅｔ＿Ｍａｓｋ信号に応答して、第１カウンタ５１２が示すセグメントに対し、読み出し用のステータス、“０１１１”を生成する。そしてマスク部５５５はセグメント・ステータス生成部５５０により生成されたステータス“００００”を、読み出し用のステータス“０１１１”でマスクする。

ここで読み出し用のステータス、“０１１１”について説明する。この４ビット信号は左端ビットから順に、図３に示す第１処理部、第２処理部、第３処理部、第４処理部の処理のステータスを割り当てられている。値１は処理が終了していることを、値０はまだ処理が終了していないことを示す。第１実施形態の説明で上述したように、次のセグメントに対する各処理部の処理の開始条件は、次のセグメントについてそれ自体の処理は終了しておらず、かつその１つ前の処理部による処理が終了していることである。開始条件が満たされたときに次のセグメントの単位データはその処理部へ転送される。従って読み出し用のステータス“０１１１”は第１処理部の開始条件を満たし、リングバッファ５０５から第１処理部への、従ってリングバッファ５０５からＣ１エンコーダ用バッファ５３０へのデータ転送が開始される。

図１７に戻って、上書きステートマシーン５２０はＱ１状態から無条件でＱ２の「読出し処理開始」状態へ遷移し、その後Ｑ３の「読出し終了待ち」状態へ遷移する。上書きステートマシーン５２０がＱ２状態になると、上書き開始位置を含むコードワードのＣ１エンコーダ用バッファ５３０への転送が開始され、上書きステートマシーン５２０はＱ３状態へ遷移して上書き開始位置を含むコードワードの転送が終了するのを待つ。

転送が完了すると、上書きステートマシーン５２０はＱ４の「書込み方向切り替え」状態へ遷移する。Ｑ４状態の上書きステートマシーン５２０は、管理部５１０の内部ロジックの方向を元の書込み方向に切り替えると同時に、第１カウンタ５１２が現在示しているセグメントに対し、ステータスを元の書込み用のステータスに戻すためのＣｌｅａｒ＿Ｍａｓｋ信号を生成する。

図１８（ｂ）に、上書きステートマシーン５２０がＱ４の状態にあるときの処理システム５００の一部を示す。上書きステートマシーン５２０が生成するＣｌｅａｒ＿Ｍａｓｋ信号は、ＶＲＢＳＲ５３５のマスク部５５５に入力される。マスク部５５５はＣｌｅａｒ＿Ｍａｓｋ信号に応答して、セグメント・ステータス生成部５５０により生成されたステータス“００００”のマスクを解除する。

図１７に戻って、上書きステートマシーン５２０はＱ４状態から無条件でＱ５の「上書き開始位置設定」状態へ遷移し、その後上書きステートマシーン５２０はＱ６の「書込み処理開始」状態へ遷移する。上書きステートマシーン５２０がＱ５状態になると、リングバッファ５０５上の上書き開始位置であるアドレスがＣ１エンコーダ用バッファ５３０にコピーされ、Ｃ１エンコーダ用バッファ５３０に対し上書き開始位置がセットされる。その後上書きステートマシーン５２０がＱ６状態へ遷移すると、セグメント・ステータス生成部５５０により出力される初期化された書込み用のステータス“００００”に基づき、上書き開始位置を含むコードワードに対し上書き処理が開始される。最後に上書きステートマシーン５２０はＱ６状態から無条件でＱ０の「アイドル」状態へ戻る。

次に、本発明に係る処理システム１００の実装例を図１９乃至図２１を参照して説明する。図１９は、一連の処理を行う複数の処理部を除いた処理システム１００の実装例を示す。図１９において、データバッファはリングバッファに対応し、バッファ・マネージャ（ＢＭＧ）は管理部に対応する。管理部の第１カウンタ、第１開始判断部、第１データ転送部及び第１更新部はホスト側回路として実現され、同様に、第３カウンタ、第３開始判断部、第３データ転送部及び第３更新部はＥＣＣ側回路、第４カウンタ、第４開始判断部、第４データ転送部及び第４更新部はテープ側回路として実現される。また、第２カウンタ及び第２データ転送部はＭＰＵインターフェース部として実現される。ＢＭＧの各回路及びＭＰＵインターフェース部は内部に処理対象である現在のセグメントを指すポインタをもつ。

ＶＲＢＳＲの複数の第１テーブル及び第２テーブル、セグメント・ステータス生成部、マスク部は、それぞれテーブル回路、ＲＢＳＲ選択回路、マスク回路として実現される。またＶＲＢＳＲのアクセス制御部は、テーブルアクセス制御部としてハードウェアとソフトウェアの協働により実現される。更にポインタビュー・レジスタ及びセグメントビュー・レジスタは、複数のレジスタにより実現される。

図１９において矢印はデータの流れを示す。ＢＭＧの各回路の現在のセグメントを指すポインタは、それぞれＲＢＳＲ選択回路へ入力される。ＲＢＳＲ選択回路はテーブル回路からの信号に基づき、入力された現在のセグメントに対するステータスを求め、ＢＭＧの各回路へ返す。ＢＭＧの各回路は受け取ったステータスに基づき、現在のセグメントの単位データの転送開始の可不可を判断する。単位データの転送が完了するとＢＭＧの各回路は、現在のセグメントを指すポインタと完了を知らせる信号とをテーブルアクセス制御部へ入力する。テーブルアクセス制御部はＢＭＧの各回路から受け取った完了の通知により現在のセグメントについてテーブルを更新することが適当であるか判断する。テーブルアクセス制御部は適切と判断した場合は、テーブル回路へ更新情報を入力する。一方不適切と判断した場合は、テーブルアクセス制御部はエラー信号を生成する。

制御部に対応するＭＰＵは、ＭＰＵインターフェースを介して現在のセグメントのポインタの値を読み出し、その値に対応するセグメントビューのレジスタ値を読み取ることにより、現在のセグメントのステータスを得る。そして取得したステータスに基づき、ＭＰＵは現在のセグメントの単位データの転送開始の可不可を判断する。現在のセグメントの単位データの転送が完了すると、ＭＰＵはポインタビュー・レジスタを介してテーブル回路へ更新情報を入力する。なお、セグメントビュー・レジスタの値は、ＭＰＵがウィンドウ用レジスタ（図示しない）にウィンドウを指定するとその値がウィンドウに含まれる複数のセグメントを指すアドレスの一部としてＲＢＳＲ選択回路に伝えられ、ＲＢＳＲ選択回路により設定される。設定されたセグメントビュー・レジスタの値は、ＭＰＵより読み出され、または変更される

図２０は、図１９に示すＶＲＢＳＲのより詳細な実装例を示す。テーブル回路は、複数の第１テーブルにそれぞれ対応する、ホスト回路、ＤＳＩＴ回路、ＥＣＣ回路、ＴＡＰＥ回路と、第２テーブルに対応するゼロ回路とからなる。ホスト回路、ＥＣＣ回路、ＴＡＰＥ回路はテーブルアクセス制御部を介してそれぞれホスト側回路、ＥＣＣ側回路、テープ側回路から信号を入力される。またホスト回路、ＤＳＩＴ回路、ＥＣＣ回路、ＴＡＰＥ回路、ゼロ回路の全ての回路は、ステータスを読み出しまた書き込むためにポインタビュー・レジスタを介して又はセグメントビュー・レジスタを介してＭＰＵによりアクセスされる。

ＲＢＳＲ選択回路は、ホスト回路、ＤＳＩＴ回路、ＥＣＣ回路及びＴＡＰＥ回路からの入力信号に基づき、ＢＭＧの各回路により指定されたセグメントに対するステータスを生成する。生成されたステータスは転送制御信号としてＢＭＧの各回路へ返され、またはセグメントビュー・レジスタに設定される。マスク回路は、入力されるＳｅｔ＿Ｍａｓｋ信号及びＣｌｅａｒ＿Ｍａｓｋ信号に基づき、ＲＢＳＲ選択回路が生成するステータスをマスクする。

図２１は、図１９に示すＢＭＧのより詳細な実装例を示す。ＢＭＧを構成する各回路は、それぞれ対応する処理部に接続される。すなわちホスト側回路は第１処理部に相当する圧縮エンジンに、ＥＣＣ回路は第３処理部に相当するＥＣＣエンジンに、テープ側回路は第４処理部に相当するＦｏｍａｒｔに、そしてＭＰＵインターフェースは第２処理部としての機能を提供するＭＰＵに接続される。ＢＭＧの各回路はまた、内部に転送制御回路をもつ。転送制御回路にはＲＢＳＲ選択回路から返される転送制御信号が入力され、転送制御回路により現在のセグメントの単位データの転送開始の可不可が判断される。転送制御回路により単位データの転送が可能と判断されると、ＢＭＧの各回路はデータバッファから現在のセグメントの単位データを読み出し、対応する処理部へ転送する。

図２３は、本発明に係る処理システムを含むストレージ装置７００のハードウェア構成の一例を示す。ストレージ装置７００は、本発明に係る処理システムを実現するＡＳＩＣ７０５と、コントローラ７１０と、記録チャネル７３０と、ヘッド位置制御システム７３５と、モータドライブ７４０と、モータ７４５と、テープ７５０と、ヘッド７５５と、リール７６０Ａ、Ｂを含む。ＡＳＩＣ７０５が実現するインターフェースは、ホスト装置と通信を行う。インターフェースは、ホスト装置から、ユーザデータのテープ７５０への書込みを指示するコマンドを受け取る。例えばインターフェースの通信の規格がＳＣＳＩの場合、コマンドはＷｒｉｔｅコマンドに相当する。バッファは、テープ７５０に書き込むべきデータを蓄積するメモリ、例えばＤＲＡＭである。データは、任意の長さでホスト１０５からドライブに転送される。

テープ７５０は、データの記録手段としてのテープ媒体である。記録チャネル７３０を介して渡されたデータは、データセット単位（例えば４００ＫＢ）でヘッド７５５によりテープ７５０に書込まれる。テープ７５０は、リール７６０Ａ及び７６０Ｂに巻かれ、これらの回転に伴い、リール７６０Ａからリール７６０Ｂの方向へ、又は、その反対の方向へ、縦方向に移動する。モータ７４５は、リール７６０Ａ及び７６０Ｂを回転させる。

コントローラ７１０は、ストレージ装置７００の全体を制御する。コントローラ７１０は、ホスト装置からインターフェースで受け付けたコマンドに従って、データのテープ７５０への書込み読取りを制御する。また、コントローラ７１０は、ヘッド位置制御システム７３５やモータドライブ７４０の制御も行う。ヘッド７５５は、トラックを切り換える必要が生じると、ヘッド位置制御システム７３５が、ヘッド７５５を電気的に切り換えの制御を行う。また、コントローラ７１０は、ＡＳＩＣ７０５、記録チャネル１３０おける（書込み及び読込み）データの監視を行なう。モータドライブ７４０は、直接コントローラ７１０に接続されていてもよい。

コントローラ７１０はＭＰＵ７１５、ＲＯＭ７２０、ＲＡＭ７２５により構成される。ＲＯＭ７２０は、ストレージ装置７００の起動時にＭＰＵ７１５が実行するブートプログラムや、起動後にストレージ装置７００を動作させるプログラムを格納する。またＲＯＭ７２０は、コントローラ７１０を、図３を参照して説明した第２処理部１５０、第２開始判断部１５２、第２更新部１５４、初期化部１５８及び調整部１５９として機能させるためのプログラムも格納する。そしてＭＰＵ７２０は、これらのプログラムを、ＲＡＭ７２５を用いて実行する。

以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。このように上記の実施形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。

ＬＴＯテープドライブの一連の処理の各段階におけるデータのフォーマットを示す。 (a)は、セグメント数に等しい数のレジスタを用いた従来の一連の処理ののステータス管理方法を示す。（ｂ）は、従来のステータス管理方法におけるレジスタのビットの割り当てを示す。 本発明の第１実施形態に係る処理システム１００の構成の一例を示す。 （ａ）は、本発明に係る複数の第１テーブルの一例を示す。（ｂ）は、（ａ）に対応する、従来のセグメント数に等しいステータスレジスタを示す。（ｃ）は、本発明に係る第２テーブルの一例を示す。 本発明に係るポインタビュー・レジスタとセグメントビュー・レジスタの一例を示す。 （ａ）は、第１処理部１４５に対する管理部１１０のデータ書込み時の処理の流れの一例を示すフローチャートを示す。（ｂ）は、第３処理部１６５及び第４処理部１７０に対する管理部１１０のデータ書込み時の処理の流れの一例を示すフローチャートを示す。 セグメント・ステータス生成部１９２のデータ書込み時の処理の流れの一例を示すフローチャートを示す。 管理部１１０の任意の更新部に対するアクセス制御部１９０のデータ書込み時の処理の流れの一例を示すフローチャートを示す。 （ａ）は、終了ステータスを新たに立てる際の複数のセグメントの処理状況の一例を示す。（ｂ）は、更新前の第１テーブルを示す。（ｃ）は、更新後の第１テーブルを示す。 （ａ）は、セグメントビュー・レジスタ１９６を使用して特定のセグメントの終了ステータスをクリアする制御部１６０の処理の流れの一例を示すフローチャートを示す。（ｂ）は、セグメントビュー・レジスタ１９６を使用して特定のセグメントの終了ステータスをクリアするアクセス制御部１９０の処理の流れの一例を示すフローチャートを示す。 （ａ）は、終了ステータスをクリアする際の複数のセグメントの処理状況の一例を示す。（ｂ）は、更新前の第１テーブルを示す。（ｃ）は、更新後の第１テーブルを示す。 ポインタビュー・レジスタ１９４を使用して特定の第１テーブルの終了ステータスをクリアする制御部１６０の処理の流れの一例を示すフローチャートを示す。 初期化部１５８による処理の流れの一例を示すフローチャートを示す。 （ａ）は、上書き処理を行う場合に終了ステータスが不連続となる場合の一例を示す。（ｂ）は、上書き処理を行う場合に終了ステータスが不連続となる場合の一例を示す。（ｃ）は、上書き処理を行う場合に終了ステータスが不連続となる場合の一例を示す。 （ａ）は、２次元のＥＣＣで保護されたデータを示す。（ｂ）は、上書きする際の前処理を示す。（ｃ）は、上書き処理を示す。 本発明の第２実施形態に係る処理システム１００の構成の一例を示す。 本発明に係る上書きステートマシーンの状態遷移を示す。 （ａ）は、ステータスをマスクする際の本発明の第２実施形態に係る処理システム１００を示す。（ｂ）マスクを解除する際の本発明の第２実施形態に係る処理システム１００を示す。 本発明に係る処理システム１００の実装例を示す。 本発明に係るＶＲＢＳＲの実装例を示す。 本発明に係る管理部の実装例を示す。 本発明に係るストレージ装置と、ホスト装置とを含むシステムの構成の一例を示す。 本発明に係るストレージ装置のハードウェア構成の一例を示す。

Claims (11)

1. 処理システムであって、
   前記処理システムに入力されるデータを入力順に処理単位でそれぞれ格納する複数のセグメントからなるバッファと、
   前記データに対し、一連の処理を所定の順序で施す複数の処理部と、
   前記複数の処理部にそれぞれ対応する複数の第１テーブルであって、対応する前記処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する前記処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する前記複数の第１テーブルと、
   前記複数の第１テーブルにより保持される前記一連の処理の処理状況に基づき、前記一連の処理が前記所定の順序で行われるように前記バッファと前記複数の処理部の間のデータ転送を管理する管理部と
   を含む処理システム。
2. 前記処理システムは、前記セグメントを指定した前記一連の処理の処理状況の問い合わせに応答して、前記複数の第１テーブルを参照して指定された前記セグメントに対する処理状況を生成するステータス生成部を含み、前記管理部は、前記複数の処理部のそれぞれについて、次に処理対象となる前記セグメントを指定して前記ステータス生成部に処理状況を問い合わせ、当該処理状況が前記処理部の処理の開始条件を満たすか否かを判断することにより、前記バッファと前記複数の処理部の間のデータ転送を管理する、請求項１に記載の処理システム。
3. 前記管理部は、前記次に処理対象となるセグメントに対する前記一連の処理の処理状況が、処理の開始条件を判断する対象の処理部による処理が終了しておらず、かつ１つ前の処理部による処理が終了していることを示すこと条件に、前記開始条件を判断する対象の処理部へ前記次に処理対象となるセグメントの単位データを転送する、請求項２に記載の処理システム。
4. 前記管理部は、前記各処理部による処理の終了に応答して対応する前記第１テーブルを更新し、前記処理システムは、任意の前記第１テーブルの前記先頭情報により示される先頭のセグメントと前記末尾情報により示される末尾のセグメントの間に、前記対応する処理部による処理が未処理のセグメントが存在することになるような更新を検知しエラー信号を生成するアクセス制御部を含む、請求項１に記載の処理システム。
5. 前記アクセス制御部は、任意の前記第１テーブルの更新の前後で前記先頭情報及び前記末尾情報が変化しないような更新を検知しエラー信号を生成する、請求項４に記載の処理システム。
6. 前記バッファはリングバッファであり、前記処理システムは制御部を含み、当該制御部は、前記リングバッファのすべてのセグメントにデータが書き込まれる前に、前記複数の第１テーブルのそれぞれの前記先頭情報を、前記先頭のセグメントの１以上先のセグメントを示すように変更する、請求項１に記載の処理システム。
7. データを所定の単位で書込み及び読出し可能な記憶媒体と、
   前記記憶媒体への書込み前及び前記記憶媒体からの読出し後に、前記所定の単位の単位データを書込み順又は読出し順にそれぞれ格納する複数のセグメントからなるバッファと、
   前記単位データに対し一連の処理を所定の順序で施す複数の処理部と、
   前記複数の処理部にそれぞれ対応する複数の第１テーブルであって、対応する前記処理部による処理が終了した連続するアドレスの複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び対応する前記処理部による処理が終了したセグメントの有無を示す存在情報をそれぞれ格納する前記複数の第１テーブルと、
   前記複数の第１テーブルにより保持される前記一連の処理の処理状況に基づき、前記一連の処理が前記所定の順序で行われるように前記バッファと前記複数の処理部の間のデータ転送を管理する管理部と
   を含む、ストレージ装置。
8. 前記ストレージ装置は、前記セグメントを指定した前記一連の処理の処理状況の問い合わせに応答して、前記複数の第１テーブルを参照して指定された前記セグメントに対する処理状況を生成するステータス生成部を含み、前記管理部は、前記複数の処理部のそれぞれについて、次に処理対象となる前記セグメントを指定して前記ステータス生成部に処理状況を問い合わせ、当該処理状況が前記処理部の処理の開始条件を満たすか否かを判断することにより、前記バッファと前記複数の処理部の間のデータ転送を管理する、請求項７に記載の処理システム。
9. 前記複数の処理部による処理が１つも終了していない連続するアドレスの複数のセグメントにおいて、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報、及び複数の処理部による処理が１つも終了していないセグメントの有無を示す存在情報を格納する第２テーブルと、前記第２テーブルを参照して前記記憶媒体へのデータ書込み又はデータ読出しのスピードを調整する調整部とを含む、請求項７に記載のストレージ装置。
10. 前記管理部は、前記バッファにデータを書き込む前にデータに行誤り訂正符号を付加するエンコーダと、当該行誤り訂正符号を付加する単位データであるコードワードを格納するエンコーダ用バッファと、前記記憶媒体に記憶された前記コードワードに対しその途中から上書きを行う場合に、途中から上書きされる前記コードワードが当該コードワードを格納する前記バッファのあるセグメントから前記エンコーダ用バッファに転送されるまでの間信号を生成する上書きステートマシーンとを含み、前記ストレージ装置は、前記信号が生成されている間、前記ステータス生成部より出力される上書き処理のため初期化された前記あるセグメントの処理状況をデータ読み出し用の処理状況でマスクするマスク部を含む、請求項８に記載のストレージ装置。
11. バッファの各セグメントに格納される単位データに対し一連の処理を所定の順序で行うための方法であって、
    前記一連の処理を実行する複数の処理部の各々は、当該処理部による処理が終了したアドレスの連続する複数のセグメントのうち、先頭のセグメントを示す先頭情報、末尾のセグメントを示す末尾情報及び前記処理部による処理の終了したセグメントの有無を示す存在情報を格納する対応する第１テーブルを有し、
    複数の前記第１テーブルを参照して、前記複数の処理部のそれぞれにおいて次に処理対象となるセグメントの処理状況を生成するステップと、
    前記次に処理対象となるセグメントの前記処理状況が、前記複数の処理部のそれぞれの処理の開始条件を満たすか否かを判断するステップと、
    判断するステップにおいて処理の開始条件が満たされると判断したことに応答して、前記バッファの前記次に処理対象となるセグメントから前記単位データを読出し判断対象の処理部へ転送するステップと
    を含む、一連の処理を所定の順序で行うための方法。

Images