JP3696740B2 - チャネルインタフェース再結合制御方法およびファイル制御装置 - Google Patents
チャネルインタフェース再結合制御方法およびファイル制御装置 Download PDFInfo
- Publication number
- JP3696740B2 JP3696740B2 JP34635798A JP34635798A JP3696740B2 JP 3696740 B2 JP3696740 B2 JP 3696740B2 JP 34635798 A JP34635798 A JP 34635798A JP 34635798 A JP34635798 A JP 34635798A JP 3696740 B2 JP3696740 B2 JP 3696740B2
- Authority
- JP
- Japan
- Prior art keywords
- recombination
- order
- tcb
- report
- busy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
- G06F3/0611—Improving I/O performance in relation to response time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
（目次）
発明の属する技術分野
従来の技術（図２３〜図４６）
発明が解決しようとする課題
課題を解決するための手段
発明の実施の形態（図１〜図２２）
発明の効果
【０００１】
【発明の属する技術分野】
本発明は、複数の処理装置が、ファイル制御装置を介して複数のファイル記憶装置を共用する際に適用される技術に関し、特に、ある処理装置がファイル記憶装置にアクセスした際に直ちにそのファイル記憶装置にアクセスできず処理装置とファイル制御装置との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する方法、および、この方法を実現するためのファイル制御装置に関する。
【０００２】
【従来の技術】
複数の処理装置が複数のファイル記憶装置を共用する際、一般に、これらの処理装置とファイル記憶装置との間には、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置がそなえられている。ここで、処理装置は、例えばＣＰＵであり、ファイル記憶装置は、例えば磁気ディスク等のデバイス（ＤＡＳＤ：Direct Access Storage Device）である。なお、以下、ファイル制御装置についてはＦＣＵと略記し、ファイル記憶装置については単にデバイスと呼ぶ場合がある。
【０００３】
このようにＦＣＵをそなえたシステムにおいて、ＣＰＵは、他のＣＰＵと共用する各デバイスのデータを読み出したり、各デバイスにデータを書き込んだりするために、まず、リザーブコマンドで他のＣＰＵからのアクセスを排他し、デバイスの占有が確立したところで、リードコマンドあるいはライトコマンドを発行する。
【０００４】
ＦＣＵは、共用デバイスであり、あるＣＰＵがデバイスを占有すると、以降、他のＣＰＵからのコマンドに対してデバイスビジーを報告し、他のＣＰＵを切り離す一方、リザーブコマンドを発行したＣＰＵからのリリースコマンドでデバイスが占有状態から解放されると、デバイスビジーを報告した他のＣＰＵ（チャネル）に再結合を行なう（リリースによるデバイスエンド割込み：第１の再結合要因）。
【０００５】
また、リードコマンド処理時もしくはライトコマンド処理時に、磁気ディスクの動作（ステージング動作）を伴う場合は、ＦＣＵは、一旦、リードコマンドもしくはライトコマンドを発行したＣＰＵの切り離しを行ない、磁気ディスクのステージング動作が終了した時点でＣＰＵ（チャネル）との再結合を行なう（ステージング完了によるデバイスエンド割込み：第２の再結合要因）。なお、ステージング動作とは、リード対象もしくはライト対象のデータがＦＣＵ内のキャッシュメモリ上に存在しない場合に、そのデータを保有するデバイスからキャッシュメモリ上へ読み出す動作である。
【０００６】
ここで、図２３を参照しながら、一般的なＦＣＵの構成について説明する。図２３は一般的なＦＣＵの構成を示すブロック図で、この図２３に示すように、ＦＣＵ１は、複数（図２３中では２台）のＣＰＵ２−０，２−１が複数（図２３中では３台）のデバイス３−０〜３−２を共用すべく、これらのＣＰＵ２−０，２−１とデバイス３−０〜３−２との間にそなえられ、各ＣＰＵ２−０，２−１からのコマンドに応じて各デバイス３−０〜３−２に対するアクセス動作を制御するものである。なお、２つ存在するＣＰＵのうちの一つを特定する場合には、符号２−０，２−１を用いる一方、特定する必要のない場合には符号２を用いる。同様に、３つ存在するデバイスのうちの一つを特定する場合には、符号３−０〜３−２を用いる一方、特定する必要のない場合には符号３を用いる。
【０００７】
このＦＣＵ１は、ＣＡ(Channel Adapter）１１−０〜１１−３，ＲＭ(Resource Manager)１２，ＴＳ（Table Storage)１３，ＣＦＥ（Cache Function Engine)１４，キャッシュメモリ１５，ＤＡ(Device Adapter)１６−０〜１６−２，コマンドバス１７およびデータバス１８を有して構成されている。なお、４つ存在するＣＡのうちの一つを特定する場合には、符号１１−０〜１１−３を用いる一方、特定する必要のない場合には符号１１を用いる。同様に、３つ存在するＤＡのうちの一つを特定する場合には、符号１６−０〜１６−２を用いる一方、特定する必要のない場合には符号１６を用いる。
【０００８】
ここで、ＣＡ１１−０〜１１−３は、それぞれ、チャネルインタフェースを介してＣＰＵ２−０もしくは２−１とのインタフェース制御を担当するモジュールである。なお、ＣＰＵ２−０，２−１は、例えば２つのチャネル（ＣＨ）２ａ，２ｂを有しており、図２３に示す例では、ＣＰＵ２−０のチャネル２ａ，２ｂがそれぞれＣＡ１１−０，１１−１に接続され、ＣＰＵ２−１のチャネル２ａ，２ｂがそれぞれＣＡ１１−２，１１−３に接続されている。
【０００９】
ＲＭ１２は、基本動作に関する資源管理を担当するモジュールであり、ＴＳ１３は、資源管理用のテーブルとして使用されるメモリである。これらのＲＭ１２およびＴＳ１３は、図２４〜図４６を参照しながら後述するごとく、２つのＣＰＵ２−０，２−１のうちの一つが３つのデバイス３−０〜３−２のうちの一つにアクセスした際に直ちにそのＣＰＵ２がデバイス３にアクセスできずそのＣＰＵ２との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する制御部として機能する。
【００１０】
また、ＣＦＥ１４は、キャッシュメモリ１５の管理を担当するモジュールであり、ＤＡ１６−０〜１６−２は、それぞれ、磁気ディスク等のデバイス３−０〜３−２とのインタフェース制御を担当するモジュールである。
さらに、コマンドバス１７は、ＣＡ１１，ＲＭ１２，ＣＦＥ１４，ＤＡ１６の間でコマンドのやり取りを行なうためのものであり、データバス１８は、ＣＡ１１，ＣＦＥ１４，キャッシュメモリ１５，ＤＡ１６の間でデータのやり取りを行なうためのものである。
【００１１】
ついで、図２４〜図２９を参照しながら、チャネルインタフェースの再結合を制御するＲＭ１２およびＴＳ１３の機能的な構成について説明する。図２４は従来のＲＭ１２／ＴＳ１３の機能的な構成を示すブロック図、図２５〜図２９はそれぞれリザーブ管理テーブル３１，デバイスビジー報告管理テーブル３２，デバイスエンド報告管理テーブル３３，タスク制御ブロック（ＴＢＣ）３４およびステージング完了報告管理テーブル（キュー）３５を説明するための図である。
【００１２】
図２４に示すように、ＴＳ１３は、リザーブ管理テーブル３１，デバイスビジー報告管理テーブル３２，デバイスエンド報告管理テーブル３３，ＴＣＢ３４およびステージング完了報告管理テーブル３５を保持するものであり、ＲＭ１２は、ＴＳ１３のデバイスビジー報告管理テーブル３２およびデバイスエンド報告管理テーブル３３を用いて、前述した第１の再結合要因の発生時に再結合処理を実行する機構（デバイスリリースによる再結合機構）として機能する。また、ＲＭ１２は、ＴＳ１３のステージング完了報告管理テーブル３５を用いて、前述した第２の再結合要因の発生時に再結合処理を実行する機構（ステージング完了による再結合機構）としても機能する。
【００１３】
リザーブ管理テーブル３１は、図２５に示すように構成され、ＣＰＵ２により占有されているデバイス３を管理するためのものである。なお、テーブル３１において、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行され、デバイス３−０を占有することができた場合、ＲＭ１２は、テーブル３１における“ＣＡ０”とデバイス番号０との交点位置に“１”を設定する（図３６参照）。
【００１４】
デバイスビジー報告管理テーブル３２は、図２６に示すように構成され、ＲＭ１２がＣＡ１１を通じてデバイスビジーを報告したＣＰＵ２と、そのＣＰＵ２が占有しようとしたデバイス３とを管理するためのものである。なお、テーブル３２においても、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行された場合、ＲＭ１２は、デバイスビジー報告を行なってからＣＰＵ２−１のチャネル２ａを切り離すようにＣＡ１１−２を制御するとともに、テーブル３２における“ＣＡ２”とデバイス番号０との交点位置に“１”を設定する（図３８参照）。
【００１５】
デバイスエンド報告管理テーブル３３は、図２７に示すように構成され、ＲＡ１２がＣＡ１１を通じてデバイスエンドを報告すべきＣＰＵ２を管理するためのものである。なお、テーブル３３においても、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくデバイスビジーが報告されＣＰＵ２−１のチャネル２ａが切り離された後にＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０に対するリリースコマンドが発行されると、ＲＭ１２（再結合機構２１）は、リザーブ管理テーブル３１の登録を抹消するとともに、デバイスビジー報告管理テーブル３２を参照して占有から解放されたデバイス３についてデバイスビジー報告を行なったＣＰＵ２が存在するか否かを確認し、存在する場合、デバイスビジー報告管理テーブル３２のデータをデバイスエンド報告管理テーブル３３にコピーし、デバイスビジー報告管理テーブル３２の登録を抹消する。これにより、テーブル３３における“ＣＡ２”とデバイス番号０との交点位置に“１”が設定される（図４４参照）。ＲＭ１２（再結合機構２１）は、デバイスエンド報告管理テーブル３３を参照し、図３４にて後述するタイミングで、ＣＰＵ２−１のチャネル２ａとの再結合を行なうようにＣＡ１１−２を制御し、デバイスエンド報告を行なう。
【００１６】
ＴＣＢ３４は、図２８に示すように構成され、ＲＭ１２がコマンドに応じたタスクを実行する毎に作成され、そのタスクを終了する際に削除されるもので、そのタスクに関連する情報等を含み、タスクの制御に用いられる。このＴＣＢ３４には、ＣＰＵ２からのコマンドの内容（種別）と、そのコマンドを受け付けたＣＡ１１の番号と、そのコマンドの対象であるデバイス３の番号と、再結合要因とが、タスク毎にタスク番号を付して保持される。ここで、再結合要因としては、リードコマンド／ライトコマンドの処理時にステージング動作に移行した後にそのステージング動作を完了した旨（つまり第２の再結合要因が発生した旨）が保持される。より具体的に、ステージング動作の完了時には、ＲＭ１２により、ＴＣＢ３４の再結合要因として例えば“１”がセットされる。
【００１７】
ステージング完了報告管理テーブル３５は、図２９に示すように構成され、ステージング完了に伴って再結合処理を行なうべきタスクのＴＣＢ番号を管理するためのもので、このテーブル３５には、前述のごとくステージング動作の完了に伴い再結合要因をセットされたタスクのＴＣＢ番号が、ＲＭ１２により再結合順序で登録される（図４６参照）。ＲＭ１２（再結合機構２２）は、ステージング完了報告管理テーブル３５を参照し、図３４にて後述するタイミングで、ステージング完了に伴う再結合処理を行なう。
【００１８】
次に、上述のようなＲＭ１２およびＴＳ１３の詳細な動作について、図３０〜図４６を参照しながら説明する。
まず、図３０〜図３４に示すフローチャートに従って、ＲＭ１２およびＴＳ１３の動作の流れについて説明する。
図３０は、ＲＭ１２がリザーブコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３０に示すように、ＲＭ１２は、リザーブコマンドを受けるとそのリザーブコマンドについてのＴＣＢ３４を作成してから（ステップＡ１１）、リザーブ管理テーブル３１を参照して、そのリザーブコマンドの対象デバイス３が他のＣＰＵ２（他パス，他チャネル）からリザーブされているか否かを判断する（ステップＡ１２）。
【００１９】
他パスからリザーブされていない場合（ステップＡ１２のＮＯルート）、ＲＭ１２は、リザーブコマンドの対象であるデバイス３についてリザーブ処理を行なってから（ステップＡ１３）、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＡ１５）。なお、リザーブ処理に際して、ＲＭ１２は、リザーブ管理テーブル３１において、リザーブ対象のデバイス３のデバイス番号とリザーブコマンドを受け付けたＣＡ１１との交点位置に“１”をセットする。
【００２０】
一方、リザーブコマンドの対象デバイス３が他パスからリザーブされている場合（ステップＡ１２のＹＥＳルート）、ＲＭ１２は、デバイスビジー報告管理テーブル３８にそのリザーブコマンドについて登録し、リザーブコマンド発行元のＣＰＵ２に対してデバイスビジー報告を行なってからそのＣＰＵ２のチャネルインタフェースを切り離すようにＣＡ１１を制御する（ステップＡ１４）。この後、ＲＭ１２は、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＡ１５）。
【００２１】
図３１は、ＲＭ１２がリリースコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３１に示すように、ＲＭ１２は、デバイス３を占有していたＣＰＵ２からリリースコマンドを受けると、そのリリースコマンドについてのＴＣＢ３４を作成してから（ステップＡ２１）、リザーブ管理テーブル３１から対応する登録（“１”の設定）を抹消し、デバイスビジー報告管理テーブル３２に、占有を解放するデバイス３についてデバイスビジー報告を行なった旨が登録されている場合、そのデバイスビジー報告管理テーブル３２の登録情報をデバイスエンド報告管理テーブル３３へ移動する（ステップＡ２２）。この後、ＲＭ１２は、そのリリースコマンドについてのＴＣＢ３４を削除する（ステップＡ２３）。
【００２２】
図３２は、ＲＭ１２がリードコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３２に示すように、ＲＭ１２は、デバイス３を占有しているＣＰＵ２からリードコマンドを受けると、そのリードコマンドについてのＴＣＢ３４を作成してから（ステップＡ３１）、ＣＦＥ１４を介してキャッシュメモリ１５上にリード対象のデータが存在するか否かを判断する（ステップＡ３２）。
【００２３】
キャッシュメモリ１５上にリード対象のデータが存在する場合（ステップＡ３２のＹＥＳルート）、ＲＭ１２は、そのデータをＣＡ１１からＣＰＵ２へ転送してから（ステップＡ３３）、そのリードコマンドについてのＴＣＢ３４を削除する（ステップＡ３４）。
一方、キャッシュメモリ１５上にリード対象のデータが存在しない場合（ステップＡ３２のＮＯルート）、ＲＭ１２は、ＣＡ１１からＣＰＵ２にチャネルエンドを報告し、ＤＡ１６にデバイス３に対するステージングを依頼し、図３３にて説明するステージング完了報告待ち処理へ移行する（ステップＡ３５）。このとき、リードコマンドについてのＴＣＢ３４は削除されることなく保持される。
【００２４】
図３３は、ＲＭ１２のステージング完了報告待ち処理を説明するためのフローチャートであり、この図３３に示すように、ＲＭ１２は、ステージングを依頼したＤＡ１６からのステージング完了報告を待機し（ステップＡ４１）、そのＤＡ１６からステージング完了報告を受けると（ステップＡ４１のＹＥＳルート）、対応するリードコマンドについてのＴＣＢ３４の再結合要因を“ステージング完了”つまり“１”に設定する（ステップＡ４２）。
【００２５】
そして、ＲＭ１２は、ステップＡ４２にて再結合要因をセットしたタスクのＴＣＢ番号を、ステージング完了報告管理テーブル３５に登録して（ステップＡ４３）、ステージング動作で読み出されたデータが、図３４にて後述するアイドルループに従って、ＣＡ１１によりＣＰＵ２へ転送されるのを待機し（ステップＡ４４）、ＣＡ１１がそのデータの転送を完了すると（ステップＡ４４のＹＥＳルート）、ステージング完了報告待ちであったリードコマンドについてのＴＣＢ３４を削除する（ステップＡ４５）。
【００２６】
図３４は、ＲＭ１２のアイドルループによる処理を説明するためのフローチャートであり、この図３４に示すように、ＲＭ１２は、常時、アイドルループにより、ステージング完了報告管理テーブル３５にＴＣＢ番号が登録されているか否か、即ち第２の再結合要因が発生しているか否かを判断した後（ステップＡ５１）、デバイスエンド報告管理テーブル３３に登録情報があるか否か、即ち第１の再結合要因が発生しているか否かを判断している（ステップＡ５３）。
【００２７】
従来、後述する理由により、ステージング完了による再結合が、デバイスリリースによる再結合よりも優先的に行なわれており、ステージング完了報告管理テーブル３５にＴＣＢ番号が登録されている場合（ステップＡ５１のＹＥＳルート）、ＲＭ１２は、そのＴＣＢ番号のＴＣＢ３４を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対してステージング完了報告を行なうようにＣＡ１１に依頼し、そのＴＣＢ番号をステージング完了報告管理テーブル３５から削除する（ステップＡ５２）。
【００２８】
ステージング完了報告管理テーブル３５に複数のＴＣＢ番号が登録されている場合には、全てのＴＣＢ番号について上述のような再結合処理が行なわれ、ステージング完了報告管理テーブル３５に登録されているＴＣＢ番号が無くなると（ステップＡ５１のＮＯルート）、デバイスエンド報告管理テーブル３３における登録情報の有無を判断し、登録情報が有る場合（ステップＡ５３のＹＥＳルート）、ＲＭ１２は、その登録情報を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対してデバイスエンド報告を行なうようにＣＡ１１に依頼し、その登録情報をデバイスエンド報告管理テーブル３３から削除する（ステップＡ５４）。
【００２９】
ついで、テーブル３１〜３３，３５およびＴＣＢ３４への具体的な登録内容について、図３５〜図４６を参照しながら説明する。
例えば、全てのテーブル３１〜３３，３５およびＴＣＢ３４に何も登録されていない状態で、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行されてくると、図３５に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リザーブ”が登録される。このとき、未だどのデバイス３もリザーブされていないので、デバイス３−０のリザーブ処理が実行され、図３６に示すように、リザーブ管理テーブル３１のデバイス番号０と“ＣＡ０”との交点位置に“１”がセットされることになる。この後、図３５に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３０】
上述のようにＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行されてくると、まず、図３７に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“２”が、コマンドとして“リザーブ”が登録される。そして、デバイス３−０がＣＰＵ２−０により既に占有されているので、ＣＰＵ２−１に対してデバイスビジーを報告してＣＰＵ２−１のチャネルインタフェースを切り離すとともに、図３８に示すように、デバイスビジー報告管理テーブル３２の“ＣＡ２”とデバイス番号０との交点位置に“１”が設定されることになる。この後、図３７に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３１】
続いて、ＣＰＵ２−１がデバイス３−１のデータをリードする場合、まず、ＣＰＵ２−１のチャネル２ａからデバイス３−１に対するリザーブコマンドが発行され、図３９に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リザーブ”が登録される。このとき、デバイス３−１はリザーブされていないので、デバイス３−１のリザーブ処理が実行され、図４０に示すように、リザーブ管理テーブル３１のデバイス番号１と“ＣＡ３”との交点位置に“１”がセットされることになる。この後、図３９に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３２】
このようにして、デバイス３−１をリザーブしたＣＰＵ２−１がリードコマンドを発行すると、図４１に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リード”が登録される。このとき、リード対象のデータがキャッシュメモリ１５上に存在しなければ、デバイス３−１に対するステージング動作が開始される。その間、リードコマンドについてのＴＣＢ３４は削除されることなく保持される。
【００３３】
このような状態で、デバイス３−０をリザーブしたＣＰＵ２−０がＣＡ１１−０を通じてリリースコマンドを発行すると、図４２に示すようにＴＣＢ３４のＴＣＢ番号２に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リリース”が登録される。そして、図４３に示すように、リザーブ管理テーブル３１から、デバイス番号０と“ＣＡ０”との交点位置にセットされた“１”が削除されるとともに、図４４に示すように、デバイスビジー報告管理テーブル３２の登録情報がデバイスエンド報告管理テーブル３３へ移動された後、図４２に示すごとく作成されたＴＣＢ番号２のＴＣＢ３４は削除される。
【００３４】
一方、ステージング動作を完了すると、図４５に示すように、ＴＣＢ番号１のＴＣＢ３４における再結合要因が“ステージング完了”（実際には“１”）に設定されるとともに、図４６に示すように、そのＴＣＢ番号１がステージング完了報告管理テーブル３５に登録される。
そして、ＲＭ１２は、図３４にて説明したアイドルループで、ステージング完了報告管理テーブル３５およびデバイスエンド報告管理テーブル３３を監視し、ステージング完了報告管理テーブル３５に図４６に示すごとくＴＣＢ番号１が登録されていることを認識すると、ＴＣＢ番号１のＴＣＢ３４を参照し、ＣＡ１１−３にステージング完了報告を依頼した後、ステージング完了報告管理テーブル３５からＴＣＢ番号１を削除するとともに、ＴＣＢ番号１のＴＣＢ３４を削除する。
【００３５】
また、ＲＭ１２は、ステージング完了報告管理テーブル３５に登録情報が無ければ、デバイスエンド報告管理テーブル３３を参照し、例えば図４６に示すような情報が登録されていれば、その情報に基づいて、ＣＡ１１−２に、デバイス３−０についてのデバイスエンド報告を依頼した後、デバイスエンド報告管理テーブル３３からその登録情報を削除する。
【００３６】
【発明が解決しようとする課題】
ところで、通常、リードコマンドを受けてステージング動作に移行した場合、ＦＣＵ１は、リードコマンドを発行したＣＰＵ２に対してチャネルエンドを報告してそのＣＰＵ２を一時的に切り離し、ＣＰＵ２は、ステージング完了報告待ちとなる。このステージング完了報告待ちの状態は、ＣＰＵ２にとって１つのＩ／Ｏ処理の完了待ちの状態であり、ステージング動作は比較的短時間で完了するので、それに応じた所定時間（例えば３０秒程度）の時間監視が行なわれ、所定時間を超えるとリセット処理が行なわれる。
【００３７】
これに対し、あるＣＰＵ２のアクセスしたデバイス３が他のＣＰＵ２により占有されているためにＦＣＵ１がデバイスビジー報告を行ないそのＣＰＵ２を一時的に切り離しＣＰＵ２がデバイスエンド報告待ちとなった場合、デバイス３が占有される時間は比較的長いため、それに応じた所定時間（例えば３分程度）の時間監視が行なわれ、所定時間を超えるとリセット処理が行なわれる。
【００３８】
上述のように、ステージング動作の方がデバイス３の占有よりもかなり短時間で完了するため、また、ＦＣＵ１とステージング完了報告待ちのＣＰＵ２との間はチャネルエンドの状態で切り離されており必ず再結合する必要があるため、従来、ステージング完了報告とデバイスエンド報告とは別々に管理され、ステージング完了による再結合（ステージング完了報告）は、デバイスリリースによる再結合（デバイスエンド報告）よりも優先的に行なわれている。
【００３９】
しかし、近年、ＦＣＵ１により管理されるべきデバイス３の数が極めて増大しており（例えば２５６台）、このような場合、多数のデバイス３に対するリード処理が同時に行なわれて多数のステージング動作が同時に行なわれることがあるため、ステージング完了報告が増加し、ステージング完了報告管理テーブル３５に複数のＴＣＢ番号が登録されている状況が多々生じる。このような状況下では、前述した通り、ステージング完了報告管理テーブル３５に登録されているＴＣＢ番号が無くなるまで、デバイスエンド報告に優先してステージング完了報告が行なわれることになり、いつまで経ってもデバイスエンド報告を行なえない状況が生じてしまう。
【００４０】
そこで、何回かに１回はデバイスエンド報告をステージング完了報告に優先して行なうように切り替えることも考えられるが、ＦＣＵ１は、デバイスリリースによる再結合順序（デバイスエンド報告を行なう順序）を認識していないため、特定のデバイス３に対するリザーブ／リリースが多発していると、そのデバイス３についてのデバイスエンド報告だけどうしても遅れがちになり、ＣＰＵ２へのデバイスエンド報告を行なうことの可能なデバイス３に偏りが生じる。
【００４１】
本発明は、このような課題に鑑み創案されたもので、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なえるようにして、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行可能にした、チャネルインタフェース再結合制御方法およびファイル制御装置を提供することを目的とする。
【００４２】
【課題を解決するための手段】
上記目的を達成するために、本発明のチャネルインタフェース再結合制御方法（請求項１）は、複数の処理装置が複数のファイル記憶装置を共用すべく、これらの処理装置とファイル記憶装置との間に、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置をそなえたシステムにおいて、複数の処理装置のうちの一の処理装置が複数のファイル記憶装置のうちの一つにアクセスした際に、ファイル記憶装置が複数の処理装置のうちの他の処理装置により占有されているために一の処理装置がファイル記憶装置にアクセスできない場合には、一の処理装置に対してビジー報告を行なって一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、ファイル記憶装置が他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、一の処理装置からのコマンドに応じてファイル記憶装置がステージング動作へ移行した場合には、一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する方法であって、前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしく前記第２の再結合要因の発生時に当該再結合要因に係わる該タスク制御ブロックの番号を用いて前記第１の再結合要因及び前記第２の再結合要因の発生順序を記憶し、記憶した前記発生順序に従って、前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置と該ファイル制御装置との間の前記チャネルインタフェースを再結合することを特徴としている。
【００４３】
このとき、前記ビジー報告を行なった場合には、当該ビジー報告に対応するタスク制御ブロックの番号を用いて前記ビジー報告を行なった順序を記憶し、前記第１の再結合要因の発生時には、前記ビジー報告を行なった順序に基づいて、前記再結合要因の発生順序を記憶することが好ましい（請求項２）。
【００４４】
一方、本発明のファイル制御装置（請求項３）は、複数の処理装置が複数のファイル記憶装置を共用すべく、これらの処理装置とファイル記憶装置との間にそなえられ、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するものであって、複数の処理装置のうちの一の処理装置が複数のファイル記憶装置のうちの一つにアクセスした際に、ファイル記憶装置が複数の処理装置のうちの他の処理装置により占有されているために一の処理装置が該ファイル記憶装置にアクセスできない場合には、一の処理装置に対してビジー報告を行なって一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、ファイル記憶装置が他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、一の処理装置からのコマンドに応じてファイル記憶装置がステージング動作へ移行した場合には、一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する制御部と、前記再結合要因の発生順序を記憶する発生順序記憶部とをそなえ、制御部が、前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしくは第２の再結合要因の発生時に当該再結合要因に係わるタスク制御ブロックの番号を発生順序記憶部に登録することにより、前記第１の再結合要因及び前記第２の再結合要因の発生を監視してその発生順序を発生順序記憶部に記憶させるとともに、発生順序記憶部に記憶された前記発生順序に従って前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置との間の前記チャネルインタフェースを再結合させることを特徴としている。
【００４６】
また、制御部が、他の処理装置からリリースコマンドを受けた場合に前記第１の再結合要因が発生したものと判断し、発生順序記憶部に対する登録を行なってもよい（請求項４）。
なお、前記ビジー報告を行なった順序を記憶するビジー報告順序記憶部をそなえ、制御部が、前記ビジー報告を行なった場合には、当該ビジー報告に対応するタスク制御ブロックの番号をビジー報告順序記憶部に記憶させることにより、ビジー報告順序記憶部に前記ビジー報告を行なった順序を記憶させ、前記第１の再結合要因の発生時には、ビジー報告順序記憶部に記録された前記ビジー報告を行なった順序に基づいて、発生順序記憶部に当該第１の再結合要因に係わるタスク制御ブロックの番号を発生順序記憶部に登録してもよい（請求項５）。
【００４７】
さらに、制御部が、前記ステージング動作の完了報告を受けた場合に前記第２の再結合要因が発生したものと判断し、発生順序記憶部に対する登録を行なってもよい（請求項６）。
【００４８】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図２は本実施形態のファイル制御装置（ＦＣＵ）の構成を示すブロック図であり、この図２に示すように、本実施形態のＦＣＵ１Ａは、図２３に示したＦＣＵ１と同様、複数（図２中では２台）のＣＰＵ２−０，２−１が複数（図２中では３台）のデバイス３−０〜３−２を共用すべく、これらのＣＰＵ２−０，２−１とデバイス３−０〜３−２との間にそなえられ、各ＣＰＵ２−０，２−１からのコマンドに応じて各デバイス３−０〜３−２に対するアクセス動作を制御するものである。なお、２つ存在するＣＰＵのうちの一つを特定する場合には、符号２−０，２−１を用いる一方、特定する必要のない場合には符号２を用いる。同様に、３つ存在するデバイスのうちの一つを特定する場合には、符号３−０〜３−２を用いる一方、特定する必要のない場合には符号３を用いる。
【００４９】
このＦＣＵ１Ａは、ＣＡ(Channel Adapter）１１−０〜１１−３，ＲＭ(Resource Manager)１２Ａ，ＴＳ（Table Storage)１３Ｂ，ＣＦＥ（Cache Function Engine)１４，キャッシュメモリ１５，ＤＡ(Device Adapter)１６−０〜１６−２，コマンドバス１７およびデータバス１８を有して構成されている。なお、４つ存在するＣＡのうちの一つを特定する場合には、符号１１−０〜１１−３を用いる一方、特定する必要のない場合には符号１１を用いる。同様に、３つ存在するＤＡのうちの一つを特定する場合には、符号１６−０〜１６−２を用いる一方、特定する必要のない場合には符号１６を用いる。
【００５０】
ここで、ＣＡ１１−０〜１１−３は、それぞれ、チャネルインタフェースを介してＣＰＵ２−０もしくは２−１とのインタフェース制御を担当するモジュールである。なお、ＣＰＵ２−０，２−１は、例えば２つのチャネル（ＣＨ）２ａ，２ｂを有しており、図２に示す例では、ＣＰＵ２−０のチャネル２ａ，２ｂがそれぞれＣＡ１１−０，１１−１に接続され、ＣＰＵ２−１のチャネル２ａ，２ｂがそれぞれＣＡ１１−２，１１−３に接続されている。
【００５１】
ＲＭ１２Ａは、基本動作に関する資源管理を担当するモジュールであり、ＴＳ１３Ａは、資源管理用のテーブルとして使用されるメモリである。これらのＲＭ１２ＡおよびＴＳ１３Ａは、図１および図３〜図２２を参照しながら後述するごとく、２つのＣＰＵ２−０，２−１のうちの一つが３つのデバイス３−０〜３−２のうちの一つにアクセスした際に直ちにそのＣＰＵ２がデバイス３にアクセスできずそのＣＰＵ２との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する制御部として機能する。
【００５２】
また、ＣＦＥ１４は、キャッシュメモリ１５の管理を担当するモジュールであり、ＤＡ１６−０〜１６−２は、それぞれ、磁気ディスク等のデバイス３−０〜３−２とのインタフェース制御を担当するモジュールである。
さらに、コマンドバス１７は、ＣＡ１１，ＲＭ１２Ａ，ＣＦＥ１４，ＤＡ１６の間でコマンドのやり取りを行なうためのものであり、データバス１８は、ＣＡ１１，ＣＦＥ１４，キャッシュメモリ１５，ＤＡ１６の間でデータのやり取りを行なうためのものである。
【００５３】
そして、本実施形態のＦＣＵ１Ａも、ＣＰＵ２の共用デバイスであり、あるＣＰＵ２がデバイス３を占有すると、以降、他のＣＰＵ２からのコマンドに対してデバイスビジーを報告し、他のＣＰＵ２を切り離す一方、リザーブコマンドを発行したＣＰＵ２からのリリースコマンドでデバイスが占有状態から解放されると、デバイスビジーを報告した他のＣＰＵ２に再結合を行なう（リリースによるデバイスエンド割込み：第１の再結合要因）。
【００５４】
また、リードコマンド処理時もしくはライトコマンド処理時に、デバイス３の動作（ステージング動作）を伴う場合は、ＦＣＵ１Ａは、一旦、リードコマンドもしくはライトコマンドを発行したＣＰＵ２の切り離しを行ない、デバイス３のステージング動作が終了した時点でＣＰＵ２との再結合を行なう（ステージング完了によるデバイスエンド割込み：第２の再結合要因）。
【００５５】
ついで、図１および図３〜図６を参照しながら、本実施形態のＦＣＵ１Ａにおいて、チャネルインタフェースの再結合を制御するＲＭ１２ＡおよびＴＳ１３Ａの機能的な構成について説明する。図１は、本発明の一実施形態としてのＦＣＵ１ＡにおけるＲＭ１２Ａ／ＴＳ１３Ａの機能的な構成を示すブロック図、図３〜図６はそれぞれリザーブ管理テーブル４１，デバイスビジー報告管理テーブル４２，ＴＢＣ４３および再結合管理テーブル４４を説明するための図である。
【００５６】
図１に示すように、本実施形態のＴＳ１３Ａは、リザーブ管理テーブル４１，デバイスビジー報告管理テーブル４２，ＴＢＣ４３および再結合管理テーブル４４を保持するものである。また、本実施形態のＲＭ１２Ａは、ＴＳ１３Ａのデバイスビジー報告管理テーブル４２および再結合管理テーブル４４を用いて、前述した第１の再結合要因および第２の再結合要因の発生時に再結合処理を実行する機構（ステージング完了／デバイスリリースによる再結合機構）２０として機能する。
【００５７】
リザーブ管理テーブル４１は、図３に示すように構成され、図２５に示したテーブル３１と同様、ＣＰＵ２により占有されているデバイス３を管理するためのものである。なお、テーブル４１において、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行され、デバイス３−０を占有することができた場合、ＲＭ１２Ａは、テーブル４１における“ＣＡ０”とデバイス番号０との交点位置に“１”を設定する（図１３参照）。
【００５８】
ＴＢＣ４３は、図５に示すように構成され、図２８に示したＴＣＢ３４とほぼ同様、ＲＭ１２Ａがコマンドに応じたタスクを実行する毎に作成され、そのタスクを終了する際に削除されるもので、そのタスクに関連する情報等を含み、タスクの制御に用いられる。このＴＣＢ４３には、ＣＰＵ２からのコマンドの内容（種別）と、そのコマンドを受け付けたＣＡ１１の番号と、そのコマンドの対象であるデバイス３の番号と、再結合状態とがタスク毎にタスク番号を付して保持される。
【００５９】
ここで、本実施形態のＴＣＢ４３の再結合状態には、ＲＭ１２Ａがコマンドの発行元ＣＰＵ２に対してデバイスビジーを報告した場合（第１の再結合要因で再結合すべき場合）に“ビジー”情報がセットされ（図１４参照）、リードコマンド／ライトコマンドの処理時にステージング動作に移行した場合（第２の再結合要因で再結合すべき場合）に“ステージング待ち”情報がセットされ（図１８，図１９参照）、ステージング動作移行後にそのステージング動作を完了した場合（第２の再結合要因の発生時）に“ステージング完了”情報がセットされる（図２１参照）。
【００６０】
本実施形態では、上述のごとく、ＲＭ１２Ａがコマンドの発行元ＣＰＵ２に対してデバイスビジー報告を行なった場合、その旨が再結合状態としてＴＣＢ４３に保持される。そして、デバイスビジー報告を行なった場合、そのデバイスビジー報告に係るコマンドについてのＴＣＢ４３は、従来、デバイスビジー報告後に削除されていたが、本実施形態では、デバイスリリースに伴ってデバイスエンド報告が行なわれるまで保持される。
【００６１】
つまり、本実施形態のＲＭ１２Ａは、デバイスビジー報告を行なった状態およびステージング動作の完了待ち状態を、ＴＣＢ４３により管理している。
デバイスビジー報告管理テーブル（キュー）４２は、図４に示すように構成され、ＲＭ１２Ａがデバイスビジー報告を行なった順序を記憶するビジー報告順序記憶部として機能するものである。なお、テーブル４２においても、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行された場合、ＲＭ１２Ａは、デバイスビジー報告を行なってからＣＰＵ２−１のチャネル２ａを切り離すようにＣＡ１１−２を制御するとともに、テーブル４２におけるデバイス番号０の“１番目にビジーを報告したＴＣＢ番号”の欄に、そのリザーブコマンドが登録されているＴＣＢ４３のＴＣＢ番号を登録する（図１５参照）。図４に示すテーブル４２には、デバイス３毎に、最大Ｎ個のＴＣＢ番号をデバイスビジー報告順に登録することができるようになっている。
【００６２】
再結合管理テーブル（キュー：発生順序記憶部）４４は、図６に示すように構成され、再結合要因の発生順序を記憶する発生順序記憶部として機能するものである。本実施形態のＲＭ１２Ａは、前述した第１および第２の再結合要因の発生を監視してその発生順序を再結合管理テーブル４４に記憶させるとともに、この再結合管理テーブル４４に記憶された発生順序に従って各再結合要因に係わるＣＰＵ２との間のチャネルインタフェースを再結合させるようにＣＡ１１を制御する。
【００６３】
より具体的に、ＲＭ１２Ａは、ＣＰＵ２からリリースコマンドを受けた場合に第１の再結合要因が発生したものと判断し、その第１の再結合要因に係るＴＣＢ番号を再結合管理テーブル４４に登録する一方、ステージング動作の完了報告を受けた場合に第２の再結合要因が発生したものと判断し、その第２の再結合要因に係るＴＣＢ番号を再結合管理テーブル４４に登録する。これにより、再結合管理テーブル４４には、再結合要因の種別に関係なく、第１および第２の再結合要因の発生した順序がＴＣＢ番号で登録・記憶されることになる。
【００６４】
次に、上述した本実施形態のＦＣＵ１ＡにおけるＲＭ１２ＡおよびＴＳ１３Ａの詳細な動作について、図７〜図２２を参照しながら説明する。
まず、図７〜図１１に示すフローチャートに従って、ＲＭ１２ＡおよびＴＳ１３Ａの動作の流れについて説明する。
図７は、ＲＭ１２Ａがリザーブコマンドを受けた場合の動作を説明するためのフローチャートであり、この図７に示すように、ＲＭ１２Ａは、リザーブコマンドを受けるとそのリザーブコマンドについてのＴＣＢ４３を作成してから（ステップＳ１１）、リザーブ管理テーブル４１を参照して、そのリザーブコマンドの対象デバイス３が他のＣＰＵ２（他パス，他チャネル）からリザーブされているか否かを判断する（ステップＳ１２）。
【００６５】
他パスからリザーブされていない場合（ステップＳ１２のＮＯルート）、ＲＭ１２Ａは、リザーブコマンドの対象であるデバイス３についてリザーブ処理を行なってから（ステップＳ１３）、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＳ１４）。なお、リザーブ処理に際して、ＲＭ１２Ａは、リザーブ管理テーブル４１において、リザーブ対象のデバイス３のデバイス番号とリザーブコマンドを受け付けたＣＡ１１との交点位置に“１”をセットする。
【００６６】
一方、リザーブコマンドの対象デバイス３が他パスからリザーブされている場合（ステップＳ１２のＹＥＳルート）、ＲＭ１２Ａは、ＴＣＢ４３の再結合状態の欄に“ビジー”を登録し、ステップＳ１１で作成したＴＣＢ４３の番号（ＴＣＢ番号）を、デバイスビジー報告管理テーブル４２における、リザーブコマンドの対象デバイス３に対応するデバイス番号の欄にビジー報告順に登録し、リザーブコマンド発行元のＣＰＵ２に対してデバイスビジー報告を行なってからそのＣＰＵ２のチャネルインタフェースを切り離すようにＣＡ１１を制御する（ステップＳ１５）。このとき、ＲＭ１２Ａは従来のごとくＴＣＢ４３を削除せず、そのＴＣＢ４３は、デバイスリリースに伴ってデバイスエンド報告が行なわれるまで保持される。
【００６７】
図８は、ＲＭ１２Ａがリリースコマンドを受けた場合の動作を説明するためのフローチャートであり、この図８に示すように、ＲＭ１２Ａは、デバイス３を占有していたＣＰＵ２からリリースコマンドを受けると、そのリリースコマンドについてのＴＣＢ４３を作成してから（ステップＳ２１）、リザーブ管理テーブル４１から対応する登録（“１”の設定）を抹消し、デバイスビジー報告管理テーブル４２に、占有を解放するデバイス３についてＴＣＢ番号が登録されている場合、そのＴＣＢ番号を再結合管理テーブル４４に登録する（ステップＳ２２）。このとき、複数のＴＣＢ番号が登録されている場合には、その登録順序に従ってＴＣＢ番号を再結合管理テーブル４４に登録する。この後、ＲＭ１２Ａは、そのリリースコマンドについてのＴＣＢ４３を削除する（ステップＳ２３）。
【００６８】
図９は、ＲＭ１２Ａがリードコマンドを受けた場合の動作を説明するためのフローチャートであり、この図９に示すように、ＲＭ１２Ａは、デバイス３を占有しているＣＰＵ２からリードコマンドを受けると、そのリードコマンドについてのＴＣＢ４３を作成してから（ステップＳ３１）、ＣＦＥ１４を介してキャッシュメモリ１５上にリード対象のデータが存在するか否かを判断する（ステップＳ３２）。
【００６９】
キャッシュメモリ１５上にリード対象のデータが存在する場合（ステップＳ３２のＹＥＳルート）、ＲＭ１２Ａは、そのデータをＣＡ１１からＣＰＵ２へ転送してから（ステップＳ３３）、そのリードコマンドについてのＴＣＢ４３を削除する（ステップＳ３４）。
一方、キャッシュメモリ１５上にリード対象のデータが存在しない場合（ステップＳ３２のＮＯルート）、ＲＭ１２Ａは、ＣＡ１１からＣＰＵ２にチャネルエンドを報告し、ＤＡ１６にデバイス３に対するステージングを依頼し、図１０にて説明するステージング完了報告待ち処理へ移行するとともに、ＴＣＢ４３の再結合状態の欄に“ステージング待ち”を登録する（ステップＳ３５）。このとき、リードコマンドについてのＴＣＢ４３を削除されることなく保持される。
【００７０】
図１０は、ＲＭ１２Ａのステージング完了報告待ち処理を説明するためのフローチャートであり、この図１０に示すように、ＲＭ１２Ａは、ステージングを依頼したＤＡ１６からのステージング完了報告を待機し（ステップＳ４１）、そのＤＡ１６からステージング完了報告を受けると（ステップＳ４１のＹＥＳルート）、対応するリードコマンドについてのＴＣＢ４３の再結合状態を“ステージング待ち”から“ステージング完了”に設定する（ステップＳ４２）。
【００７１】
そして、ＲＭ１２Ａは、ステップＳ４２にて再結合状態を“ステージング完了”にセットしたタスクのＴＣＢ番号を、再結合管理テーブル４４に登録し（ステップＳ４３）、ステージング動作で読み出されたデータが、図１１にて後述するアイドルループに従って再結合されてＣＡ１１によりＣＰＵ２へ転送されるのを待機し（ステップＳ４４）、ＣＡ１１がそのデータの転送を完了すると（ステップＳ４４のＹＥＳルート）、ステージング完了報告待ちであったリードコマンドについてのＴＣＢ４３を削除する（ステップＳ４５）。
【００７２】
図１１は、ＲＭ１２Ａのアイドルループによる処理を説明するためのフローチャートであり、この図１１に示すように、ＲＭ１２Ａは、常時、アイドルループにより、再結合管理テーブル４４にＴＣＢ番号が登録されているか否か、即ち第１もしくは第２の再結合要因が発生しているか否かを判断している（ステップＳ５３）。
【００７３】
再結合管理テーブル４４にＴＣＢ番号が登録されている場合（ステップＳ５１のＹＥＳルート）、ＲＭ１２Ａは、そのＴＣＢ番号のＴＣＢ４３を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対して再結合状態に応じた処理を行なうようにＣＡ１１に依頼する（ステップＳ５２）。ここで、再結合状態が“ビジー”である場合、ＲＭ１２Ａは、ＣＡ１１に、ＣＰＵ２に対しデバイスエンドを報告させる一方、再結合状態が“ステージング完了”である場合、ＲＭ１２Ａは、ＣＡ１１に、ＣＰＵ２に対しステージング完了を報告させリードデータの転送を行なわせる。
【００７４】
そして、ステップＳ５２で行なわれた再結合がデバイスリリース（第１の再結合要因）によるものであるか否かを判断し（ステップＳ５３）、デバイスリリースによるものである場合（ステップＳ５３のＹＥＳルート）、対応するＴＣＢ４３を削除する（ステップＳ５４）。一方、デバイスリリースによるものではない場合（ステージング完了による再結合の場合；ステップＳ５３のＮＯルート）、ＴＣＢ４３の削除は図１０のステップＳ４５で行なわれているので、何も行なうことなく、ステップＳ５１へ戻る。
【００７５】
ついで、テーブル４１，４３，４４およびＴＣＢ４３への具体的な登録内容について、図１２〜図２２を参照しながら説明する。
例えば、全てのテーブル４１，４２，４４およびＴＣＢ４３に何も登録されていない状態で、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行されてくると、図１２に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リザーブ”が登録される。このとき、未だどのデバイス３もリザーブされていないので、デバイス３−０のリザーブ処理が実行され、図１３に示すように、リザーブ管理テーブル４１のデバイス番号０と“ＣＡ０”との交点位置に“１”がセットされることになる。この後、図１２に示すごとく作成されたＴＣＢ番号１のＴＣＢ４３は削除される。
【００７６】
上述のようにＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行されてくると、まず、図１４に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“２”が、コマンドとして“リザーブ”が登録される。そして、デバイス３−０がＣＰＵ２−０により既に占有されているので、ＣＰＵ２−１に対してデバイスビジーを報告してＣＰＵ２−１のチャネルインタフェースを切り離し、図１４に示すように、ＴＣＢ番号１の再結合状態に“ビジー”が設定されるとともに、図１５に示すように、デバイスビジー報告管理テーブル４２における、デバイス番号０の“１番目にビジーを報告したＴＣＢ番号”の欄に、ＴＣＢ番号１が設定される。このとき、図１４に示すＴＣＢ番号１のＴＣＢ４３は、削除されず、デバイスエンドの報告が行なわれるまで保持される。
【００７７】
続いて、ＣＰＵ２−１がデバイス３−１のデータをリードする場合、まず、ＣＰＵ２−１のチャネル２ｂからデバイス３−１に対するリザーブコマンドが発行され、図１６に示すようにＴＣＢ４３のＴＣＢ番号２に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リザーブ”が登録される。このとき、デバイス３−１はリザーブされていないので、デバイス３−１のリザーブ処理が実行され、図１７に示すように、リザーブ管理テーブル４１のデバイス番号１と“ＣＡ３”との交点位置に“１”がセットされることになる。この後、図１６に示すごとく作成されたＴＣＢ番号２のＴＣＢ４３は削除される。
【００７８】
このようにして、デバイス３−１をリザーブしたＣＰＵ２−１がリードコマンドを発行すると、図１８に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リード”が登録される。このとき、リード対象のデータがキャッシュメモリ１５上に存在しなければ、デバイス３−１に対するステージング動作が開始され、ＴＣＢ番号２の再結合状態に“ステージング待ち”が設定される。このＴＣＢ番号２のＴＣＢ４３は、ステージング動作が完了するまで削除されることなく保持される。
【００７９】
このような状態で、デバイス３−０をリザーブしたＣＰＵ２−０がＣＡ１１−０を通じてリリースコマンドを発行すると、図１９に示すようにＴＣＢ４３のＴＣＢ番号３に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リリース”が登録される。そして、図２０に示すように、リザーブ管理テーブル４１から、デバイス番号０と“ＣＡ０”との交点位置にセットされた“１”が削除されるとともに、図２２に示すように、再結合管理テーブル４４の再結合順序１に対応する欄にＴＣＢ番号１が登録された後、図１９に示すごとく作成されたＴＣＢ番号３のＴＣＢ４３は削除される。
【００８０】
デバイス３−０の解放に続いてステージング動作を完了すると、図２１に示すように、ＴＣＢ番号２のＴＣＢ４３における再結合状態が“ステージング完了”に設定されるとともに、図２２に示すように、そのＴＣＢ番号２が再結合管理テーブル４４の再結合順序２に対応する欄に登録される。
そして、ＲＭ１２Ａは、図１１にて説明したアイドルループで、再結合管理テーブル４４を監視し、この再結合管理テーブル４４に図２２に示すごとくＴＣＢ番号１およびＴＣＢ番号２が登録されていることを認識すると、その登録順序に従って再結合処理をＣＡ１１に依頼する。つまり、ここでは、まず、ＴＣＢ番号１のＴＣＢ４３を参照し、ＣＡ１１−２に、デバイス３−０についてのデバイスエンド報告を依頼した後、そのＴＣＢ４３を削除する。ついで、ＴＣＢ番号２のＴＣＢ４３を参照し、ＣＡ１１−３にステージング完了報告を依頼した後、そのＴＣＢ４３を削除する。
【００８１】
このように、本発明の一実施形態によれば、ステージング完了報告を管理するテーブルとデバイスエンド報告を管理するテーブルとが１つの再結合管理テーブル４４に融合され、この再結合管理テーブル４４を図１１に示すアイドルループに従って検索することにより、再結合要因の発生した順にＣＡ１１に再結合を依頼することができる。つまり、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なうことができるので、再結合処理に偏りが生じることがなく、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行することができる。
【００８２】
従って、デバイスリリースを行なったデバイス順にデバイスエンド報告を行なえ、ステージング完了報告数の増加に伴い従来生じていたデバイスエンド報告の沈み込みを確実に回避することができる。
また、本実施形態によれば、デバイスビジー報告管理テーブル４２に、デバイスビジー報告を行なった順序でＴＣＢ番号を登録しておくことにより、デバイスビジー報告を行なった順序でデバイスエンド報告を行なうことが可能になり、デバイスエンド報告の遅れを抑止することもできる。
【００８３】
さらに、本実施形態によれば、デバイスビジー報告を行なった状態およびステージング動作の完了待ち状態をＴＣＢ４３で管理しているので、ＴＣＢ番号を用いて再結合処理の順序を管理することができ、再結合処理を大幅に簡素化できる利点もある。
なお、本発明は上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
【００８４】
例えば、上述した実施形態では、処理装置としてのＣＰＵ２が２台、ファイル記憶装置としてのデバイス３が３台である場合について説明しているが、本発明は、このような台数に限定されるものではない。
また、上述した実施形態では、再結合要因がデバイスリリースとステージング完了との２種類である場合について説明したが、本発明は、これに限定されるものではなく、再結合要因が３種類以上である場合や、異なる種類の再結合要因を含む場合にも同様に適用され、上述した実施形態と同様の作用効果を得ることができる。
【００８５】
【発明の効果】
以上詳述したように、本発明のチャネルインタフェース再結合制御方法（請求項１，２）およびファイル制御装置（請求項３〜６）によれば、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なうことができるので、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行することができる。従って、デバイスリリースを行なったデバイス順にデバイスエンド報告を行なえ、ステージング完了報告数の増加に伴い従来生じていたデバイスエンド報告の沈み込みを確実に回避することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態としてのファイル制御装置（ＦＣＵ）におけるＲＭ／ＴＳの機能的な構成を示すブロック図である。
【図２】本実施形態のファイル制御装置（ＦＣＵ）の構成を示すブロック図である。
【図３】本実施形態のリザーブ管理テーブルを説明するための図である。
【図４】本実施形態のデバイスビジー報告管理テーブル（キュー：ビジー報告順序記憶部）を説明するための図である。
【図５】本実施形態のタスク制御ブロック（ＴＢＣ）を説明するための図である。
【図６】本実施形態の再結合管理テーブル（キュー：発生順序記憶部）を説明するための図である。
【図７】本実施形態のＲＭがリザーブコマンドを受けた場合の動作を説明するためのフローチャートである。
【図８】本実施形態のＲＭがリリースコマンドを受けた場合の動作を説明するためのフローチャートである。
【図９】本実施形態のＲＭがリードコマンドを受けた場合の動作を説明するためのフローチャートである。
【図１０】本実施形態のＲＭのステージング完了報告待ち処理を説明するためのフローチャートである。
【図１１】本実施形態のＲＭのアイドルループによる処理を説明するためのフローチャートである。
【図１２】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１３】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図１４】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１５】本実施形態のデバイスビジー報告管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【図１６】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１７】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図１８】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１９】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図２０】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図２１】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図２２】本実施形態の再結合管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【図２３】一般的なＦＣＵの構成を示すブロック図である。
【図２４】従来のＲＭ／ＴＳの機能的な構成を示すブロック図である。
【図２５】リザーブ管理テーブルを説明するための図である。
【図２６】デバイスビジー報告管理テーブルを説明するための図である。
【図２７】デバイスエンド報告管理テーブルを説明するための図である。
【図２８】タスク制御ブロック（ＴＢＣ）を説明するための図である。
【図２９】ステージング完了報告管理テーブル（キュー）を説明するための図である。
【図３０】ＲＭがリザーブコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３１】ＲＭがリリースコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３２】ＲＭがリードコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３３】ＲＭのステージング完了報告待ち処理を説明するためのフローチャートである。
【図３４】ＲＭのアイドルループによる処理を説明するためのフローチャートである。
【図３５】ＴＣＢへの具体的な登録内容について説明するための図である。
【図３６】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図３７】ＴＣＢへの具体的な登録内容について説明するための図である。
【図３８】デバイスビジー報告管理テーブルへの具体的な登録内容について説明するための図である。
【図３９】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４０】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図４１】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４２】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４３】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図４４】デバイスエンド報告管理テーブルへの具体的な登録内容について説明するための図である。
【図４５】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４６】ステージング完了報告管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【符号の説明】
１Ａ ファイル制御装置（ＦＣＵ）
２，２−０，２−１ ＣＰＵ（処理装置）
２ａ，２ｂ チャネル（ＣＨ）
３，３−０〜３−２ デバイス（ＤＶ，ファイル記憶装置）
１１，１１−０〜１１−３ ＣＡ(Channel Adapter）
１２Ａ ＲＭ(Resource Manager:制御部）
１３Ａ ＴＳ(Table Storage）
１４ ＣＦＥ(Cache Function Engine）
１５ キャッシュメモリ
１６，１６−０〜１６−２ ＤＡ(Device Adapter)
１７ コマンドバス
１８ データバス
２０ ステージング完了／デバイスリリースによる再結合機構（制御部）
４１ リザーブ管理テーブル
４２ デバイスビジー報告管理テーブル（キュー：ビジー報告順序記憶部）
４３ タスク制御ブロック（ＴＣＢ）
４４ 再結合管理テーブル（キュー：発生順序記憶部）
発明の属する技術分野
従来の技術（図２３〜図４６）
発明が解決しようとする課題
課題を解決するための手段
発明の実施の形態（図１〜図２２）
発明の効果
【０００１】
【発明の属する技術分野】
本発明は、複数の処理装置が、ファイル制御装置を介して複数のファイル記憶装置を共用する際に適用される技術に関し、特に、ある処理装置がファイル記憶装置にアクセスした際に直ちにそのファイル記憶装置にアクセスできず処理装置とファイル制御装置との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する方法、および、この方法を実現するためのファイル制御装置に関する。
【０００２】
【従来の技術】
複数の処理装置が複数のファイル記憶装置を共用する際、一般に、これらの処理装置とファイル記憶装置との間には、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置がそなえられている。ここで、処理装置は、例えばＣＰＵであり、ファイル記憶装置は、例えば磁気ディスク等のデバイス（ＤＡＳＤ：Direct Access Storage Device）である。なお、以下、ファイル制御装置についてはＦＣＵと略記し、ファイル記憶装置については単にデバイスと呼ぶ場合がある。
【０００３】
このようにＦＣＵをそなえたシステムにおいて、ＣＰＵは、他のＣＰＵと共用する各デバイスのデータを読み出したり、各デバイスにデータを書き込んだりするために、まず、リザーブコマンドで他のＣＰＵからのアクセスを排他し、デバイスの占有が確立したところで、リードコマンドあるいはライトコマンドを発行する。
【０００４】
ＦＣＵは、共用デバイスであり、あるＣＰＵがデバイスを占有すると、以降、他のＣＰＵからのコマンドに対してデバイスビジーを報告し、他のＣＰＵを切り離す一方、リザーブコマンドを発行したＣＰＵからのリリースコマンドでデバイスが占有状態から解放されると、デバイスビジーを報告した他のＣＰＵ（チャネル）に再結合を行なう（リリースによるデバイスエンド割込み：第１の再結合要因）。
【０００５】
また、リードコマンド処理時もしくはライトコマンド処理時に、磁気ディスクの動作（ステージング動作）を伴う場合は、ＦＣＵは、一旦、リードコマンドもしくはライトコマンドを発行したＣＰＵの切り離しを行ない、磁気ディスクのステージング動作が終了した時点でＣＰＵ（チャネル）との再結合を行なう（ステージング完了によるデバイスエンド割込み：第２の再結合要因）。なお、ステージング動作とは、リード対象もしくはライト対象のデータがＦＣＵ内のキャッシュメモリ上に存在しない場合に、そのデータを保有するデバイスからキャッシュメモリ上へ読み出す動作である。
【０００６】
ここで、図２３を参照しながら、一般的なＦＣＵの構成について説明する。図２３は一般的なＦＣＵの構成を示すブロック図で、この図２３に示すように、ＦＣＵ１は、複数（図２３中では２台）のＣＰＵ２−０，２−１が複数（図２３中では３台）のデバイス３−０〜３−２を共用すべく、これらのＣＰＵ２−０，２−１とデバイス３−０〜３−２との間にそなえられ、各ＣＰＵ２−０，２−１からのコマンドに応じて各デバイス３−０〜３−２に対するアクセス動作を制御するものである。なお、２つ存在するＣＰＵのうちの一つを特定する場合には、符号２−０，２−１を用いる一方、特定する必要のない場合には符号２を用いる。同様に、３つ存在するデバイスのうちの一つを特定する場合には、符号３−０〜３−２を用いる一方、特定する必要のない場合には符号３を用いる。
【０００７】
このＦＣＵ１は、ＣＡ(Channel Adapter）１１−０〜１１−３，ＲＭ(Resource Manager)１２，ＴＳ（Table Storage)１３，ＣＦＥ（Cache Function Engine)１４，キャッシュメモリ１５，ＤＡ(Device Adapter)１６−０〜１６−２，コマンドバス１７およびデータバス１８を有して構成されている。なお、４つ存在するＣＡのうちの一つを特定する場合には、符号１１−０〜１１−３を用いる一方、特定する必要のない場合には符号１１を用いる。同様に、３つ存在するＤＡのうちの一つを特定する場合には、符号１６−０〜１６−２を用いる一方、特定する必要のない場合には符号１６を用いる。
【０００８】
ここで、ＣＡ１１−０〜１１−３は、それぞれ、チャネルインタフェースを介してＣＰＵ２−０もしくは２−１とのインタフェース制御を担当するモジュールである。なお、ＣＰＵ２−０，２−１は、例えば２つのチャネル（ＣＨ）２ａ，２ｂを有しており、図２３に示す例では、ＣＰＵ２−０のチャネル２ａ，２ｂがそれぞれＣＡ１１−０，１１−１に接続され、ＣＰＵ２−１のチャネル２ａ，２ｂがそれぞれＣＡ１１−２，１１−３に接続されている。
【０００９】
ＲＭ１２は、基本動作に関する資源管理を担当するモジュールであり、ＴＳ１３は、資源管理用のテーブルとして使用されるメモリである。これらのＲＭ１２およびＴＳ１３は、図２４〜図４６を参照しながら後述するごとく、２つのＣＰＵ２−０，２−１のうちの一つが３つのデバイス３−０〜３−２のうちの一つにアクセスした際に直ちにそのＣＰＵ２がデバイス３にアクセスできずそのＣＰＵ２との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する制御部として機能する。
【００１０】
また、ＣＦＥ１４は、キャッシュメモリ１５の管理を担当するモジュールであり、ＤＡ１６−０〜１６−２は、それぞれ、磁気ディスク等のデバイス３−０〜３−２とのインタフェース制御を担当するモジュールである。
さらに、コマンドバス１７は、ＣＡ１１，ＲＭ１２，ＣＦＥ１４，ＤＡ１６の間でコマンドのやり取りを行なうためのものであり、データバス１８は、ＣＡ１１，ＣＦＥ１４，キャッシュメモリ１５，ＤＡ１６の間でデータのやり取りを行なうためのものである。
【００１１】
ついで、図２４〜図２９を参照しながら、チャネルインタフェースの再結合を制御するＲＭ１２およびＴＳ１３の機能的な構成について説明する。図２４は従来のＲＭ１２／ＴＳ１３の機能的な構成を示すブロック図、図２５〜図２９はそれぞれリザーブ管理テーブル３１，デバイスビジー報告管理テーブル３２，デバイスエンド報告管理テーブル３３，タスク制御ブロック（ＴＢＣ）３４およびステージング完了報告管理テーブル（キュー）３５を説明するための図である。
【００１２】
図２４に示すように、ＴＳ１３は、リザーブ管理テーブル３１，デバイスビジー報告管理テーブル３２，デバイスエンド報告管理テーブル３３，ＴＣＢ３４およびステージング完了報告管理テーブル３５を保持するものであり、ＲＭ１２は、ＴＳ１３のデバイスビジー報告管理テーブル３２およびデバイスエンド報告管理テーブル３３を用いて、前述した第１の再結合要因の発生時に再結合処理を実行する機構（デバイスリリースによる再結合機構）として機能する。また、ＲＭ１２は、ＴＳ１３のステージング完了報告管理テーブル３５を用いて、前述した第２の再結合要因の発生時に再結合処理を実行する機構（ステージング完了による再結合機構）としても機能する。
【００１３】
リザーブ管理テーブル３１は、図２５に示すように構成され、ＣＰＵ２により占有されているデバイス３を管理するためのものである。なお、テーブル３１において、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行され、デバイス３−０を占有することができた場合、ＲＭ１２は、テーブル３１における“ＣＡ０”とデバイス番号０との交点位置に“１”を設定する（図３６参照）。
【００１４】
デバイスビジー報告管理テーブル３２は、図２６に示すように構成され、ＲＭ１２がＣＡ１１を通じてデバイスビジーを報告したＣＰＵ２と、そのＣＰＵ２が占有しようとしたデバイス３とを管理するためのものである。なお、テーブル３２においても、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行された場合、ＲＭ１２は、デバイスビジー報告を行なってからＣＰＵ２−１のチャネル２ａを切り離すようにＣＡ１１−２を制御するとともに、テーブル３２における“ＣＡ２”とデバイス番号０との交点位置に“１”を設定する（図３８参照）。
【００１５】
デバイスエンド報告管理テーブル３３は、図２７に示すように構成され、ＲＡ１２がＣＡ１１を通じてデバイスエンドを報告すべきＣＰＵ２を管理するためのものである。なお、テーブル３３においても、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくデバイスビジーが報告されＣＰＵ２−１のチャネル２ａが切り離された後にＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０に対するリリースコマンドが発行されると、ＲＭ１２（再結合機構２１）は、リザーブ管理テーブル３１の登録を抹消するとともに、デバイスビジー報告管理テーブル３２を参照して占有から解放されたデバイス３についてデバイスビジー報告を行なったＣＰＵ２が存在するか否かを確認し、存在する場合、デバイスビジー報告管理テーブル３２のデータをデバイスエンド報告管理テーブル３３にコピーし、デバイスビジー報告管理テーブル３２の登録を抹消する。これにより、テーブル３３における“ＣＡ２”とデバイス番号０との交点位置に“１”が設定される（図４４参照）。ＲＭ１２（再結合機構２１）は、デバイスエンド報告管理テーブル３３を参照し、図３４にて後述するタイミングで、ＣＰＵ２−１のチャネル２ａとの再結合を行なうようにＣＡ１１−２を制御し、デバイスエンド報告を行なう。
【００１６】
ＴＣＢ３４は、図２８に示すように構成され、ＲＭ１２がコマンドに応じたタスクを実行する毎に作成され、そのタスクを終了する際に削除されるもので、そのタスクに関連する情報等を含み、タスクの制御に用いられる。このＴＣＢ３４には、ＣＰＵ２からのコマンドの内容（種別）と、そのコマンドを受け付けたＣＡ１１の番号と、そのコマンドの対象であるデバイス３の番号と、再結合要因とが、タスク毎にタスク番号を付して保持される。ここで、再結合要因としては、リードコマンド／ライトコマンドの処理時にステージング動作に移行した後にそのステージング動作を完了した旨（つまり第２の再結合要因が発生した旨）が保持される。より具体的に、ステージング動作の完了時には、ＲＭ１２により、ＴＣＢ３４の再結合要因として例えば“１”がセットされる。
【００１７】
ステージング完了報告管理テーブル３５は、図２９に示すように構成され、ステージング完了に伴って再結合処理を行なうべきタスクのＴＣＢ番号を管理するためのもので、このテーブル３５には、前述のごとくステージング動作の完了に伴い再結合要因をセットされたタスクのＴＣＢ番号が、ＲＭ１２により再結合順序で登録される（図４６参照）。ＲＭ１２（再結合機構２２）は、ステージング完了報告管理テーブル３５を参照し、図３４にて後述するタイミングで、ステージング完了に伴う再結合処理を行なう。
【００１８】
次に、上述のようなＲＭ１２およびＴＳ１３の詳細な動作について、図３０〜図４６を参照しながら説明する。
まず、図３０〜図３４に示すフローチャートに従って、ＲＭ１２およびＴＳ１３の動作の流れについて説明する。
図３０は、ＲＭ１２がリザーブコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３０に示すように、ＲＭ１２は、リザーブコマンドを受けるとそのリザーブコマンドについてのＴＣＢ３４を作成してから（ステップＡ１１）、リザーブ管理テーブル３１を参照して、そのリザーブコマンドの対象デバイス３が他のＣＰＵ２（他パス，他チャネル）からリザーブされているか否かを判断する（ステップＡ１２）。
【００１９】
他パスからリザーブされていない場合（ステップＡ１２のＮＯルート）、ＲＭ１２は、リザーブコマンドの対象であるデバイス３についてリザーブ処理を行なってから（ステップＡ１３）、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＡ１５）。なお、リザーブ処理に際して、ＲＭ１２は、リザーブ管理テーブル３１において、リザーブ対象のデバイス３のデバイス番号とリザーブコマンドを受け付けたＣＡ１１との交点位置に“１”をセットする。
【００２０】
一方、リザーブコマンドの対象デバイス３が他パスからリザーブされている場合（ステップＡ１２のＹＥＳルート）、ＲＭ１２は、デバイスビジー報告管理テーブル３８にそのリザーブコマンドについて登録し、リザーブコマンド発行元のＣＰＵ２に対してデバイスビジー報告を行なってからそのＣＰＵ２のチャネルインタフェースを切り離すようにＣＡ１１を制御する（ステップＡ１４）。この後、ＲＭ１２は、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＡ１５）。
【００２１】
図３１は、ＲＭ１２がリリースコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３１に示すように、ＲＭ１２は、デバイス３を占有していたＣＰＵ２からリリースコマンドを受けると、そのリリースコマンドについてのＴＣＢ３４を作成してから（ステップＡ２１）、リザーブ管理テーブル３１から対応する登録（“１”の設定）を抹消し、デバイスビジー報告管理テーブル３２に、占有を解放するデバイス３についてデバイスビジー報告を行なった旨が登録されている場合、そのデバイスビジー報告管理テーブル３２の登録情報をデバイスエンド報告管理テーブル３３へ移動する（ステップＡ２２）。この後、ＲＭ１２は、そのリリースコマンドについてのＴＣＢ３４を削除する（ステップＡ２３）。
【００２２】
図３２は、ＲＭ１２がリードコマンドを受けた場合の動作を説明するためのフローチャートであり、この図３２に示すように、ＲＭ１２は、デバイス３を占有しているＣＰＵ２からリードコマンドを受けると、そのリードコマンドについてのＴＣＢ３４を作成してから（ステップＡ３１）、ＣＦＥ１４を介してキャッシュメモリ１５上にリード対象のデータが存在するか否かを判断する（ステップＡ３２）。
【００２３】
キャッシュメモリ１５上にリード対象のデータが存在する場合（ステップＡ３２のＹＥＳルート）、ＲＭ１２は、そのデータをＣＡ１１からＣＰＵ２へ転送してから（ステップＡ３３）、そのリードコマンドについてのＴＣＢ３４を削除する（ステップＡ３４）。
一方、キャッシュメモリ１５上にリード対象のデータが存在しない場合（ステップＡ３２のＮＯルート）、ＲＭ１２は、ＣＡ１１からＣＰＵ２にチャネルエンドを報告し、ＤＡ１６にデバイス３に対するステージングを依頼し、図３３にて説明するステージング完了報告待ち処理へ移行する（ステップＡ３５）。このとき、リードコマンドについてのＴＣＢ３４は削除されることなく保持される。
【００２４】
図３３は、ＲＭ１２のステージング完了報告待ち処理を説明するためのフローチャートであり、この図３３に示すように、ＲＭ１２は、ステージングを依頼したＤＡ１６からのステージング完了報告を待機し（ステップＡ４１）、そのＤＡ１６からステージング完了報告を受けると（ステップＡ４１のＹＥＳルート）、対応するリードコマンドについてのＴＣＢ３４の再結合要因を“ステージング完了”つまり“１”に設定する（ステップＡ４２）。
【００２５】
そして、ＲＭ１２は、ステップＡ４２にて再結合要因をセットしたタスクのＴＣＢ番号を、ステージング完了報告管理テーブル３５に登録して（ステップＡ４３）、ステージング動作で読み出されたデータが、図３４にて後述するアイドルループに従って、ＣＡ１１によりＣＰＵ２へ転送されるのを待機し（ステップＡ４４）、ＣＡ１１がそのデータの転送を完了すると（ステップＡ４４のＹＥＳルート）、ステージング完了報告待ちであったリードコマンドについてのＴＣＢ３４を削除する（ステップＡ４５）。
【００２６】
図３４は、ＲＭ１２のアイドルループによる処理を説明するためのフローチャートであり、この図３４に示すように、ＲＭ１２は、常時、アイドルループにより、ステージング完了報告管理テーブル３５にＴＣＢ番号が登録されているか否か、即ち第２の再結合要因が発生しているか否かを判断した後（ステップＡ５１）、デバイスエンド報告管理テーブル３３に登録情報があるか否か、即ち第１の再結合要因が発生しているか否かを判断している（ステップＡ５３）。
【００２７】
従来、後述する理由により、ステージング完了による再結合が、デバイスリリースによる再結合よりも優先的に行なわれており、ステージング完了報告管理テーブル３５にＴＣＢ番号が登録されている場合（ステップＡ５１のＹＥＳルート）、ＲＭ１２は、そのＴＣＢ番号のＴＣＢ３４を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対してステージング完了報告を行なうようにＣＡ１１に依頼し、そのＴＣＢ番号をステージング完了報告管理テーブル３５から削除する（ステップＡ５２）。
【００２８】
ステージング完了報告管理テーブル３５に複数のＴＣＢ番号が登録されている場合には、全てのＴＣＢ番号について上述のような再結合処理が行なわれ、ステージング完了報告管理テーブル３５に登録されているＴＣＢ番号が無くなると（ステップＡ５１のＮＯルート）、デバイスエンド報告管理テーブル３３における登録情報の有無を判断し、登録情報が有る場合（ステップＡ５３のＹＥＳルート）、ＲＭ１２は、その登録情報を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対してデバイスエンド報告を行なうようにＣＡ１１に依頼し、その登録情報をデバイスエンド報告管理テーブル３３から削除する（ステップＡ５４）。
【００２９】
ついで、テーブル３１〜３３，３５およびＴＣＢ３４への具体的な登録内容について、図３５〜図４６を参照しながら説明する。
例えば、全てのテーブル３１〜３３，３５およびＴＣＢ３４に何も登録されていない状態で、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行されてくると、図３５に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リザーブ”が登録される。このとき、未だどのデバイス３もリザーブされていないので、デバイス３−０のリザーブ処理が実行され、図３６に示すように、リザーブ管理テーブル３１のデバイス番号０と“ＣＡ０”との交点位置に“１”がセットされることになる。この後、図３５に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３０】
上述のようにＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行されてくると、まず、図３７に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“２”が、コマンドとして“リザーブ”が登録される。そして、デバイス３−０がＣＰＵ２−０により既に占有されているので、ＣＰＵ２−１に対してデバイスビジーを報告してＣＰＵ２−１のチャネルインタフェースを切り離すとともに、図３８に示すように、デバイスビジー報告管理テーブル３２の“ＣＡ２”とデバイス番号０との交点位置に“１”が設定されることになる。この後、図３７に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３１】
続いて、ＣＰＵ２−１がデバイス３−１のデータをリードする場合、まず、ＣＰＵ２−１のチャネル２ａからデバイス３−１に対するリザーブコマンドが発行され、図３９に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リザーブ”が登録される。このとき、デバイス３−１はリザーブされていないので、デバイス３−１のリザーブ処理が実行され、図４０に示すように、リザーブ管理テーブル３１のデバイス番号１と“ＣＡ３”との交点位置に“１”がセットされることになる。この後、図３９に示すごとく作成されたＴＣＢ番号１のＴＣＢ３４は削除される。
【００３２】
このようにして、デバイス３−１をリザーブしたＣＰＵ２−１がリードコマンドを発行すると、図４１に示すようにＴＣＢ３４のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リード”が登録される。このとき、リード対象のデータがキャッシュメモリ１５上に存在しなければ、デバイス３−１に対するステージング動作が開始される。その間、リードコマンドについてのＴＣＢ３４は削除されることなく保持される。
【００３３】
このような状態で、デバイス３−０をリザーブしたＣＰＵ２−０がＣＡ１１−０を通じてリリースコマンドを発行すると、図４２に示すようにＴＣＢ３４のＴＣＢ番号２に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リリース”が登録される。そして、図４３に示すように、リザーブ管理テーブル３１から、デバイス番号０と“ＣＡ０”との交点位置にセットされた“１”が削除されるとともに、図４４に示すように、デバイスビジー報告管理テーブル３２の登録情報がデバイスエンド報告管理テーブル３３へ移動された後、図４２に示すごとく作成されたＴＣＢ番号２のＴＣＢ３４は削除される。
【００３４】
一方、ステージング動作を完了すると、図４５に示すように、ＴＣＢ番号１のＴＣＢ３４における再結合要因が“ステージング完了”（実際には“１”）に設定されるとともに、図４６に示すように、そのＴＣＢ番号１がステージング完了報告管理テーブル３５に登録される。
そして、ＲＭ１２は、図３４にて説明したアイドルループで、ステージング完了報告管理テーブル３５およびデバイスエンド報告管理テーブル３３を監視し、ステージング完了報告管理テーブル３５に図４６に示すごとくＴＣＢ番号１が登録されていることを認識すると、ＴＣＢ番号１のＴＣＢ３４を参照し、ＣＡ１１−３にステージング完了報告を依頼した後、ステージング完了報告管理テーブル３５からＴＣＢ番号１を削除するとともに、ＴＣＢ番号１のＴＣＢ３４を削除する。
【００３５】
また、ＲＭ１２は、ステージング完了報告管理テーブル３５に登録情報が無ければ、デバイスエンド報告管理テーブル３３を参照し、例えば図４６に示すような情報が登録されていれば、その情報に基づいて、ＣＡ１１−２に、デバイス３−０についてのデバイスエンド報告を依頼した後、デバイスエンド報告管理テーブル３３からその登録情報を削除する。
【００３６】
【発明が解決しようとする課題】
ところで、通常、リードコマンドを受けてステージング動作に移行した場合、ＦＣＵ１は、リードコマンドを発行したＣＰＵ２に対してチャネルエンドを報告してそのＣＰＵ２を一時的に切り離し、ＣＰＵ２は、ステージング完了報告待ちとなる。このステージング完了報告待ちの状態は、ＣＰＵ２にとって１つのＩ／Ｏ処理の完了待ちの状態であり、ステージング動作は比較的短時間で完了するので、それに応じた所定時間（例えば３０秒程度）の時間監視が行なわれ、所定時間を超えるとリセット処理が行なわれる。
【００３７】
これに対し、あるＣＰＵ２のアクセスしたデバイス３が他のＣＰＵ２により占有されているためにＦＣＵ１がデバイスビジー報告を行ないそのＣＰＵ２を一時的に切り離しＣＰＵ２がデバイスエンド報告待ちとなった場合、デバイス３が占有される時間は比較的長いため、それに応じた所定時間（例えば３分程度）の時間監視が行なわれ、所定時間を超えるとリセット処理が行なわれる。
【００３８】
上述のように、ステージング動作の方がデバイス３の占有よりもかなり短時間で完了するため、また、ＦＣＵ１とステージング完了報告待ちのＣＰＵ２との間はチャネルエンドの状態で切り離されており必ず再結合する必要があるため、従来、ステージング完了報告とデバイスエンド報告とは別々に管理され、ステージング完了による再結合（ステージング完了報告）は、デバイスリリースによる再結合（デバイスエンド報告）よりも優先的に行なわれている。
【００３９】
しかし、近年、ＦＣＵ１により管理されるべきデバイス３の数が極めて増大しており（例えば２５６台）、このような場合、多数のデバイス３に対するリード処理が同時に行なわれて多数のステージング動作が同時に行なわれることがあるため、ステージング完了報告が増加し、ステージング完了報告管理テーブル３５に複数のＴＣＢ番号が登録されている状況が多々生じる。このような状況下では、前述した通り、ステージング完了報告管理テーブル３５に登録されているＴＣＢ番号が無くなるまで、デバイスエンド報告に優先してステージング完了報告が行なわれることになり、いつまで経ってもデバイスエンド報告を行なえない状況が生じてしまう。
【００４０】
そこで、何回かに１回はデバイスエンド報告をステージング完了報告に優先して行なうように切り替えることも考えられるが、ＦＣＵ１は、デバイスリリースによる再結合順序（デバイスエンド報告を行なう順序）を認識していないため、特定のデバイス３に対するリザーブ／リリースが多発していると、そのデバイス３についてのデバイスエンド報告だけどうしても遅れがちになり、ＣＰＵ２へのデバイスエンド報告を行なうことの可能なデバイス３に偏りが生じる。
【００４１】
本発明は、このような課題に鑑み創案されたもので、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なえるようにして、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行可能にした、チャネルインタフェース再結合制御方法およびファイル制御装置を提供することを目的とする。
【００４２】
【課題を解決するための手段】
上記目的を達成するために、本発明のチャネルインタフェース再結合制御方法（請求項１）は、複数の処理装置が複数のファイル記憶装置を共用すべく、これらの処理装置とファイル記憶装置との間に、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置をそなえたシステムにおいて、複数の処理装置のうちの一の処理装置が複数のファイル記憶装置のうちの一つにアクセスした際に、ファイル記憶装置が複数の処理装置のうちの他の処理装置により占有されているために一の処理装置がファイル記憶装置にアクセスできない場合には、一の処理装置に対してビジー報告を行なって一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、ファイル記憶装置が他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、一の処理装置からのコマンドに応じてファイル記憶装置がステージング動作へ移行した場合には、一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する方法であって、前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしく前記第２の再結合要因の発生時に当該再結合要因に係わる該タスク制御ブロックの番号を用いて前記第１の再結合要因及び前記第２の再結合要因の発生順序を記憶し、記憶した前記発生順序に従って、前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置と該ファイル制御装置との間の前記チャネルインタフェースを再結合することを特徴としている。
【００４３】
このとき、前記ビジー報告を行なった場合には、当該ビジー報告に対応するタスク制御ブロックの番号を用いて前記ビジー報告を行なった順序を記憶し、前記第１の再結合要因の発生時には、前記ビジー報告を行なった順序に基づいて、前記再結合要因の発生順序を記憶することが好ましい（請求項２）。
【００４４】
一方、本発明のファイル制御装置（請求項３）は、複数の処理装置が複数のファイル記憶装置を共用すべく、これらの処理装置とファイル記憶装置との間にそなえられ、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するものであって、複数の処理装置のうちの一の処理装置が複数のファイル記憶装置のうちの一つにアクセスした際に、ファイル記憶装置が複数の処理装置のうちの他の処理装置により占有されているために一の処理装置が該ファイル記憶装置にアクセスできない場合には、一の処理装置に対してビジー報告を行なって一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、ファイル記憶装置が他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、一の処理装置からのコマンドに応じてファイル記憶装置がステージング動作へ移行した場合には、一の処理装置とファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する制御部と、前記再結合要因の発生順序を記憶する発生順序記憶部とをそなえ、制御部が、前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしくは第２の再結合要因の発生時に当該再結合要因に係わるタスク制御ブロックの番号を発生順序記憶部に登録することにより、前記第１の再結合要因及び前記第２の再結合要因の発生を監視してその発生順序を発生順序記憶部に記憶させるとともに、発生順序記憶部に記憶された前記発生順序に従って前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置との間の前記チャネルインタフェースを再結合させることを特徴としている。
【００４６】
また、制御部が、他の処理装置からリリースコマンドを受けた場合に前記第１の再結合要因が発生したものと判断し、発生順序記憶部に対する登録を行なってもよい（請求項４）。
なお、前記ビジー報告を行なった順序を記憶するビジー報告順序記憶部をそなえ、制御部が、前記ビジー報告を行なった場合には、当該ビジー報告に対応するタスク制御ブロックの番号をビジー報告順序記憶部に記憶させることにより、ビジー報告順序記憶部に前記ビジー報告を行なった順序を記憶させ、前記第１の再結合要因の発生時には、ビジー報告順序記憶部に記録された前記ビジー報告を行なった順序に基づいて、発生順序記憶部に当該第１の再結合要因に係わるタスク制御ブロックの番号を発生順序記憶部に登録してもよい（請求項５）。
【００４７】
さらに、制御部が、前記ステージング動作の完了報告を受けた場合に前記第２の再結合要因が発生したものと判断し、発生順序記憶部に対する登録を行なってもよい（請求項６）。
【００４８】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図２は本実施形態のファイル制御装置（ＦＣＵ）の構成を示すブロック図であり、この図２に示すように、本実施形態のＦＣＵ１Ａは、図２３に示したＦＣＵ１と同様、複数（図２中では２台）のＣＰＵ２−０，２−１が複数（図２中では３台）のデバイス３−０〜３−２を共用すべく、これらのＣＰＵ２−０，２−１とデバイス３−０〜３−２との間にそなえられ、各ＣＰＵ２−０，２−１からのコマンドに応じて各デバイス３−０〜３−２に対するアクセス動作を制御するものである。なお、２つ存在するＣＰＵのうちの一つを特定する場合には、符号２−０，２−１を用いる一方、特定する必要のない場合には符号２を用いる。同様に、３つ存在するデバイスのうちの一つを特定する場合には、符号３−０〜３−２を用いる一方、特定する必要のない場合には符号３を用いる。
【００４９】
このＦＣＵ１Ａは、ＣＡ(Channel Adapter）１１−０〜１１−３，ＲＭ(Resource Manager)１２Ａ，ＴＳ（Table Storage)１３Ｂ，ＣＦＥ（Cache Function Engine)１４，キャッシュメモリ１５，ＤＡ(Device Adapter)１６−０〜１６−２，コマンドバス１７およびデータバス１８を有して構成されている。なお、４つ存在するＣＡのうちの一つを特定する場合には、符号１１−０〜１１−３を用いる一方、特定する必要のない場合には符号１１を用いる。同様に、３つ存在するＤＡのうちの一つを特定する場合には、符号１６−０〜１６−２を用いる一方、特定する必要のない場合には符号１６を用いる。
【００５０】
ここで、ＣＡ１１−０〜１１−３は、それぞれ、チャネルインタフェースを介してＣＰＵ２−０もしくは２−１とのインタフェース制御を担当するモジュールである。なお、ＣＰＵ２−０，２−１は、例えば２つのチャネル（ＣＨ）２ａ，２ｂを有しており、図２に示す例では、ＣＰＵ２−０のチャネル２ａ，２ｂがそれぞれＣＡ１１−０，１１−１に接続され、ＣＰＵ２−１のチャネル２ａ，２ｂがそれぞれＣＡ１１−２，１１−３に接続されている。
【００５１】
ＲＭ１２Ａは、基本動作に関する資源管理を担当するモジュールであり、ＴＳ１３Ａは、資源管理用のテーブルとして使用されるメモリである。これらのＲＭ１２ＡおよびＴＳ１３Ａは、図１および図３〜図２２を参照しながら後述するごとく、２つのＣＰＵ２−０，２−１のうちの一つが３つのデバイス３−０〜３−２のうちの一つにアクセスした際に直ちにそのＣＰＵ２がデバイス３にアクセスできずそのＣＰＵ２との間のチャネルインタフェースを一時的に非結合状態とした後、再結合要因の発生に伴ってチャネルインタフェースの再結合を制御する制御部として機能する。
【００５２】
また、ＣＦＥ１４は、キャッシュメモリ１５の管理を担当するモジュールであり、ＤＡ１６−０〜１６−２は、それぞれ、磁気ディスク等のデバイス３−０〜３−２とのインタフェース制御を担当するモジュールである。
さらに、コマンドバス１７は、ＣＡ１１，ＲＭ１２Ａ，ＣＦＥ１４，ＤＡ１６の間でコマンドのやり取りを行なうためのものであり、データバス１８は、ＣＡ１１，ＣＦＥ１４，キャッシュメモリ１５，ＤＡ１６の間でデータのやり取りを行なうためのものである。
【００５３】
そして、本実施形態のＦＣＵ１Ａも、ＣＰＵ２の共用デバイスであり、あるＣＰＵ２がデバイス３を占有すると、以降、他のＣＰＵ２からのコマンドに対してデバイスビジーを報告し、他のＣＰＵ２を切り離す一方、リザーブコマンドを発行したＣＰＵ２からのリリースコマンドでデバイスが占有状態から解放されると、デバイスビジーを報告した他のＣＰＵ２に再結合を行なう（リリースによるデバイスエンド割込み：第１の再結合要因）。
【００５４】
また、リードコマンド処理時もしくはライトコマンド処理時に、デバイス３の動作（ステージング動作）を伴う場合は、ＦＣＵ１Ａは、一旦、リードコマンドもしくはライトコマンドを発行したＣＰＵ２の切り離しを行ない、デバイス３のステージング動作が終了した時点でＣＰＵ２との再結合を行なう（ステージング完了によるデバイスエンド割込み：第２の再結合要因）。
【００５５】
ついで、図１および図３〜図６を参照しながら、本実施形態のＦＣＵ１Ａにおいて、チャネルインタフェースの再結合を制御するＲＭ１２ＡおよびＴＳ１３Ａの機能的な構成について説明する。図１は、本発明の一実施形態としてのＦＣＵ１ＡにおけるＲＭ１２Ａ／ＴＳ１３Ａの機能的な構成を示すブロック図、図３〜図６はそれぞれリザーブ管理テーブル４１，デバイスビジー報告管理テーブル４２，ＴＢＣ４３および再結合管理テーブル４４を説明するための図である。
【００５６】
図１に示すように、本実施形態のＴＳ１３Ａは、リザーブ管理テーブル４１，デバイスビジー報告管理テーブル４２，ＴＢＣ４３および再結合管理テーブル４４を保持するものである。また、本実施形態のＲＭ１２Ａは、ＴＳ１３Ａのデバイスビジー報告管理テーブル４２および再結合管理テーブル４４を用いて、前述した第１の再結合要因および第２の再結合要因の発生時に再結合処理を実行する機構（ステージング完了／デバイスリリースによる再結合機構）２０として機能する。
【００５７】
リザーブ管理テーブル４１は、図３に示すように構成され、図２５に示したテーブル３１と同様、ＣＰＵ２により占有されているデバイス３を管理するためのものである。なお、テーブル４１において、“ＣＡ０”〜“ＣＡ３”はそれぞれＣＡ１１−０〜ＣＡ１１−３に対応し、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行され、デバイス３−０を占有することができた場合、ＲＭ１２Ａは、テーブル４１における“ＣＡ０”とデバイス番号０との交点位置に“１”を設定する（図１３参照）。
【００５８】
ＴＢＣ４３は、図５に示すように構成され、図２８に示したＴＣＢ３４とほぼ同様、ＲＭ１２Ａがコマンドに応じたタスクを実行する毎に作成され、そのタスクを終了する際に削除されるもので、そのタスクに関連する情報等を含み、タスクの制御に用いられる。このＴＣＢ４３には、ＣＰＵ２からのコマンドの内容（種別）と、そのコマンドを受け付けたＣＡ１１の番号と、そのコマンドの対象であるデバイス３の番号と、再結合状態とがタスク毎にタスク番号を付して保持される。
【００５９】
ここで、本実施形態のＴＣＢ４３の再結合状態には、ＲＭ１２Ａがコマンドの発行元ＣＰＵ２に対してデバイスビジーを報告した場合（第１の再結合要因で再結合すべき場合）に“ビジー”情報がセットされ（図１４参照）、リードコマンド／ライトコマンドの処理時にステージング動作に移行した場合（第２の再結合要因で再結合すべき場合）に“ステージング待ち”情報がセットされ（図１８，図１９参照）、ステージング動作移行後にそのステージング動作を完了した場合（第２の再結合要因の発生時）に“ステージング完了”情報がセットされる（図２１参照）。
【００６０】
本実施形態では、上述のごとく、ＲＭ１２Ａがコマンドの発行元ＣＰＵ２に対してデバイスビジー報告を行なった場合、その旨が再結合状態としてＴＣＢ４３に保持される。そして、デバイスビジー報告を行なった場合、そのデバイスビジー報告に係るコマンドについてのＴＣＢ４３は、従来、デバイスビジー報告後に削除されていたが、本実施形態では、デバイスリリースに伴ってデバイスエンド報告が行なわれるまで保持される。
【００６１】
つまり、本実施形態のＲＭ１２Ａは、デバイスビジー報告を行なった状態およびステージング動作の完了待ち状態を、ＴＣＢ４３により管理している。
デバイスビジー報告管理テーブル（キュー）４２は、図４に示すように構成され、ＲＭ１２Ａがデバイスビジー報告を行なった順序を記憶するビジー報告順序記憶部として機能するものである。なお、テーブル４２においても、デバイス番号０〜２はそれぞれデバイス３−０〜３−２に対応している。例えば、前述のごとくＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行された場合、ＲＭ１２Ａは、デバイスビジー報告を行なってからＣＰＵ２−１のチャネル２ａを切り離すようにＣＡ１１−２を制御するとともに、テーブル４２におけるデバイス番号０の“１番目にビジーを報告したＴＣＢ番号”の欄に、そのリザーブコマンドが登録されているＴＣＢ４３のＴＣＢ番号を登録する（図１５参照）。図４に示すテーブル４２には、デバイス３毎に、最大Ｎ個のＴＣＢ番号をデバイスビジー報告順に登録することができるようになっている。
【００６２】
再結合管理テーブル（キュー：発生順序記憶部）４４は、図６に示すように構成され、再結合要因の発生順序を記憶する発生順序記憶部として機能するものである。本実施形態のＲＭ１２Ａは、前述した第１および第２の再結合要因の発生を監視してその発生順序を再結合管理テーブル４４に記憶させるとともに、この再結合管理テーブル４４に記憶された発生順序に従って各再結合要因に係わるＣＰＵ２との間のチャネルインタフェースを再結合させるようにＣＡ１１を制御する。
【００６３】
より具体的に、ＲＭ１２Ａは、ＣＰＵ２からリリースコマンドを受けた場合に第１の再結合要因が発生したものと判断し、その第１の再結合要因に係るＴＣＢ番号を再結合管理テーブル４４に登録する一方、ステージング動作の完了報告を受けた場合に第２の再結合要因が発生したものと判断し、その第２の再結合要因に係るＴＣＢ番号を再結合管理テーブル４４に登録する。これにより、再結合管理テーブル４４には、再結合要因の種別に関係なく、第１および第２の再結合要因の発生した順序がＴＣＢ番号で登録・記憶されることになる。
【００６４】
次に、上述した本実施形態のＦＣＵ１ＡにおけるＲＭ１２ＡおよびＴＳ１３Ａの詳細な動作について、図７〜図２２を参照しながら説明する。
まず、図７〜図１１に示すフローチャートに従って、ＲＭ１２ＡおよびＴＳ１３Ａの動作の流れについて説明する。
図７は、ＲＭ１２Ａがリザーブコマンドを受けた場合の動作を説明するためのフローチャートであり、この図７に示すように、ＲＭ１２Ａは、リザーブコマンドを受けるとそのリザーブコマンドについてのＴＣＢ４３を作成してから（ステップＳ１１）、リザーブ管理テーブル４１を参照して、そのリザーブコマンドの対象デバイス３が他のＣＰＵ２（他パス，他チャネル）からリザーブされているか否かを判断する（ステップＳ１２）。
【００６５】
他パスからリザーブされていない場合（ステップＳ１２のＮＯルート）、ＲＭ１２Ａは、リザーブコマンドの対象であるデバイス３についてリザーブ処理を行なってから（ステップＳ１３）、そのリザーブコマンドについてのＴＣＢ３４を削除する（ステップＳ１４）。なお、リザーブ処理に際して、ＲＭ１２Ａは、リザーブ管理テーブル４１において、リザーブ対象のデバイス３のデバイス番号とリザーブコマンドを受け付けたＣＡ１１との交点位置に“１”をセットする。
【００６６】
一方、リザーブコマンドの対象デバイス３が他パスからリザーブされている場合（ステップＳ１２のＹＥＳルート）、ＲＭ１２Ａは、ＴＣＢ４３の再結合状態の欄に“ビジー”を登録し、ステップＳ１１で作成したＴＣＢ４３の番号（ＴＣＢ番号）を、デバイスビジー報告管理テーブル４２における、リザーブコマンドの対象デバイス３に対応するデバイス番号の欄にビジー報告順に登録し、リザーブコマンド発行元のＣＰＵ２に対してデバイスビジー報告を行なってからそのＣＰＵ２のチャネルインタフェースを切り離すようにＣＡ１１を制御する（ステップＳ１５）。このとき、ＲＭ１２Ａは従来のごとくＴＣＢ４３を削除せず、そのＴＣＢ４３は、デバイスリリースに伴ってデバイスエンド報告が行なわれるまで保持される。
【００６７】
図８は、ＲＭ１２Ａがリリースコマンドを受けた場合の動作を説明するためのフローチャートであり、この図８に示すように、ＲＭ１２Ａは、デバイス３を占有していたＣＰＵ２からリリースコマンドを受けると、そのリリースコマンドについてのＴＣＢ４３を作成してから（ステップＳ２１）、リザーブ管理テーブル４１から対応する登録（“１”の設定）を抹消し、デバイスビジー報告管理テーブル４２に、占有を解放するデバイス３についてＴＣＢ番号が登録されている場合、そのＴＣＢ番号を再結合管理テーブル４４に登録する（ステップＳ２２）。このとき、複数のＴＣＢ番号が登録されている場合には、その登録順序に従ってＴＣＢ番号を再結合管理テーブル４４に登録する。この後、ＲＭ１２Ａは、そのリリースコマンドについてのＴＣＢ４３を削除する（ステップＳ２３）。
【００６８】
図９は、ＲＭ１２Ａがリードコマンドを受けた場合の動作を説明するためのフローチャートであり、この図９に示すように、ＲＭ１２Ａは、デバイス３を占有しているＣＰＵ２からリードコマンドを受けると、そのリードコマンドについてのＴＣＢ４３を作成してから（ステップＳ３１）、ＣＦＥ１４を介してキャッシュメモリ１５上にリード対象のデータが存在するか否かを判断する（ステップＳ３２）。
【００６９】
キャッシュメモリ１５上にリード対象のデータが存在する場合（ステップＳ３２のＹＥＳルート）、ＲＭ１２Ａは、そのデータをＣＡ１１からＣＰＵ２へ転送してから（ステップＳ３３）、そのリードコマンドについてのＴＣＢ４３を削除する（ステップＳ３４）。
一方、キャッシュメモリ１５上にリード対象のデータが存在しない場合（ステップＳ３２のＮＯルート）、ＲＭ１２Ａは、ＣＡ１１からＣＰＵ２にチャネルエンドを報告し、ＤＡ１６にデバイス３に対するステージングを依頼し、図１０にて説明するステージング完了報告待ち処理へ移行するとともに、ＴＣＢ４３の再結合状態の欄に“ステージング待ち”を登録する（ステップＳ３５）。このとき、リードコマンドについてのＴＣＢ４３を削除されることなく保持される。
【００７０】
図１０は、ＲＭ１２Ａのステージング完了報告待ち処理を説明するためのフローチャートであり、この図１０に示すように、ＲＭ１２Ａは、ステージングを依頼したＤＡ１６からのステージング完了報告を待機し（ステップＳ４１）、そのＤＡ１６からステージング完了報告を受けると（ステップＳ４１のＹＥＳルート）、対応するリードコマンドについてのＴＣＢ４３の再結合状態を“ステージング待ち”から“ステージング完了”に設定する（ステップＳ４２）。
【００７１】
そして、ＲＭ１２Ａは、ステップＳ４２にて再結合状態を“ステージング完了”にセットしたタスクのＴＣＢ番号を、再結合管理テーブル４４に登録し（ステップＳ４３）、ステージング動作で読み出されたデータが、図１１にて後述するアイドルループに従って再結合されてＣＡ１１によりＣＰＵ２へ転送されるのを待機し（ステップＳ４４）、ＣＡ１１がそのデータの転送を完了すると（ステップＳ４４のＹＥＳルート）、ステージング完了報告待ちであったリードコマンドについてのＴＣＢ４３を削除する（ステップＳ４５）。
【００７２】
図１１は、ＲＭ１２Ａのアイドルループによる処理を説明するためのフローチャートであり、この図１１に示すように、ＲＭ１２Ａは、常時、アイドルループにより、再結合管理テーブル４４にＴＣＢ番号が登録されているか否か、即ち第１もしくは第２の再結合要因が発生しているか否かを判断している（ステップＳ５３）。
【００７３】
再結合管理テーブル４４にＴＣＢ番号が登録されている場合（ステップＳ５１のＹＥＳルート）、ＲＭ１２Ａは、そのＴＣＢ番号のＴＣＢ４３を参照し、対応するＣＰＵ２との再結合を行ないそのＣＰＵ２に対して再結合状態に応じた処理を行なうようにＣＡ１１に依頼する（ステップＳ５２）。ここで、再結合状態が“ビジー”である場合、ＲＭ１２Ａは、ＣＡ１１に、ＣＰＵ２に対しデバイスエンドを報告させる一方、再結合状態が“ステージング完了”である場合、ＲＭ１２Ａは、ＣＡ１１に、ＣＰＵ２に対しステージング完了を報告させリードデータの転送を行なわせる。
【００７４】
そして、ステップＳ５２で行なわれた再結合がデバイスリリース（第１の再結合要因）によるものであるか否かを判断し（ステップＳ５３）、デバイスリリースによるものである場合（ステップＳ５３のＹＥＳルート）、対応するＴＣＢ４３を削除する（ステップＳ５４）。一方、デバイスリリースによるものではない場合（ステージング完了による再結合の場合；ステップＳ５３のＮＯルート）、ＴＣＢ４３の削除は図１０のステップＳ４５で行なわれているので、何も行なうことなく、ステップＳ５１へ戻る。
【００７５】
ついで、テーブル４１，４３，４４およびＴＣＢ４３への具体的な登録内容について、図１２〜図２２を参照しながら説明する。
例えば、全てのテーブル４１，４２，４４およびＴＣＢ４３に何も登録されていない状態で、ＣＰＵ２−０のチャネル２ａからデバイス３−０に対するリザーブコマンドが発行されてくると、図１２に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リザーブ”が登録される。このとき、未だどのデバイス３もリザーブされていないので、デバイス３−０のリザーブ処理が実行され、図１３に示すように、リザーブ管理テーブル４１のデバイス番号０と“ＣＡ０”との交点位置に“１”がセットされることになる。この後、図１２に示すごとく作成されたＴＣＢ番号１のＴＣＢ４３は削除される。
【００７６】
上述のようにＣＰＵ２−０がチャネル２ａ（ＣＡ１１−０）を通じてデバイス３−０を占有している状態で、ＣＰＵ２−１のチャネル２ａ（ＣＡ１１−２）を通じてデバイス３−０に対するリザーブコマンドが発行されてくると、まず、図１４に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“０”が、ＣＡ番号として“２”が、コマンドとして“リザーブ”が登録される。そして、デバイス３−０がＣＰＵ２−０により既に占有されているので、ＣＰＵ２−１に対してデバイスビジーを報告してＣＰＵ２−１のチャネルインタフェースを切り離し、図１４に示すように、ＴＣＢ番号１の再結合状態に“ビジー”が設定されるとともに、図１５に示すように、デバイスビジー報告管理テーブル４２における、デバイス番号０の“１番目にビジーを報告したＴＣＢ番号”の欄に、ＴＣＢ番号１が設定される。このとき、図１４に示すＴＣＢ番号１のＴＣＢ４３は、削除されず、デバイスエンドの報告が行なわれるまで保持される。
【００７７】
続いて、ＣＰＵ２−１がデバイス３−１のデータをリードする場合、まず、ＣＰＵ２−１のチャネル２ｂからデバイス３−１に対するリザーブコマンドが発行され、図１６に示すようにＴＣＢ４３のＴＣＢ番号２に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リザーブ”が登録される。このとき、デバイス３−１はリザーブされていないので、デバイス３−１のリザーブ処理が実行され、図１７に示すように、リザーブ管理テーブル４１のデバイス番号１と“ＣＡ３”との交点位置に“１”がセットされることになる。この後、図１６に示すごとく作成されたＴＣＢ番号２のＴＣＢ４３は削除される。
【００７８】
このようにして、デバイス３−１をリザーブしたＣＰＵ２−１がリードコマンドを発行すると、図１８に示すようにＴＣＢ４３のＴＣＢ番号１に、デバイス番号として“１”が、ＣＡ番号として“３”が、コマンドとして“リード”が登録される。このとき、リード対象のデータがキャッシュメモリ１５上に存在しなければ、デバイス３−１に対するステージング動作が開始され、ＴＣＢ番号２の再結合状態に“ステージング待ち”が設定される。このＴＣＢ番号２のＴＣＢ４３は、ステージング動作が完了するまで削除されることなく保持される。
【００７９】
このような状態で、デバイス３−０をリザーブしたＣＰＵ２−０がＣＡ１１−０を通じてリリースコマンドを発行すると、図１９に示すようにＴＣＢ４３のＴＣＢ番号３に、デバイス番号として“０”が、ＣＡ番号として“０”が、コマンドとして“リリース”が登録される。そして、図２０に示すように、リザーブ管理テーブル４１から、デバイス番号０と“ＣＡ０”との交点位置にセットされた“１”が削除されるとともに、図２２に示すように、再結合管理テーブル４４の再結合順序１に対応する欄にＴＣＢ番号１が登録された後、図１９に示すごとく作成されたＴＣＢ番号３のＴＣＢ４３は削除される。
【００８０】
デバイス３−０の解放に続いてステージング動作を完了すると、図２１に示すように、ＴＣＢ番号２のＴＣＢ４３における再結合状態が“ステージング完了”に設定されるとともに、図２２に示すように、そのＴＣＢ番号２が再結合管理テーブル４４の再結合順序２に対応する欄に登録される。
そして、ＲＭ１２Ａは、図１１にて説明したアイドルループで、再結合管理テーブル４４を監視し、この再結合管理テーブル４４に図２２に示すごとくＴＣＢ番号１およびＴＣＢ番号２が登録されていることを認識すると、その登録順序に従って再結合処理をＣＡ１１に依頼する。つまり、ここでは、まず、ＴＣＢ番号１のＴＣＢ４３を参照し、ＣＡ１１−２に、デバイス３−０についてのデバイスエンド報告を依頼した後、そのＴＣＢ４３を削除する。ついで、ＴＣＢ番号２のＴＣＢ４３を参照し、ＣＡ１１−３にステージング完了報告を依頼した後、そのＴＣＢ４３を削除する。
【００８１】
このように、本発明の一実施形態によれば、ステージング完了報告を管理するテーブルとデバイスエンド報告を管理するテーブルとが１つの再結合管理テーブル４４に融合され、この再結合管理テーブル４４を図１１に示すアイドルループに従って検索することにより、再結合要因の発生した順にＣＡ１１に再結合を依頼することができる。つまり、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なうことができるので、再結合処理に偏りが生じることがなく、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行することができる。
【００８２】
従って、デバイスリリースを行なったデバイス順にデバイスエンド報告を行なえ、ステージング完了報告数の増加に伴い従来生じていたデバイスエンド報告の沈み込みを確実に回避することができる。
また、本実施形態によれば、デバイスビジー報告管理テーブル４２に、デバイスビジー報告を行なった順序でＴＣＢ番号を登録しておくことにより、デバイスビジー報告を行なった順序でデバイスエンド報告を行なうことが可能になり、デバイスエンド報告の遅れを抑止することもできる。
【００８３】
さらに、本実施形態によれば、デバイスビジー報告を行なった状態およびステージング動作の完了待ち状態をＴＣＢ４３で管理しているので、ＴＣＢ番号を用いて再結合処理の順序を管理することができ、再結合処理を大幅に簡素化できる利点もある。
なお、本発明は上述した実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
【００８４】
例えば、上述した実施形態では、処理装置としてのＣＰＵ２が２台、ファイル記憶装置としてのデバイス３が３台である場合について説明しているが、本発明は、このような台数に限定されるものではない。
また、上述した実施形態では、再結合要因がデバイスリリースとステージング完了との２種類である場合について説明したが、本発明は、これに限定されるものではなく、再結合要因が３種類以上である場合や、異なる種類の再結合要因を含む場合にも同様に適用され、上述した実施形態と同様の作用効果を得ることができる。
【００８５】
【発明の効果】
以上詳述したように、本発明のチャネルインタフェース再結合制御方法（請求項１，２）およびファイル制御装置（請求項３〜６）によれば、再結合要因の種類によることなく再結合要因の発生順に再結合処理を行なうことができるので、リリースによるデバイスエンド報告およびステージング完了報告をいずれも遅延・沈み込ませることなく実行することができる。従って、デバイスリリースを行なったデバイス順にデバイスエンド報告を行なえ、ステージング完了報告数の増加に伴い従来生じていたデバイスエンド報告の沈み込みを確実に回避することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態としてのファイル制御装置（ＦＣＵ）におけるＲＭ／ＴＳの機能的な構成を示すブロック図である。
【図２】本実施形態のファイル制御装置（ＦＣＵ）の構成を示すブロック図である。
【図３】本実施形態のリザーブ管理テーブルを説明するための図である。
【図４】本実施形態のデバイスビジー報告管理テーブル（キュー：ビジー報告順序記憶部）を説明するための図である。
【図５】本実施形態のタスク制御ブロック（ＴＢＣ）を説明するための図である。
【図６】本実施形態の再結合管理テーブル（キュー：発生順序記憶部）を説明するための図である。
【図７】本実施形態のＲＭがリザーブコマンドを受けた場合の動作を説明するためのフローチャートである。
【図８】本実施形態のＲＭがリリースコマンドを受けた場合の動作を説明するためのフローチャートである。
【図９】本実施形態のＲＭがリードコマンドを受けた場合の動作を説明するためのフローチャートである。
【図１０】本実施形態のＲＭのステージング完了報告待ち処理を説明するためのフローチャートである。
【図１１】本実施形態のＲＭのアイドルループによる処理を説明するためのフローチャートである。
【図１２】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１３】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図１４】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１５】本実施形態のデバイスビジー報告管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【図１６】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１７】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図１８】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図１９】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図２０】本実施形態のリザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図２１】本実施形態のＴＣＢへの具体的な登録内容について説明するための図である。
【図２２】本実施形態の再結合管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【図２３】一般的なＦＣＵの構成を示すブロック図である。
【図２４】従来のＲＭ／ＴＳの機能的な構成を示すブロック図である。
【図２５】リザーブ管理テーブルを説明するための図である。
【図２６】デバイスビジー報告管理テーブルを説明するための図である。
【図２７】デバイスエンド報告管理テーブルを説明するための図である。
【図２８】タスク制御ブロック（ＴＢＣ）を説明するための図である。
【図２９】ステージング完了報告管理テーブル（キュー）を説明するための図である。
【図３０】ＲＭがリザーブコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３１】ＲＭがリリースコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３２】ＲＭがリードコマンドを受けた場合の動作を説明するためのフローチャートである。
【図３３】ＲＭのステージング完了報告待ち処理を説明するためのフローチャートである。
【図３４】ＲＭのアイドルループによる処理を説明するためのフローチャートである。
【図３５】ＴＣＢへの具体的な登録内容について説明するための図である。
【図３６】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図３７】ＴＣＢへの具体的な登録内容について説明するための図である。
【図３８】デバイスビジー報告管理テーブルへの具体的な登録内容について説明するための図である。
【図３９】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４０】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図４１】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４２】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４３】リザーブ管理テーブルへの具体的な登録内容について説明するための図である。
【図４４】デバイスエンド報告管理テーブルへの具体的な登録内容について説明するための図である。
【図４５】ＴＣＢへの具体的な登録内容について説明するための図である。
【図４６】ステージング完了報告管理テーブル（キュー）への具体的な登録内容について説明するための図である。
【符号の説明】
１Ａ ファイル制御装置（ＦＣＵ）
２，２−０，２−１ ＣＰＵ（処理装置）
２ａ，２ｂ チャネル（ＣＨ）
３，３−０〜３−２ デバイス（ＤＶ，ファイル記憶装置）
１１，１１−０〜１１−３ ＣＡ(Channel Adapter）
１２Ａ ＲＭ(Resource Manager:制御部）
１３Ａ ＴＳ(Table Storage）
１４ ＣＦＥ(Cache Function Engine）
１５ キャッシュメモリ
１６，１６−０〜１６−２ ＤＡ(Device Adapter)
１７ コマンドバス
１８ データバス
２０ ステージング完了／デバイスリリースによる再結合機構（制御部）
４１ リザーブ管理テーブル
４２ デバイスビジー報告管理テーブル（キュー：ビジー報告順序記憶部）
４３ タスク制御ブロック（ＴＣＢ）
４４ 再結合管理テーブル（キュー：発生順序記憶部）
Claims (6)
- 複数の処理装置が複数のファイル記憶装置を共用すべく、該複数の処理装置と該複数のファイル記憶装置との間に、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置をそなえたシステムにおいて、該複数の処理装置のうちの一の処理装置が該複数のファイル記憶装置のうちの一つにアクセスした際に、該ファイル記憶装置が該複数の処理装置のうちの他の処理装置により占有されているために該一の処理装置が該ファイル記憶装置にアクセスできない場合には、該一の処理装置に対してビジー報告を行なって該一の処理装置と該ファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、該ファイル記憶装置が該他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、該一の処理装置からのコマンドに応じて該ファイル記憶装置がステージング動作へ移行した場合には、該一の処理装置と該ファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する方法であって、
前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしく前記第２の再結合要因の発生時に当該再結合要因に係わる該タスク制御ブロックの番号を用いて前記第１の再結合要因及び前記第２の再結合要因の発生順序を記憶し、
記憶した前記発生順序に従って、前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置と該ファイル制御装置との間の前記チャネルインタフェースを再結合することを特徴とする、チャネルインタフェース再結合制御方法。 - 前記ビジー報告を行なった場合には、当該ビジー報告に対応する該タスク制御ブロックの番号を用いて前記ビジー報告を行なった順序を記憶し、
前記第１の再結合要因の発生時には、前記ビジー報告を行なった順序に基づいて、前記再結合要因の発生順序を記憶することを特徴とする、請求項１記載のチャネルインタフェース再結合制御方法。 - 複数の処理装置が複数のファイル記憶装置を共用すべく、該複数の処理装置と該複数のファイル記憶装置との間にそなえられ、各処理装置からのコマンドに応じて各ファイル記憶装置に対するアクセス動作を制御するファイル制御装置であって、
該複数の処理装置のうちの一の処理装置が該複数のファイル記憶装置のうちの一つにアクセスした際に、該ファイル記憶装置が該複数の処理装置のうちの他の処理装置により占有されているために該一の処理装置が該ファイル記憶装置にアクセスできない場合には、該一の処理装置に対してビジー報告を行なって該一の処理装置と該ファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、該ファイル記憶装置が該他の処理装置から解放されたことによる第１の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する一方、該一の処理装置からのコマンドに応じて該ファイル記憶装置がステージング動作へ移行した場合には、該一の処理装置と該ファイル記憶装置との間のチャネルインタフェースを一時的に非結合状態とした後に、前記ステージング動作を完了したことによる第２の再結合要因の発生に伴って前記チャネルインタフェースの再結合を制御する制御部と、
前記再結合要因の発生順序を記憶する発生順序記憶部とをそなえ、
該制御部が、前記ビジー報告を行なった状態及び前記ステージング動作の完了待ち状態をタスク制御ブロックにより管理し、前記第１の再結合要因もしくは第２の再結合要因の発生時に当該再結合要因に係わる該タスク制御ブロックの番号を該発生順序記憶部に登録することにより、前記第１の再結合要因及び前記第２の再結合要因の発生を監視してその発生順序を該発生順序記憶部に記憶させるとともに、該発生順序記憶部に記憶された前記発生順序に従って前記第１の再結合要因もしくは前記第２の再結合要因に係わる処理装置との間の前記チャネルインタフェースを再結合させることを特徴とする、ファイル制御装置。 - 該制御部が、該他の処理装置からリリースコマンドを受けた場合に前記第１の再結合要因が発生したものと判断し、該発生順序記憶部に対する登録を行なうことを特徴とする、請求項３記載のファイル制御装置。
- 前記ビジー報告を行なった順序を記憶するビジー報告順序記憶部をそなえ、
該制御部が、前記ビジー報告を行なった場合には、当該ビジー報告に対応する該タスク制御ブロックの番号を該ビジー報告順序記憶部に記憶させることにより、該ビジー報告順序記憶部に前記ビジー報告を行なった順序を記憶させ、前記第１の再結合要因の発生時には、該ビジー報告順序記憶部に記録された前記ビジー報告を行なった順序に基づいて、該発生順序記憶部に当該第１の再結合要因に係わる該タスク制御ブロックの番号を該発生順序記憶部に登録することを特徴とする、請求項３または４記載のファイル制御装置。 - 該制御部が、前記ステージング動作の完了報告を受けた場合に前記第２の再結合要因が発生したものと判断し、該発生順序記憶部に対する登録を行なうことを特徴とする、請求項３〜５のいずれか１項に記載のファイル制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34635798A JP3696740B2 (ja) | 1998-12-07 | 1998-12-07 | チャネルインタフェース再結合制御方法およびファイル制御装置 |
| US09/348,074 US6338054B1 (en) | 1998-12-07 | 1999-07-06 | Channel interface re-connection controlling method and file controlling apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34635798A JP3696740B2 (ja) | 1998-12-07 | 1998-12-07 | チャネルインタフェース再結合制御方法およびファイル制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000172623A JP2000172623A (ja) | 2000-06-23 |
| JP3696740B2 true JP3696740B2 (ja) | 2005-09-21 |
Family
ID=18382872
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34635798A Expired - Fee Related JP3696740B2 (ja) | 1998-12-07 | 1998-12-07 | チャネルインタフェース再結合制御方法およびファイル制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6338054B1 (ja) |
| JP (1) | JP3696740B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263556B1 (en) * | 2000-08-11 | 2007-08-28 | Microsoft Corporation | System and method of enhancing server throughput by minimizing timed-wait TCP control block (TWTCB) size |
| US8078730B2 (en) * | 2000-12-22 | 2011-12-13 | Rockstar Bidco, LP | System, device, and method for maintaining communication sessions in a communication system |
| US7702801B1 (en) * | 2001-04-19 | 2010-04-20 | Advanced Micro Devices, Inc. | Determining logon status in a broadband network system and automatically restoring logon connectivity |
| US9069667B2 (en) * | 2008-01-28 | 2015-06-30 | International Business Machines Corporation | Method to identify unique host applications running within a storage controller |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4207609A (en) * | 1978-05-08 | 1980-06-10 | International Business Machines Corporation | Method and means for path independent device reservation and reconnection in a multi-CPU and shared device access system |
| JPS60100238A (ja) | 1983-11-02 | 1985-06-04 | Nec Corp | 共用フアイル制御システム |
| JPH02170219A (ja) | 1988-12-23 | 1990-07-02 | Hitachi Ltd | デバイスクロスコール制御方式 |
| JPH0328934A (ja) | 1989-06-27 | 1991-02-07 | Oki Electric Ind Co Ltd | 共有資源のデッドロック防止方法 |
| JP2699600B2 (ja) | 1990-01-30 | 1998-01-19 | 日本電気株式会社 | 資源の排他制御方式 |
| US5787278A (en) * | 1994-12-28 | 1998-07-28 | Pitney Bowes Inc. | Method and system for generating and mailing a system performance report, utilizing a report template with predetermined control commands for controlling the printer |
| US5805578A (en) * | 1995-10-27 | 1998-09-08 | International Business Machines Corporation | Automatic reconfiguration of multipoint communication channels |
| US6215782B1 (en) * | 1996-12-20 | 2001-04-10 | Lucent Technologies Inc. | Method for reconnecting calls in a wireless telecommunications system |
| US6061559A (en) * | 1998-03-26 | 2000-05-09 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for reconnecting a disconnected low priority call in a mobile telecommunications network |
-
1998
- 1998-12-07 JP JP34635798A patent/JP3696740B2/ja not_active Expired - Fee Related
-
1999
- 1999-07-06 US US09/348,074 patent/US6338054B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6338054B1 (en) | 2002-01-08 |
| JP2000172623A (ja) | 2000-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8266375B2 (en) | Automated on-line capacity expansion method for storage device | |
| US6157962A (en) | Multipath I/O storage systems with multiipath I/O request mechanisms | |
| US6633925B2 (en) | Operating system for generating overlapped input-output requests to a device in a disk array storage | |
| JP4371724B2 (ja) | 記憶システム及び記憶装置システム | |
| JP3209634B2 (ja) | 計算機システム | |
| US7334097B2 (en) | Method for controlling storage device controller, storage device controller, and program | |
| JP2000181773A (ja) | 記憶装置システム | |
| JP2005309550A (ja) | リモートコピー方法及びリモートコピーシステム | |
| JP3617437B2 (ja) | データコピー方法およびデータコピー用プログラムを記録したプログラム記録媒体 | |
| US7610461B2 (en) | Storage system with mainframe and open host performing remote copying by setting a copy group | |
| JP4074442B2 (ja) | データのバックアップのための方法、装置、システム、プログラム及び記憶媒体 | |
| JP3696740B2 (ja) | チャネルインタフェース再結合制御方法およびファイル制御装置 | |
| JPH0844649A (ja) | データ処理装置 | |
| US8214613B2 (en) | Storage system and copy method | |
| JP3425355B2 (ja) | 多重書き込み記憶装置 | |
| JP4791265B2 (ja) | 信号処理方法、信号処理プログラムおよび信号処理装置 | |
| JP3778405B2 (ja) | ディスクサブシステム | |
| JP2732951B2 (ja) | データ転送制御方法 | |
| JPH0830402A (ja) | パリティ格納方法 | |
| JP2000163277A (ja) | Ｄａｓｄ制御装置間のデータ転送方法 | |
| JP2005327015A (ja) | データ二重化方法とプログラム | |
| JPH0235546A (ja) | 補助記憶装置への書き込み制御方式 | |
| JPH04102135A (ja) | ファイル二重化制御方式 | |
| JPH05324490A (ja) | ディスクアレイ制御装置 | |
| JPH08235085A (ja) | 入出力制御装置及びその制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050218 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050308 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050509 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050621 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050630 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080708 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090708 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100708 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100708 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110708 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110708 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120708 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120708 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130708 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |