(57)【要約】本発明の一実施形態において、メモリシステムは、少なくとも１つのイニシエータと、ＳＡＴＡデバイスと、改善されたブリッジデバイスとを含むことが開示される。該改善されたブリッジデバイスは、該少なくとも１つのイニシエータと該ＳＡＴＡデバイスとの間の通信を容易にするように構成され、そして少なくとも１つの入力ポートを有し、該（１つ以上の）入力ポートを介して該イニシエータからの情報を受信するように動作可能である。該改善されたブリッジデバイスは、通知イベントの間に、通知が該少なくとも１つのイニシエータに送信される通知イベントを処理し、そしてイベントに基づいて動作を実行し、それによって、イニシエータとＳＡＴＡデバイスとの間の通信の容易さを促進する。
2010519617.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのイニシエータと、
シリアルアドバンストテクノロジーアタッチメント（ＳＡＴＡ）デバイスと、
該少なくとも１つのイニシエータと該ＳＡＴＡデバイスとの間の通信を容易にするように構成され、そして少なくとも１つのシリアルアタッチトスモールコンピュータシステムインターフェイス（ＳＣＳＩ）（ＳＡＳ）入力ポートを有し、該少なくとも１つの入力ポートを介して該イニシエータからの情報を受信するように動作可能である改善されたブリッジデバイスであって、通知イベントの間に、通知が該少なくとも１つのイニシエータに送信される通知イベントを処理し、そしてイベントに基づいて動作を実行し、それによって、通信の容易さを促進する、改善されたブリッジデバイスと
を備える、メモリシステム。
【請求項２】
前記少なくとも１つの入力ポートは、少なくとも１つのＳＡＳ入力ポートである、請求項１に記載のメモリシステム。
【請求項３】
前記複数のイニシエータと前記改善されたブリッジデバイスとの間に連結された複数のエクスパンダをさらに含む、請求項１に記載のメモリシステム。
【請求項４】
前記少なくとも１つの入力ポートは、少なくとも１つのＳＡＴＡ入力ポートである、請求項１に記載のメモリシステム。
【請求項５】
エクスパンダは、イニシエータを含む、請求項３に記載のメモリシステム。
【請求項６】
前記改善されたブリッジデバイスは、マルチポートＳＡＳ  ｍｕｘおよびＳＡＳ−ＳＡＴＡブリッジデバイスである、請求項１に記載のメモリシステム。
【請求項７】
前記改善されたブリッジデバイスは、前記複数のイニシエータおよびＳＡＳポートをそれらの対応する通知イベントと関連づけるために用いられるアフィリエーションテーブルを含み、該通知イベントは、対応するイニシエータが該改善されたブリッジデバイスにアクセスすることを妨げられる条件を示す、請求項６に記載のメモリシステム。
【請求項８】
入って来るイニシエータコマンドに基づいて、前記イニシエータのタグから動的に割り当て可能な予備のタグをさらに含み、該予備のタグは、前記ＳＡＴＡデバイスにコマンドを発行するために用いられる、請求項１に記載のメモリシステム。
【請求項９】
前記割り当てられるタグを再要求するために、イニシエータと関連づけられたアフィリエーションをクリアする手段をさらに含む、請求項８に記載のメモリシステム。
【請求項１０】
前記割り当てられる予備のタグは、イニシエータタグに割り当てられる予備のタグであり、連続した順序にある、請求項８に記載のメモリシステム。
【請求項１１】
前記アフィリエーションテーブルは、それと関連づけられた深さを有し、該深さは、所定の深さに制限される、請求項６に記載のメモリシステム。
【請求項１２】
イニシエータの間で渡される情報を含むメールボックス情報を含むメールボックステーブルをさらに含む、請求項６に記載のメモリシステム。
【請求項１３】
前記ブリッジデバイスのトポロジへの変化のステータスを維持するアフィリエーションカウンタをさらに含み、該カウンタが最後に読み取られたときに、該カウンタの現在の値と、該カウンタの前の値との間の値の不整合は、該ブリッジデバイスのトポロジの変化を示す、請求項１２に記載のメモリシステム。
【請求項１４】
前記アフィリエーションテーブルは、イニシエータを識別し、かつ１つ以上のポートによってアフィリエートされるＳＡＳアドレスを含み、そしてさらに、アフィリエートされたＳＡＳアドレスは、ＳＡＳアドレスの新しい組に原子的に移動される、請求項１２に記載のメモリシステム。
【請求項１５】
前記アフィリエーションテーブルは、前記改善されたブリッジデバイスと通信するべき所定の時間をすでに超えたイニシエータと関連づけられるＳＡＳアドレスについてクリアさせられる、請求項１４に記載のメモリシステム。
【請求項１６】
１つ以上のエクスパンダをさらに含み、前記改善されたブリッジデバイスは、前記複数のイニシエータおよびＳＡＳポートをそれらの対応する通知イベントと関連づけるために用いられるアフィリエーションテーブルを含み、該通知イベントは、対応するイニシエータが該改善されたブリッジデバイスにアクセスすることを妨げられる条件を示す、請求項１５に記載のメモリシステム。
【請求項１７】
前記複数のイニシエータおよびＳＡＳポートをそれらの対応する通知イベントと関連づけるために用いられるアフィリエーションテーブルを含む１つ以上のエクスパンダをさらに含み、該通知イベントは、対応するイニシエータが該改善されたブリッジデバイスにアクセスすることを妨げられる条件を示す、請求項１に記載のメモリシステム。
【請求項１８】
前記改善されたブリッジデバイスに連結された１つ以上のエクスパンダをさらに含み、前記イニシエータは、該改善されたブリッジデバイスに割込みを引き起こす通知イベントによって割込み駆動され、それによって、該イベントの位置を見出すためにエクスパンダにクエリすることを回避する、請求項１に記載のメモリシステム。
【請求項１９】
前記改善されたブリッジデバイスに連結された１つ以上のエクスパンダをさらに含み、前記イニシエータは、割込み駆動され、そこでは、通知イベントの発生の際に、該改善されたブリッジデバイスに該通知イベントを知らせる割込みが引き起こされ、さらに、リンクは、該通知イベントの結果としてドロップされない、請求項１に記載のメモリシステム。
【請求項２０】
前記改善されたブリッジデバイスに連結された１つ以上のエクスパンダをさらに含み、該改善されたブリッジデバイスは、通知フレームまたはプリミティブを前記イニシエータに対して生成し、該イニシエータは、該フレームまたはプリミティブを該イニシエータ自体への割込みとして用いる、請求項１に記載のメモリシステム。
【請求項２１】
障害が起きた前記少なくとも１つのイニシエータのうちの１つを置き換える置換イニシエータをさらに含む、請求項７に記載のメモリシステム。
【請求項２２】
改善されたブリッジデバイスであって、
該デバイスを少なくとも１つのイニシエータに連結する少なくとも２つのＳＡＳ入力ポートと、
該デバイスをディスクドライブに連結するＳＡＴＡポートと、
受信された情報を該ディスクドライブとの通信のためのＳＡＴＡ情報に変換するためのブリッジであって、該デバイスは、該複数のイニシエータのうちの少なくとも２つのイニシエータの間の通信を引き起こし、該マルチポートブリッジデバイスは、該少なくとも１つのイニシエータと該ディスクドライブとの間の通信を容易にするように構成され、そして少なくとも２つのＳＡＳ入力ポートを有し、該入力ポートを介して該イニシエータからの情報を受信するように動作可能に連結され、該マルチポートブリッジデバイスは、通知イベントの間に、通知が該少なくとも１つのイニシエータに送信される通知イベントを処理し、そしてイベントに基づいて動作を実行し、それによって、通信の容易さを促進する、ブリッジと
を備える、改善されたブリッジデバイス。
【請求項２３】
前記デバイスは、ターゲットである、請求項２２に記載の改善されたブリッジデバイス。
【請求項２４】
前記複数のイニシエータおよびＳＡＳポートをそれらの対応する通知イベントと関連づけるために用いられるアフィリエーションテーブルをさらに含み、該通知イベントは、対応するイニシエータが前記改善されたブリッジデバイスにアクセスすることを妨げられる条件を示す、請求項２２に記載の改善されたブリッジデバイス。
【請求項２５】
イニシエータの間で渡される情報を含むメールボックステーブルをさらに含む、請求項２２に記載の改善されたブリッジデバイス。
【請求項２６】
アフィリエーションテーブルへの変化があるたびにインクリメントするアフィリエーションカウンタをさらに含む、請求項２２に記載の改善されたブリッジデバイス。
【請求項２７】
通知フラグを設定することと、
通知を１つ以上のイニシエータに送信することと、
イベントに基づいて動作を実行することと、
該通知フラグをクリアすることと
を包含する、１つ以上のイニシエータにイベントを通知する方法。
【請求項２８】
前記通知イベントは、エラーイベントである、請求項２７に記載の１つ以上のイニシエータにイベントを通知する方法。
【請求項２９】
前記通知イベントは、非エラーイベントである、請求項２７に記載の１つ以上のイニシエータにイベントを通知する方法。
【請求項３０】
ＳＴＰまたはＳＭＰオープンを要求することをさらに含む、請求項２７に記載の通知する方法。
【請求項３１】
前記通知フラグが設定されているか否かを決定することと、設定されていない場合には、通常動作を実行することとをさらに含む、請求項２７に記載の通知する方法。
【請求項３２】
前記通知フラグが設定されていることを決定する際に、前記通知が、意図されたイニシエータに送信されるか否かを決定することと、送信される場合には、ＳＴＰリトライを発行することとをさらに含む、請求項２７に記載の通知する方法。
【請求項３３】
通知フラグが設定されていないことを決定する際に、通知が送信されるように準備できているか否かを決定することと、準備できている場合には、該通知を送信することと、準備できていない場合には、ＳＴＰリトライを発行することとをさらに含む、請求項３２に記載の通知する方法。
【請求項３４】
前記通知フラグをクリアすることをさらに含む、請求項３３に記載の通知する方法。
【請求項３５】
コマンドを一掃することをさらに含む、請求項３４に記載の通知する方法。
【請求項３６】
フラグのクリアを受容することをさらに含む、請求項３３に記載の通知する方法。
【請求項３７】
ログデータを読み取る通知を受信することと、
ＳＭＰを介してログデータを読み取ることを要求することと、
読み取りログデータが準備できているか否かを決定することと、
読み取りログデータを戻すことと
を包含する、読み取りログデータを１つ以上のイニシエータによって受信する方法。
【請求項３８】
読み取りログデータがフェッチされるか否かを決定することと、フェッチされる場合には、読み取りログデータの通知を受信することと、フェッチされない場合には、読み取りログデータが利用可能でないことを戻すこととを含む、請求項３７に記載の読み取りログデータを受信する方法。
【請求項３９】
イニシエータと関連づけられたタグを再マッピングすることをさらに含む、請求項３７に記載の読み取りログデータを受信する方法。
【請求項４０】
理由コードとともに通知フラグを設定することと、
通知を特定のイニシエータに送信することと、
該理由コードに基づいて動作を実行することと
を包含する、２つ以上のイニシエータの間で情報を転送する方法。
【請求項４１】
メールボックステーブル内に情報を格納することと、
理由コードとともに通知フラグを設定することと、
通知を特定のイニシエータに送信することと、
該格納された情報を、該理由コードに基づいて読み取られるようにさせることと
を包含する、２つ以上のイニシエータの間で情報を転送する方法。
【請求項４２】
通知を送信することは、ＳＡＴＡコマンドに影響することなく実行される、請求項４１に記載の情報を転送する方法。
【請求項４３】
アクセスするために複数のイニシエータに連結されたＳＡＴＡディスクドライブと関連づけられるエラーを検出する方法であって、
エラーを検出することと、
通知フラグを設定することと、
エラーの通知を特定のイニシエータに送信することと、
該ドライブをリセットすることと、
非障害のコマンドをドライブに再送信することと、
通知フラグをクリアすることと
を包含する、方法。
【請求項４４】
アクセスするために複数のイニシエータに連結されたＳＡＴＡディスクドライブをリセットする方法であって、
ディスクドライブをリセットするためにコマンドを受信することと、
該複数のイニシエータのステータスを「通知」に設定することと、
エラーログ情報をフェッチすることと、
該エラーログ情報を格納することと、
該ドライブをリセットすることと
を包含する、方法。
【請求項４５】
特定のイニシエータのステータスについてクエリされるステップと、該特定のイニシエータに該特定のイニシエータの「通知」のステータスを知らせるステップとをさらに含む、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項４６】
前記複数のイニシエータに対する前記「通知」ステータスをクリアすることをさらに含む、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項４７】
前記エラーログ情報を要求イニシエータに戻すことをさらに含む、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項４８】
同じ同報通信を引き起こすことを回避することをさらに含む、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項４９】
前記ドライブをリセットすることは、リンクをドロップすることなく実行される、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項５０】
前記ドライブをリセットすることは、リンクを介して実行され、いかなるリンクもドロップさせることなく該リセットすることを別のポートに伝播させる、請求項４４に記載のＳＡＴＡディスクドライブをリセットする方法。
【請求項５１】
読み取りログデータ以外のログデータの通知を受信することと、
ＳＭＰを介して該ログデータを要求することと、
該ログデータが準備できているか否かを決定することと、
該ログデータを戻すことと
を包含する、１つ以上のイニシエータによってログデータを受信する方法。
【請求項５２】
ログデータがフェッチされるか否かを決定することと、フェッチされる場合には、該ログデータの通知を受信することと、フェッチされない場合には、該ログデータが利用可能でないことを戻すこととをさらに含む、請求項５１に記載のログデータを受信する方法。
【請求項５３】
イニシエータと関連づけられたタグを再マッピングすることをさらに含む、請求項５１に記載のログデータを受信する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本願は、２００６年１２月２２日に出願された本発明者の米国特許出願第１１／６４４，５４９号、発明の名称「Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ  （ＳＡＴＡ）  Ａｎｄ  Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ  （ＳＣＳＩ）  （ＳＡＳ）  Ｂｒｉｄｇｉｎｇ」（以下の本明細書中において、「ＳＡＴＡ特許文献」と呼ばれる）の一部継続出願であり、上記出願の開示は、全部が記述されるかのように、本明細書中に援用される。
【０００２】
（発明の分野）
本発明は、概してシリアルアドバンストテクノロジーアタッチメントＡＴＡ（ＳＡＴＡ）（Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ  ＡＴＡ（ＳＡＴＡ））および／またはシリアルアタッチトスモールコンピュータシステムインターフェイス（ＳＣＳＩ）（ＳＡＳ）（Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）（ＳＡＳ））環境内のイニシエータおよびターゲットを用いるシステムに関し、特に、それらの間を直接的に接続することなく、２つ以上のイニシエータに、情報を互いに通信および／または共有させるターゲットに関する。
【背景技術】
【０００３】
（発明の背景）
（ＳＡＴＡプロトコルの概要）
本明細書中に用いられるような「デバイス」は、産業界によって採用された任意の公知の規格に付着する周辺装置を表している。ＳＡＴＡは、大容量ストレージデバイスのパラレルアドバンストテクノロジーアタッチメント（ＡＴＡ）（ｐａｒａｌｌｅｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ（ＡＴＡ））アタッチメントの置き換えとなる高速シリアルリンクである。利用されるシリアルリンクは、当業者には公知のギガビット技術と、８ｂ／１０ｂ符号化とを利用するポイントツーポイント高速差動リンクである。ＳＡＴＡプロトコルは、開放型システム間相互接続（ＯＳＩ）参照モデル（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ（ＯＳＩ）Ｒｅｆｅｒｅｎｃｅ  Ｍｏｄｅｌ）に類似する階層化通信モデルに基づく。概要は、以下に提示される。詳細については、参考として本明細書中に援用されるＳＡＴＡ規格文書を参照されたい。ＳＡＴＡ仕様は、２００５年１０月２７日付刊行物、「Ｓｅｒｉａｌ  ＡＴＡ：Ｈｉｇｈ  Ｓｐｅｅｄ  Ｓｅｒｉａｌｉｚｅｄ  ＡＴＡ  Ａｔｔａｃｈｍｅｎｔ」または「Ｓｅｒｉａｌ  ＡＴＡ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｚａｔｉｏｎ：Ｓｅｒｉａｌ  ＡＴＡ  Ｒｅｖｉｓｉｏｎｓ  ２．５」において提供され、両方とも、シリアルＡＴＡワークグループのウェブサイトｗｗｗ．ｓｅｒｉａｌａｔａ．ｏｒｇにおいて現在利用可能である。
【０００４】
ＳＡＴＡプロトコルにおいては、プロトコルの各層は、その相手側と直接的または間接的に通信する。シリアルＡＴＡリンクは、公知の規格に従うプロトコルによって規定されており、４つの通信層、すなわち、物理レベルで通信を実行するための物理層、リンク層、トランスポート層、およびしばしばコマンド層と呼ばれるアプリケーション層を有する。送信器および受信器は、直接相互に後の層と通信することができず、これらの層は、他の対応する層に到達する前に、システムの他の層を通り抜けなければならない。例えば、送信器の物理層が受信器のトランスポート層と通信するためには、最初に送信器のリンク層、トランスポート層およびアプリケーション層を通り、次いでシリアルＡＴＡリンクを介して、受信器のアプリケーション層に進み、最後に、受信器のトランスポート層に進まなければならない。
【０００５】
通信または交換の基本単位はフレームである。フレームは、フレーム開始部（ｓｔａｒｔ  ｏｆ  ｆｒａｍｅ；ＳＯＦ）プリミティブと、フレーム情報構造（ｆｒａｍｅ  ｉｎｆｏｒｍａｔｉｏｎ  ｓｔｒｕｃｔｕｒｅ；ＦＩＳ）と、ＦＩＳのコンテンツにわたって計算される巡回冗長チェックサム（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋｓｕｍ；ＣＲＣ）と、フレーム終了部（ｅｎｄ  ｏｆ  ｆｒａｍｅ；ＥＯＦ）プリミティブとを備える。シリアルＡＴＡ機関は、フレームの定義が提供される仕様を規定しており、その仕様は、本文書全体にわたって用いられることを意図する。プリミティブは、ダブルワード（Ｄｗｏｒｄ）のエンティティであり、そこでは、シリアルラインを制御し、そのステータスを提供するために用いられる１バイトのＫ文字を含む。シリアルＡＴＡ機関は、許可されるプリミティブの定義が提供される仕様を規定しており、その仕様は、ＳＡＳで規定されたプリミティブに加えて、本文書全体にわたって用いられることを意図する。
【０００６】
図１は、フレーム３０の例を示す。図１において、フレームは、ＳＯＦプリミティブ３０ａによって開始し、後に第一のＦＩＳコンテンツ３０ｂが続き、後に送信器が利用可能なデータを有しないことを示すＨＯＬＤプリミティブ３０ｃが続き、後に第二のＦＩＳコンテンツ３０ｄが続き、後にＨＯＬＤプリミティブの受信を肯定応答するために送信され、受信器バッファが「準備できていない（ｎｏｔ  ｒｅａｄｙ）」状態にあることを示す、受信器によって送信されるＨＯＬＤＡプリミティブ３０ｅが続き、後にＣＲＣ３０ｆおよびＥＯＦプリミティブ３０ｇが続く。
【０００７】
図１において、フレーム３０は、フロー制御のために用いられる２つのプリミティブであるＨＯＬＤおよびＨＯＬＤＡプリミティブを含む。ＨＯＬＤプリミティブは、ＦＩＳコンテンツを送信または受信する能力がないことを示す。ＨＯＬＤＡプリミティブは、ＨＯＬＤプリミティブの受信を肯定応答するために送信される。例えば、受信ノードが、そのバッファがほぼフルであることを検出するときに、ＨＯＬＤプリミティブを送信ノードに送信し、送信器ノードを停止するように要求し、そしてバッファがさらにデータを受信するように準備できている状態になるときには、受信ノードは、ＨＯＬＤプリミティブの送信を停止する。送信ノードは、ＨＯＬＤプリミティブの受信を肯定応答するためにＨＯＬＤＡプリミティブを送信する。ＨＯＬＤＡプリミティブが受信されるまで、受信ノードは、データの受信を継続する。バッファのオーバーランを防止するために、ＳＡＴＡプロトコルは、ＨＯＬＤプリミティブを送信するノードとＨＯＬＤＡプリミティブを受信するノードとの間に２０個のＤｗｏｒｄの最大遅延を必要とする。
【０００８】
多くの様々なフレームタイプが存在する。例えば、ダイレクトメモリアクセス（ＤＭＡ）を介してデータを送信するために、ＤＭＡセットアップＦＩＳとして公知のフレームが利用され、後にＤＭＡデータＦＩＳが続く。概して、３つのタイプのＦＩＳ構造があり、１つはコマンド用、１つは転送のセットアップ用、およびもう１つは転送に関連するデータ用である。各フレーム構造は、異なる目的のために用いられる。コマンドタイプのフレームは、コマンドを実行するために送信され、セットアップフレームは、コマンドのデータ転送フェーズを準備するために用いられ、データフレームは、データを転送するために用いられる。
【０００９】
複数のホストユニットとデバイスとの間を連結し、それらの間の通信を調停するスイッチに対する必要性が存在する。該スイッチは、時間の遅延と関連づけられており、そこでは、スイッチの遅延にもかかわらず、ＳＡＴＡプロトコルのタイミング要件が満足される。
【００１０】
ＳＡＳをリンクとして用いることによって、３つの異なるタイプの通信プロトコルが、接続をオープンするために利用され得る。それらは、シリアルＡＴＡトンネル型プロトコル（Ｓｅｒｉａｌ  ＡＴＡ  Ｔｕｎｎｅｌｅｄ  Ｐｒｏｔｏｃｏｌ；ＳＴＰ）、ＳＳＰ、およびＳＭＰである。ＳＴＰは、ＳＡＴＡ規格に規定されるＳＡＴＡ通信方法を可能にするために用いられ、ＳＳＰおよびＳＭＰは、ＳＡＳ規格に規定されるＳＡＳ通信方法において用いられる。ＳＳＰは、スモールコンピュータシステムインターフェイス（ＳＣＳＩ）タイプの通信に用いられる通信方法を規定するために用いられる。
【００１１】
一旦ＳＴＰ接続が確立される（「オープン」されるとも呼ばれる）と、概して、ＳＡＴＡプロトコルに従う。一旦ＳＭＰ接続が確立される、すなわち「オープン」されると、ＳＭＰプロトコルに従う。より具体的には、接続がオープンされ、接続が確立され、要求フレームがイニシエータによって送信され、応答フレームがターゲットによって送信され、そして接続がクローズされる。ＳＡＳに関する上記の通信技術およびさらなる情報は、ＳＡＳ規格に見出され、そのコピーは、ウェブサイトｗｗｗ．ｔ１０．ｏｒｇを参照することによって捜し出される。イニシエータからのＳＭＰ要求は、ベンダ固有の領域として領域が予備とされる機能コードを含み、例えば、コマンドを受信することが可能なユニットまたはデバイスなどのターゲットによって実行される機能をさらに規定するために用いられる。
【００１２】
「イニシエータ」は、本明細書中に用いられるように、コマンドを送信し、送信されたコマンドへの応答を受信することが可能なユニットまたはデバイスを表す。
【００１３】
現在、イニシエータおよびＳＡＴＡおよび／またはＳＴＰターゲットに関係するエラーが発生するときに、リンクをドロップすることなく、またはリンクを介する通信を不許可にすることなく、ＳＡＳまたはＳＡＴＡの通信リンクを維持する公知の効率的な方法は存在しない。ＳＡＴＡドライブなどのデバイスをリセットする一方で、リンクを維持するさらに柔軟かつ有益な方法は存在しない。すなわち、ドライブがリセットされるときに、例えば、エラーの原因についての情報は、イニシエータ間の競合条件に起因して失われ得る。さらに、ドライブに関連しないエラーは、イニシエータに未知であり続ける。なぜならば、イニシエータが、同じことについて情報を検索する方法を有しないからである。従って、エラーが発生するときに、エラーを引き起こしたかまたはときにエラーに関連し得るイニシエータ以外のイニシエータのコマンドが一掃されるか、または失われる。
【００１４】
従って、上記のシステムが現在直面している問題の１つは、イニシエータが、システムのステータスについてのよりよい理解を得るために用いる、エラーのタイプに関する情報の不足である。換言すると、現在イニシエータがエラーについての情報を知らないままであるので、実現されたシステム改善は存在し得ない。例として、エラーがドライブによって引き起こされたか、またはそうではないかを、イニシエータが知ることは価値がある。ドライブによって引き起こされていないエラーの例は、上記に加えて、ドライブ以外のシステム内の位置にある内部コンポーネントによる問題である。より具体的には、デバイスのバッファ内のパリティエラーの場合には、そのようなタイプのエラーを検索する公知の方法は現在存在しない。
【００１５】
あるイニシエータが「ソフト」リセットをＳＡＴＡドライブに送信するときには、別のイニシエータに対して意図されている未決定のコマンドをリセット（または、クリア）し、従って、後者のイニシエータは、その未決定のコマンドおよびＳＡＴＡドライブ上の未決定のコマンドのクリアまたは損失に気づかず、ドライブ上でクリアされているその未決定のコマンドを知らないままである。このことは、カオスを作り出す。さらに、後者のイニシエータは、いつリセットが除去されたかを知らないままである。このことは、後者のイニシエータに、そのコマンドをいつドライブに送信するか、またはその未決定のコマンドのステータスを知らないままにさせる。
【００１６】
別の例は、エラーの位置を知る能力がないことである。例えば、エラーは、イニシエータとエクスパンダとの間および／またはドライブとデバイスとの間のリンクにおいて起こり得る。
【００１７】
ＳＡＴＡドライブは、実のところ複数のイニシエータの存在を知らないままであり、ドライブが知るすべてのことは、イニシエータからコマンドを受信し、イニシエータに応答を送信することである。さらに、イニシエータは、他のイニシエータの存在を知らないままである。
【００１８】
従って、イニシエータの間でエラーを伝達する実用的な方法、およびイニシエータがデバイスまたはＳＡＴＡドライブを介して互いに通信する実用的な公知の方法は現在存在しない。さらに、イニシエータは、互いに衝突することなく、ＳＡＴＡドライブからエラー情報をフェッチすることができない。従来技術のシステムにおいては、衝突を回避するために、多くの作業がイニシエータによって実行され、それによって、システムの帯域幅および性能を低減している。
【００１９】
エラーが発生するときに、イニシエータは、他のイニシエータに関して発生したエラーのタイプについて知らないままにされる。このために、イニシエータは、エラーがそれらのものではないときには、エラーがあったことに気づきさえしない。ドライブが首尾よくリセットされ、イニシエータが再度ドライブにアクセスすることが可能になるまで、イニシエータは、それらのリンクを通信するために用いることを単に奪われる。
【００２０】
現在、エラーが発生するときに、エラーに気づいているイニシエータは、さらにいかなるコマンドをもドライブに送信されることを回避するために、ドライブへのリンクのすべてに、ドロップさせるか、または接続解除させる情報を送信する。なぜならば、送信された場合には、コマンドがおそらくは失われるからである。リンクのドロップは、すべてのイニシエータに、トポロジの変化を気づかせる。その後、すべてのイニシエータは、新しいトポロジに関して情報を収集するために、システムにクエリしなければならない。このことは、明らかにカオスおよび性能に有害な影響をもたらす。なぜならば、イニシエータタスクの実質である入力／出力機能を実行するのではなく、イニシエータがシステムのトポロジを発見するためにクエリを実行するからである。従って、性能は低下し、カオスが作り出される。換言すると、クエリすることは、入力／出力機能に費やされ得る帯域幅を消費し、従って、低減されたシステムの性能をもたらす。
【００２１】
現在のシステムに関するさらに別の問題は、エラー以外の様々な情報、すなわちステータス情報について、イニシエータ間の通信が不足していることである。例えば、１つのイニシエータは、それが近い将来システムからドロップすることを、他のイニシエータが知るように望み得る。他の非エラー関連の情報は、イニシエータが動作可能であったことなどの時間の長さを含み得る。エラーまたはドライブと関連づけられなかった非エラー関連の情報をイニシエータが検索する方法はさらに存在しない。
【００２２】
上記を考慮すると、イニシエータと、イニシエータの間およびイニシエータとＳＡＴＡドライブなどのターゲットとの間で通信を引き起こすリンクとを用いる通信システム（またはブリッジ）に対する必要性が生じており、そのような通信はエラーについての情報を含むが、それに限定されない。
【発明の概要】
【課題を解決するための手段】
【００２３】
（発明の概要）
簡潔には、本発明の実施形態は、少なくとも１つのイニシエータと、ＳＡＴＡデバイスと、該少なくとも１つのイニシエータと該ＳＡＴＡデバイスとの間の通信を容易にするように構成される改善されたブリッジデバイスとを含み、そして少なくとも１つの入力ポートを有し、該入力ポートを介して該イニシエータからの情報を受信するように動作可能であるメモリシステムを含む。通知イベントの間に、通知が該少なくとも１つのイニシエータに送信される通知イベントを処理し、そしてイベントに基づいて動作を実行する該ブリッジデバイスによって、通信の容易さを促進する。
【図面の簡単な説明】
【００２４】
【図１】図１は、従来技術のＳＡＴＡプロトコル通信層を示す。
【図２】図２は、本発明の実施形態に従った、エクスパンダの群がマルチポートブリッジデバイス１６と通信する状態で、エクスパンダ１４、Ｅ０およびＥ１の群に連結されたイニシエータ１２、Ｉ０およびＩ１の群を含むメモリシステム１０を示す。
【図３】図３は、本発明の実施形態に従った、通知フラグテーブル５２を示す。
【図４】図４は、デバイス１６に維持される情報のメールボックステーブルであるメールボックスｏを格納するための、例示的なメールボックステーブル１３０を示す。
【図５】図５は、本発明の別の実施形態に従った、メモリシステム１４０を示す。
【図６】図６は、本発明の別の実施形態に従った、アフィリエーション（ａｆｆｉｌｉａｔｉｏｎ）テーブル１５０と、デバイス１６内に格納されるメールボックステーブル１３０とを示す。
【図７】図７は、デバイス１６が（１つ以上の）通知イベントと呼ばれるイベントを１つ以上のイニシエータに通知することを望むときに、デバイス１６によって実行されるステップのフローチャート３００と、デバイス１６によって実行される代替のステップとを示す。
【図８】図８は、図７のステップ３０４における通知フラグの設定と、図７のステップ３１０における通知フラグのクリアとの間の時間の間に、デバイス１６と、イベントを通知される１つ以上のイニシエータとによって実行されるステップのフローチャート４００を示す。
【図９】図９は、図７のステップ３１０においてイニシエータフラグをクリアするために実行されるステップの例のフローチャート４２０を示し、それは、上記されたように、デバイス１６かまたはイニシエータによって実行され得る。
【図１０】図１０は、イニシエータによって実行されるときに、図７のステップ３１０においてイニシエータフラグをクリアするために実行されるステップのフローチャート４３０を示す。
【図１１】図１１は、イニシエータによってログデータを読み取る（Ｒｅａｄ  Ｌｏｇ  Ｄａｔａ）ときに実行されるステップのフローチャート４５０を示す。
【図１２】図１２は、イニシエータＩ０とイニシエータＩ２との間の情報を互いに利用可能にする第一のメールボックスに関連して実行されるステップのフローチャート４８０を示す。
【図１３】図１３は、イニシエータＩ０とイニシエータＩｘｘとの間の情報を互いに利用可能にする第二のメールボックスに関連して実行されるステップのフローチャート５００を示す。
【図１４】図１４は、ＢＩＳＴなどのイベントを処理するために実行されるステップのフローチャート５１０を示すが、ＢＩＳＴに限定されない。
【図１５】図１５は、コマンドを再発行（または再送信）するために実行されるステップのフローチャート５３０を示す。
【図１６】図１６は、セットデバイスビットＦＩＳ（Ｓｅｔ  Ｄｅｖｉｃｅ  Ｂｉｔ  ＦＩＳ）のフォーマットを示す。
【発明を実施するための形態】
【００２５】
（好適な実施形態の詳細な説明）
ＲＡＩＤディスクアレイ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｄｉｓｋｓ；ＲＡＩＤ）などの大規模なメモリシステムにおいて、改善されたブリッジデバイスが、１つ以上のホスト（すなわちイニシエータ）とターゲットとの間で通信するために用いられる。ホストとイニシエータとは、本明細書中において同じデバイスを表すために用いられる。ターゲットは、イニシエータによって提供され、イニシエータによってアクセスされる情報を格納するためのディスクドライブであり得る。あるいは、ターゲットはＳＡＴＡデバイスである。産業界はこのタイプの通信において利用されるインターフェイス（リンク）を規格化し、そのようなものとして、インターフェイスは産業界において周知のＳＡＴＡおよびシリアルアタッチトＳＣＳＩ（ＳＡＳ）規格に準拠する。
【００２６】
改善されたブリッジデバイスは、複数のポートを介してイニシエータと、そしてＳＡＴＡポートまたはＳＡＴＡ規格を用いてＳＡＴＡデバイスとインターフェイスするポートを介してＳＡＴＡデバイスと通信する。ブリッジデバイスは、多くのイニシエータと通信することが可能であり、一方でイニシエータは、ブリッジデバイスを介してＳＡＴＡデバイスにアクセスする。
【００２７】
ブリッジデバイスは、ＳＡＴＡデバイスとイニシエータとの間のブリッジとして作動する。さらにシステムのスケールを変えるために、エクスパンダが、イニシエータとブリッジデバイスとの間で利用され、それによって、複数のイニシエータが、１つのエクスパンダを介して通信することを可能にする。上記などのメモリシステムが図２に示される。
【００２８】
ここで図２を参照すると、メモリシステム１０は、本発明の実施形態に従った、エクスパンダの群がマルチポートブリッジデバイス１６と通信する状態で、エクスパンダ１４、Ｅ０およびＥ１の群に連結されたイニシエータ１２、Ｉ０およびＩ１の群を含むように示される。２つのイニシエータと２つのエクスパンダとが示されるけれども、任意の数のイニシエータとエクスパンダとが利用され得ることが理解される。エクスパンダ１４は選択的であり、この点において、本発明の他の実施形態において、エクスパンダ１４は存在しないかもしれない。デバイス１６はターゲットである。エクスパンダＥ０およびＥ１はスイッチとして機能し、一般に、そこに接続された多くのターゲット、および／またはエクスパンダの階層を有する。
【００２９】
代替の実施形態において、図２のエクスパンダ１４の中のエクスパンダは、イニシエータを含む。
【００３０】
デバイス１６は、ＳＡＴＡディスクドライブ１８に連結されて示される。ディスクドライブ１８は、ＳＡＴＡドライブまたはＳＡＴＡデバイスであり、従って、ＳＡＴＡ規格を用いてデバイス１６と通信する。デバイス１６は、ＳＡＳインターフェイスを用いるエクスパンダＥ０およびＥ１との通信を引き起こすための２つのＳＡＳポート、ポート２０および２２を含むように示される。本発明の別の実施形態において、デバイス１６は、ポート２０またはポート２２のいずれかなどの単一のＳＡＳポートを含む。
【００３１】
デバイス１６は、ＳＡＴＡ規格プロトコルを用いてドライブ１８と通信するために、ＳＡＴＡポート２４を用いる。単一ポートデバイス１６が利用され得るけれども、デバイス１６は、本発明の一実施形態においてマルチポート化される。単一ポートのブリッジデバイス１６の例が、ＳＡＴＡ特許文献の図３〜図５において示される。デュアルポート化またはマルチポート化されたデバイス１６は、ＳＡＴＡデバイス１８がマルチポート化されることを可能にする。デュアルポート化またはデュアルポートを有することは、２つ以上の通信経路を有することを表し、それは、２つの経路を有することに起因して性能を増大させることに役立つ。なぜならば、両方の経路が同時にアクティブだからである。
【００３２】
図２に示されないけれども、実際の用途において、システム１０は、ドライブ１８などの多くのドライブを含み得、それらのドライブは、エクスパンダに連結され得る。例えば、エクスパンダ２６は数多くのドライブに連結され得、エクスパンダ２６以外の他のエクスパンダ（図示されない）が、さらに他のドライブをシステムに連結するために利用され得る。上記のシステムにおいて、一般に数多くのイニシエータがなお存在し得る。図２のシステム１０の一部の用途例は、文書のストレージおよび検索、写真のストレージおよび検索、財務会計ソフトのストレージを含むが、それらに限定されない。利用される大きなストレージ容量に起因して、イニシエータなどのデバイスへの複数の経路を有することが、デバイスのステータスおよびエラーについての様々な情報がそうであるように、非常に望ましい。このことは、利益のうちでも特に、さらなる柔軟性、よりよいシステムの性能およびより低いコストを明らかに可能とする。
【００３３】
あるいは、２つ以上のデバイス１６がドライブ１８に連結され、そのデバイスは、さらにシステムの性能を改善する。
【００３４】
システム１０の様々なトポロジが予期され、その一部が、２００６年１２月２２日に出願された、「Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ  （ＳＡＴＡ）  Ａｎｄ  Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ  （ＳＣＳＩ）  （ＳＡＳ）  Ｂｒｉｄｇｉｎｇ」という名称の米国特許出願第１１／６４４，５４９号において示され、そして論じられている。上記出願の内容は、全部が記述されるかのように、参考として本明細書中に援用される。上記の参照特許文献において、図２〜図７は、システム１０の異なるトポロジを示すけれども、その中に含まれなかった追加のトポロジが予期される。参照特許文献の図８および図９が、システム１０の一部の詳細を開示しており、それは、主題の特許文献の図２のデバイス１６が、参照特許文献の図８および図９に開示された構造を含むという点において、本明細書中に記載される実施形態および方法にあてはまる。
【００３５】
２つ以上の利用されるイニシエータが存在する場合、上記に示されたように、例えば、すべてのイニシエータがドライブにアクセスすることを欲し、そして特に、例えばドライブによって引き起こされ得るエラーが存在するときには、複数の問題が起こる。これらの問題は、本発明の様々な実施形態によって解決される。エラーの場合において、エラーがイニシエータに報告され、メモリシステムの接続性についての他の情報が、イニシエータに対してさらに選択的に利用可能である。
【００３６】
エラーは様々な方法で引き起こされ得る。１つの一般的なエラーは、ドライブ１８が原因であり、ドライブ１８がハングするか、または主としてその動く機械的部品に起因して特定の領域において単に欠陥となり得るときである。別のタイプのエラーは、イニシエータまたはエクスパンダなどのデバイスの送信器または受信器（トランシーバ）が原因である。例示的なエラーは、図２のイニシエータＩ０とエクスパンダＥ０との間のリンクにおいて、より具体的には４２において発生し得、そのエラーは、イニシエータＩ０のトランシーバ内の問題によって引き起こされる可能性がある。従来技術のシステムでは、そのようなエラーが発生するときまたは発生した後に、イニシエータＩ１がエラーおよびその原因を知らないままであり、エラーがドライブ１８内の場合には、イニシエータＩ０とＩ１との両方が、エラーおよびその原因を知らないままである。
【００３７】
ドライブ１８はリセット可能であり、リセットするための方法は、後の図について提示され、そして論じられる。しかしながら、今のところ、本発明の方法および装置に従った、複数のイニシエータが、リンク４４または４６などのエクスパンダへのリンクをドロップすることなく、１つ以上のＳＡＳポートを介してドライブ１８をリセットし得ることに言及することは注目に値する。さらに、１つのポート上のリセットの伝達は、例えばリンク４４および４６において任意のリンクをドロップすることなく、別のポートに伝播することを可能にし得る。
【００３８】
別の例示的なエラーは、リンク４４および４６でリンクをドロップさせ得、そして従来技術のシステムにおいて、イニシエータＩ１は、エラーがエクスパンダＥ０とエクスパンダＥ１との間にあったか、あるいはデバイス１６内またはドライブ１８内にあったかを決定するための情報を有しない。本発明の様々な実施形態において、そのような情報は、デバイス１６によってイニシエータＩ１に対して利用可能にされる。エラーがドライブ１８によって引き起こされる場合においては、不良ステータス情報は、エクスパンダＥ０に伝えられ、デバイス１６によって、この出来事の後に続いてリンク４４および４６がドロップされる。しかしながら、従来技術のシステムにおいては、この場合のイニシエータＩ１は、不良ステータスが欠陥のあるメディアまたはドライブ１８のどちらに起因していたか、または不良ステータスがリンク４４および４６によって引き起こされたか否かを知らない。本発明の様々な実施形態においては、エラーを引き起こす構造についての情報が、デバイス１６により報告され、それによって、エラーの理由の情報がイニシエータＩ１に報告される。ここまででおそらく明らかなように、本発明の実施形態および方法が、複数のイニシエータ１２のイニシエータの間で様々なタイプの情報の通信を容易にするさらに多くの場合が存在する。
【００３９】
エラーと、そのエラーが引き起こされる回数と、エラーがドライブに関連しているか否かとを追跡することは、イニシエータへの重要な情報である。なぜならば、その情報が、システムの性能および信頼性を改善するために用いられ得るからである。
【００４０】
本発明の一実施形態において、デバイス１６は、ブリッジ４０に連結されたＳＡＳ  ｍｕｘ２８を含む。デバイス１６が、ホストまたはイニシエータに連結するための複数のポートを有するように示されたが、一方で、ＳＡＴＡ特許文献の図３〜図５に示されたような単一ポートのデバイス１６が予期されることは注目されるべきである。ＳＡＴＡ特許文献の開示は、全部が記述されるかのように、参考として本明細書中に援用される。
【００４１】
本発明の一実施形態において、デバイス１６は、ＳＡＳポート以外の入力ポートを含み、従って、ＳＡＳポートに関係する図を取り巻く議論が本明細書中で行われるけれども、実施形態はそれらに限定されない。例として、１つ以上のＳＡＴＡポートが、入力ポートとしてデバイス１６に役立ち得る。ＳＡＳポートは、ＳＡＳ規格を用いてインターフェイスするポートであり、ＳＡＴＡポートは、ＳＡＴＡ規格を用いてインターフェイスするポートである。
【００４２】
ｍｕｘ２８は、２つ以上のイニシエータからエクスパンダを介して２つ以上の入力を受信するように動作する。図２の実施形態において、ｍｕｘ２８は、そのポート２０でエクスパンダＥ１から、そしてそのポート２２でエクスパンダＥ０からの入力を受信ように示される。これらの入力はＳＡＳ入力であり、ドライブ１８がアクセスされるためには、ＳＡＴＡに変換されなければならない。従って、ｍｕｘ２８の出力は、ＳＡＳがドライブ１８との通信のためにＳＡＴＡに変換されるブリッジ４０に連結される。
【００４３】
２つのイニシエータおよびエクスパンダが図２に示されるけれども、任意の数のそのようなデバイスが利用され得る。実際には、追加のエクスパンダ２６が、デバイス１６を介して通信することなく、エクスパンダＥ０に、そして他のディスクドライブに選択的に連結され得、それは、さらなるスケーラビリティを提供する。
【００４４】
イニシエータの群１２のイニシエータＩ０およびＩ１は、それらがターゲットではないので、互いに直接的に通信し得ず、そしてターゲットとだけ通信し得る。例えば、図２において、イニシエータＩ０とＩ２との間に直接的な経路が存在しない。例えば、この点において、エクスパンダＥ０は、イニシエータＩ１へのターゲットであり、従って、イニシエータＩ１は、エクスパンダＥ０およびエクスパンダＥ１と通信し得るけれども、イニシエータＩ０と直接的に通信し得ない。同様に、イニシエータＩ０は、Ｅ０およびＥ１のターゲットと通信し得るけれども、イニシエータＩ１とは通信し得ない。特にこの理由に対して、本発明の様々な実施形態は、たとえいずれもがターゲットでないとしても、イニシエータの間の通信を容易にするために必要である。
【００４５】
イニシエータによって起動された通信の間、シリアルＡＴＡトンネル型プロトコル（ＳＴＰ）−ＳＡＳ規格の接続が、ＳＴＰ規格に従って「オープン」され、そしてその後、ＳＡＴＡ規格が、ドライブ１８と通信するために用いられる。
【００４６】
まもなく明らかになるように、本発明の様々な実施形態は、イニシエータが所定のプロトコルを用いて互いに通信することを可能にする。
【００４７】
デバイス１６のアーキテクチャは、通信の制御情報のための経路が、通信の入力／出力情報のための経路から独立であることを可能にする。このことは、デバイス１６がシステム１０に、より大きなシステムの性能および効率をもたらすという点において重要である。このことが達成される方法は、少なくとも、部分的に、デバイス１６が、ポート２４を介してドライブ１８との通信に使用するためのＳＡＴＡバス４８と、それぞれポート２２および２０を介してエクスパンダＥ０およびＥ１との通信に使用するための別個のＳＡＳバス５０とを含むことに起因する。デバイス１６のアーキテクチャのより大きな理解のために、読者は、２００６年１２月２２日に出願された米国特許出願第１１／６４４，５４９号、発明の名称「Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ（ＳＡＴＡ）  Ａｎｄ  Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ  （ＳＣＳＩ）  （ＳＡＳ）  Ｂｒｉｄｇｉｎｇ」に向けられ、上記出願の開示は、全部が記述されるかのように、参考として本明細書中に援用される。
【００４８】
簡潔な背景としては、ポート２０および２２を介する通信はＳＡＳ規格を用いて行われる。この点において、ＳＭＰが、ドライブ１８と通信するために、エクスパンダなどのターゲットを指向し、イニシエータによって起動された接続をオープンするために実行される。その後、イニシエータは関数をエクスパンダに送信し、そしてさらに応答を受信し、その後、イニシエータは接続をクローズする。ポート２４を介する通信はＳＴＰを伴い、そこでは、接続がオープンされ、ＳＡＴＡを用いる通信が、ドライブ１８とデバイス１６との間を往復して実行される。上記の方法において、ＳＭＰが、ＳＡＴＡ／ＳＴＰと実質的に独立に実行される。
【００４９】
図３において、デバイス１６は、３つの列と、存在するイニシエータおよびポート（例えば、ポート２０および２２）と同じ数の行とを含む通知フラグテーブル５２を含むように示され、該通知フラグテーブル５２は、例えば、ＳＡＴＡ特許文献のデバイス１６のメモリ１０２内に維持され得る。テーブル５２は、ハードウェアまたはソフトウェアにおいて実装され得る。このテーブル５２は、以下の例を通しておそらく最もよく理解される方法において、例えば、最近発生したエラーを分離するために用いられる。
【００５０】
テーブル５２内の情報については、列「イニシエータ」の下に現われる行、すなわち行５４〜行６０のそれぞれは、特定のポートと特定のイニシエータとの状態を表す。例えば、行５４において、イニシエータのイニシエータ０（Ｉ０）とポート０とのステータスが、実質的に「通知フラグ」の状態である「通知」というラベルを貼られた列の下の対応する行内の情報によって示される。行５６において、イニシエータＩ０とポート１とのステータスが、列「通知」の下の対応する行内の情報によって示される。
【００５１】
行５８において、イニシエータ１（またはＩ１）とポート０とのステータスが、列「通知」の下の対応する行内の情報によって示され、そして行６０において、イニシエータＩ１とポート１とのステータスが、列「通知」の下の対応する行内の情報によって示される。追加のイニシエータ／ポートが利用される場合には、テーブルは、それに応じた情報を含む。デバイス１６によって設定またはリセットされる「通知」フラグは、例えば、イニシエータなどのデバイスと関連づけられるエラー（または、非エラー）の問題／イベントを示すために用いられる。従って、「通知」状態にあることは、対応するイニシエータがデバイス１６にアクセスすることを妨げる。
【００５２】
例えば、（図２の）イニシエータＩ０が、エラーについてさらに情報をクエリするか、あるいはドライブ１８内、またはデバイス１６とそれに連結されたイニシエータとの間にあるエラーの原因を分離することを望む場合においては、イニシエータＩ０は、接続をオープンし、次いで、デバイス１６が「通知」イベント内にあるか、または通知フラグが設定されているか否かについてデバイス１６にクエリするために、ＳＭＰを実行する。このことは、まもなくさらに詳しく説明される。デバイス１６によるイニシエータＩ０への応答が否定的であり、デバイス１６が「通知イベント」内にない場合には、イニシエータＩ０は、エラーがドライブ１８によって引き起こされていることを知る。これに対して、デバイス１６による応答が肯定的であり、デバイス１６が通知イベント内にある場合には、エラーについてのさらなる情報が、イニシエータＩ０に伝えられる。デバイス１６は次いで、イニシエータが通知のソースを知ることを可能にする情報によってクエリに応答する。従って、イニシエータＩ０は通知の理由について知識を有する。通知がエラーである場合には、上記のことはエラーのソースとなる。
【００５３】
ストレージデバイス５２内の情報が、エラーを分離するために用いられる方法は、おそらくその後の図における例に関してよりよく理解される。今のところ、本発明の様々な実施形態が、イニシエータの間の直接的な経路なしでイニシエータの間の通信を可能にすることを述べれば十分である。このことは、システムのトポロジへのより大きな洞察をイニシエータに提供し、従って、イニシエータが、入力／出力機能により大きな時間を充てることを可能にすることによって、システムの性能を増大させる。そのような通信の例として、エラーは、エラーの理由がそうであるように、デバイス１６を介してイニシエータの間で報告される。
【００５４】
本発明のさらに別の実施形態は、イニシエータＩ０およびＩ１が、エラー以外の互いの通信情報用のメールボックスを有することを可能にする。メールボックスは、１つ以上のイニシエータが、ＳＴＰなどのＳＡＴＡコマンドに影響することなく情報を互いに通信することを可能にする。
【００５５】
Ｉ０およびＩ１は、それぞれイニシエータ０およびイニシエータ１を表す。図４において、例示的なメールボックスストレージデバイス１３０は、デバイス１６内に維持されるメールボックス情報のテーブルであることが示される。本発明の一実施形態において、メールボックスストレージテーブル１３０は、ＳＡＴＡ特許文献において開示されたメモリ１０２内に配置される。
【００５６】
テーブル１３０は、イニシエータのそれぞれが互いに情報を渡すための方法およびメカニズムとして役立つ。例えば、図４の例示的な実施形態において、テーブル１３０は、３つの列と、その数がイニシエータの数に依存する多くの行とを含む。列１３２において、イニシエータが識別され、この例では、Ｉ０〜Ｉ３の４つが存在し、列１３４において、ポートが識別され、この例では、ポート０およびポート１、またはＰ０およびＰ１であり、そして列１３６において、関連するイニシエータが次に伝えたい情報が含まれる。ストレージデバイス１３０は、ハードウェア内、例えばレジスタファイル内、またはソフトウェアにおいて実装され得る。
【００５７】
例として、イニシエータＩ０は、ＳＡＳポート０（またはＰ０）で、第一行の列１３６における情報を含み、そしてこのようにして、イニシエータＩ１は、ストレージデバイス１３０の内容を読み取ると、Ｉ０が伝えた情報について知らされる。実のところ、Ｉ１は、メールボックスを読み取ることによって、すべてのポートにおいてすべてのイニシエータによって伝えられた情報のすべてに気づかされる。典型的な例において、列１３６内の情報は複数のバイト内にある。イニシエータによって伝えられる情報の例は、ドライブ１８内の所定の位置に格納され得る特定の情報などのドライブ１８についての情報と同様であり、他のイニシエータに重要であるかまたは重要であり得る。例えば、Ｉ０は、セクタ５およびセクタ６内に読み取られる必要のある情報が格納されていることを示し得、次いで同じことを知らされることによって、Ｉ１が同じものに対してセクタ７およびセクタ８を選び得る。キーは、ドライブ１８内の異なるセクタがＩ０およびＩ１によって用いられることであり、それによって、Ｉ０とＩ１との間のいかなる衝突をも回避する。別の例は、特定のイニシエータがオフラインになる前に残存する時間の長さであり、このイニシエータがシステム機能を管理している場合には、別のイニシエータはここで、入って来て、そして後者のイニシエータがオフラインになった後、オフラインになるイニシエータによって処理される機能を引き継ぐことを知り得る。
【００５８】
図６に関してさらに明らかになるように、アフィリエーションカウンタ１５２は、デバイス１６の現在のトポロジへの変化を追跡するために用いられ、同じカウンタは次いで、メールボックスにおける、現在のトポロジのイニシエータの読み取りを追跡するために用いられる。
【００５９】
従って、イニシエータは、テーブル１３０内のそれらの指定された領域に情報を格納する能力と、新しく格納された情報に気づき、かつ／または以前に提出された問題点への応答またはイニシエータによる要求を受信するために、テーブル１３０を読み取る能力とを有する。この方法において、イベントに関する情報を識別する「理由コード（ｒｅａｓｏｎ  ｃｏｄｅ）」は、イニシエータが、問題の性質に気づくために、メールボックスを読み取るように指示する問題を示すために用いられ得る。
【００６０】
本発明の別の実施形態および方法において、イニシエータの障害は、適切に動作させるためか、または障害以外の理由のために、置換（Ｒ）イニシエータをもたらし、障害のある（または、まもなく置き換えられる）イニシエータを、システム１０によって経験されるいかなる休止時間（例えば、リブートまたは電源切断）もなく、そして障害のあるイニシエータ（例えば、イニシエータＩ１）を物理的に除去する必要性なしに置き換え、障害のあるイニシエータによって処理されていた機能と同じ機能を、置換イニシエータ、イニシエータ１Ｒによって直ちに実行される状態にする。このことは、例として図５において例示される。
【００６１】
図５において、メモリシステム１４０は、本発明の別の実施形態に従って示され、エクスパンダＥ０およびＥ１と通信するイニシエータＩ０と、エクスパンダＥ１およびＥ１と通信するイニシエータＩ１とを含む。エクスパンダＥ０およびＥ１は、マルチポートブリッジデバイス１６に連結されて示され、マルチポートブリッジデバイス１６は、ＳＡＴＡディスクドライブ１８に連結されて示される。
【００６２】
上記の実際の用途例は、ウェブサイトが、再構築されることを意図されるときには、その場合において、イニシエータが、障害または他のためか否かにかかわらず動作不能にされ、システムから効果的に除去され、そしてシステムの休止時間なしに別のイニシエータと置き換えられる必要があり得る。
【００６３】
その場合において、例えば、Ｉ１が障害となる場合には、Ｉ１は、恒久的に「通知イベントリセット」状態にあり、それは、貴重なシステムの帯域幅を不必要に消費することになる。本発明のこの実施形態において、Ｉ１は、Ｉ１の機能を有するＩ１Ｒイニシエータと置き換えられる。そうするには、デバイス１６は、そのリソースを再要求する必要がある。
【００６４】
デバイス１６内に、Ｉ１が「通知」状態にある期間を測定するタイマ１４２があり、そしてこの測定された期間が所定のしきい値を超えるときかまたは超える場合には、デバイス１６は、システム１０からＩ１を除去する（または、Ｉ１を動作不能にする）ことを決定する。本発明の一実施形態において、後者はテーブル１５０内に反映される。
【００６５】
Ｉ１がシステム１０から除去されるときには、Ｉ１の通知イベントは、Ｉ１と関連づけられるすべての他の機能または属性が、新たに開始するＩ１Ｒのために、本質的にスレート（ｓｌａｔｅ）をクリアするように、クリアされる（または、通知フラグがリセットされる）。
【００６６】
別のイニシエータを置き換える置換イニシエータが、システム１０内に置かれるときには、置き換えられるイニシエータのタスクが、置換イニシエータによってシームレスに引き継がれる一方で、置き換えられていないイニシエータは、この置き換えまたはシステムトポロジの変化を知らないままである。このように、本発明のさらに別の実施形態において、イニシエータは、システムトポロジの変化（あるイニシエータが別のイニシエータを置き換えることのような）を気づかされる。
【００６７】
図６は、それぞれが本発明の別の実施形態に従った、デバイス１６内に配置されるアフィリエーションテーブル１５０およびメールボックステーブル１３０を示す。テーブル１５０は、システム内のイニシエータのアフィリエーションテーブルを格納する一方で、メールボックステーブル１３０は、上記されたように、メールボックスの情報を格納する。両方のテーブルは、本明細書中の実施形態のデバイス１６によって維持され、そしてデバイス１６内に配置される。
【００６８】
テーブル１５０は、それと関連するアフィリエーションカウンタ１５２を有する。任意の値または状態がストレージデバイス１５０内で変化するたびに、カウンタは、１つずつインクリメントされる。テーブル１５０は、スロットに基づいた情報を含み、スロットは、ポートに基づいて識別される。例えば、テーブル１５０の第一または一番上の行内のテーブル１５０のスロット０では、イニシエータ０、すなわちＩ０は、ポート０において、それは、例えば（図２の）ポート２２であり、列１５６の対応する行において「有効（ｖａｌｉｄ）」である、として示される。「有効」は、対応する行のエントリが有効であることを示す一方、無効（ｉｎｖａｌｉｄ）は、対応する行の情報が無効であることを示す。テーブル１５０への変化があるたびに、カウンタ１５２は１つずつインクリメントされる。カウンタ１５２のカウントがカウンタ１５２のビット数を超えるときに、最後は０に反転する。
【００６９】
テーブル１５０の行のそれぞれの第一の列において、追加の格納されたイニシエータアドレスが存在する。例えば、テーブル１５０の第一行において、イニシエータ０を識別するアドレスは、第一の列１５６に格納される。
【００７０】
テーブル１３０については、イニシエータがテーブル１５０の状態を読み取るたびに、テーブル１３０のカウンタ１５２は、テーブル１５０のカウンタ１５２と比較され、それらのカウンタの両方は、物理的に同じカウンタであり、カウントの状態が同じ場合には、読み取られたトポロジは最新であり、もしそうでない場合には、読み取られたトポロジは最新ではない。すなわち、カウンタ１５２は、トポロジの変化（例えば、導入されたイニシエータまたは新しいイニシエータ）に気づくためにイニシエータによってさらに用いられる。
【００７１】
イニシエータは次いで、テーブル１５０を読み取ることによって正確な変化を知らされる。このことは重要である。なぜならば、例えば、情報を要求されるイニシエータに障害があるかまたは置き換えられている場合には、そのイニシエータにテーブル１３０を介して出す要求または情報を有していたイニシエータは、いかなる情報をも受信しないからである。テーブル１５０を読み取ることによって、要求イニシエータは同じことに気づくようになる。カウンタ１５２内の現在の値とその前の値（すなわち、イニシエータがテーブル１５０を最後に読み取ったときのカウンタの値）との不整合があると、イニシエータは、トポロジの変化について警告を出され、次いで特定の変化に気づくためにテーブル１５０を読み取るべきことを理解する。
【００７２】
図６において、テーブル１５０は、システム内のパラメータを制御するために用いられる。すなわち、例えばＳＭＰを介して、テーブル１５０の各ポートに対する深さが、固定の深さまたは所定の深さに制限され得る。ＳＭＰを介して、テーブル１５０の列内の値が制御され得、その値は、１つ以上のポートに対してアフィリエートした（ａｆｆｉｌｉａｔｅｄ）ＳＡＳアドレスが、ＳＡＳアドレスの新しい組に原子的に（ａｔｏｍｉｃａｌｌｙ）移動させられることを可能にする。すなわちテーブル１５０は、ＳＡＴＡデバイスへのイニシエータによるアクセスを制御または制限するために、デバイス１６によって一方的に変更され得る。この方法において、テーブル１５０の深さ、およびテーブル１５０へのアクセスは、デバイス１６によって制御または変更される。例えば、イニシエータの受信者は、テーブル１５０へのアクセスを効果的に制限するために一方的に変更され得る。このことはさらに、アフィリエートしたイニシエータの数が、特定のＳＡＳポートに対するアフィリエーションの最大の数よりも少ない値に制限されることを可能にする。
【００７３】
あるいは、テーブル１５０以外のテーブルまたはテーブル１５０の拡張されたバージョンが、デバイス１６へのアクセスをエクスパンダによって一方的に制御するために利用され得る。例えば、テーブル１５０、またはエクスパンダを含むように拡張されたテーブル１５０に類似するエクスパンダアフィリエーションテーブルは、エクスパンダによるアフィリエーションを記載するために用いられ、デバイス１６は、エクスパンダによるＳＡＴＡデバイスへのアクセスを制限するために、そのテーブルの深さおよびアドレスを変更することが可能である。
【００７４】
本発明のさらに別の実施形態において、図２のエクスパンダ１４などの（１つ以上の）エクスパンダは、テーブル１５０に類似するアフィリエーションテーブルを含み、該テーブルは、エクスパンダとデバイス１６との間のアフィリエーションを記載し、そしてエクスパンダによるＳＡＴＡデバイスへのアクセスを制限するために、テーブルの深さおよびアドレスを変更するために用いられる。
【００７５】
上記は、ＳＡＳ  ｍｕｘおよびエクスパンダなどのアフィリエーションを維持するいかなるＳＡＳポートにも有利に値を提供する。また、上記を介して、イニシエータの１つの組からイニシエータの別の組にアフィリエーションを原子的に移動させる方法が提供される。また、１つ以上のイニシエータがデバイス１６にアクセスすることを意図的に不許可にすることは可能である。そのような機能の使用の例は、イニシエータが高い動作帯域幅を有する場合に、そのイニシエータは、デバイス１６上で動作する必要があるけれども、他のイニシエータには、いかなる帯域幅も用いてほしくないような場合である。
【００７６】
本発明の別の実施形態において、特別なイニシエータがフェイルオーバー（ｆａｉｌｏｖｅｒ）に対して用いられ、その結果として、動作可能のイニシエータが作業しているときには、フェイルオーバーイニシエータは、デバイス１６へのアクセスを得ることができない。しかしながら、障害が起こるときには、アフィリエーションが、直ちにフェイルオーバーイニシエータに柔軟に移動され得、システムはもう一度動作可能である。
【００７７】
さらに代替としては、アフィリエーションテーブルは、デバイス１６に応答するか、またはデバイス１６と通信することになっていた所定の期間を超えたイニシエータと関連づけられる任意のイニシエータアドレスが自動的にクリアされる。タイムアウトが起こる場合には、タイムアウトを起こしたイニシエータと関連づけられるＳＡＳアドレスが、アフィリエーションテーブルから取り除かれる。
【００７８】
図７は、デバイス１６が、（１つ以上の）通知イベントと呼ばれるイベントを１つ以上のイニシエータに通知すること（通知イベント）を望むときに、デバイス１６によって実行されるステップのフローチャート３００を示す。イベントの例は、ドライブまたはＳＡＴＡデバイス内のエラー、あるいはＳＡＳリンク内の「ＢＲＥＡＫ」プリミティブまたはステータスの提供の発生を含むけれども、これらに限定されない。「ＢＲＥＡＫ」プリミティブは、ＳＡＳ仕様において規定される。通知イベントのさらなる例およびより具体的な例が以下で提供される。
【００７９】
図７のステップ３０２において、デバイス１６は、イベントをＩ０またはＩ１などの１つ以上のイニシエータに通知することを望む。このことは、次のステップ３０４に、相互通知（ｉｎｔｅｒ−ｎｏｔｉｆｉｃａｔｉｏｎ）、すなわち通知フラグ状態の設定を入力させ、実行させる（または、イベントフラグが設定される）。次に、ステップ３０６において、通知が１つ以上のイニシエータに送信される。次に、ステップ３０８において、イベントに基づいて動作が実行される。他の例が予期されるけれども、イベントに基づいた（ステップ３０８の）動作のいくつかの例は、
１．  エラーを有するＳＡＴＡデバイス（または、ドライブ）は、相互通知を引き起こすイベントの例であり、ステップ３０８で実行される動作は、読み取りログデータ（ｒｅａｄ  ｌｏｇ  ｄａｔａ）をフェッチし、格納すること
２．  イニシエータは、そのコマンドのすべてを取り去ることを要求する。それは相互通知イベントであり、動作は、要求イニシエータのコマンドのすべてを取り去ること
３．  相互通知イベントは、回復不能なドライブエラーであり、動作は、ＳＡＴＡデバイスまたはドライブをリセットすること
４．  相互通知イベントは、すべてのイニシエータに対してそれらのメールボックスを読み取るように、理由コードを有する通知を送信するイニシエータ要求であり、動作は、イニシエータに通知を送り返すときに、理由コードを用いること
である。上記は、イベントに基づいた動作の一部の例を提供するけれども、他が予期される。
【００８０】
次に、図７のステップ３１０において、ステップ３０４で設定された通知フラグがクリアされる。通知フラグのクリアは、イニシエータまたはデバイス１６によって実行され得、それは、一般にプリミティブまたはフレームの形態である。次に、ステップ３１２において、通知プロセスが終了する。
【００８１】
他の例が予期されるけれども、通知フラグをクリアする（ステップ３１０の）いくつかの例は、
１．  デバイス１６は、自動的に通知フラグをクリアし、次いでオープン要求を拒絶するプリミティブまたはオープン要求を拒絶する他のタイプのプリミティブであるオープン拒絶（リトライ）の発行を停止し得ること
２．  イニシエータは、ＳＭＰ接続を介して通知フラグをクリアするようにデバイス１６に要求し得、デバイス１６は、通知フラグをクリアする要求を受容するかまたは拒絶し得ること
である。
【００８２】
ステップ３０６において通知が送信された後にステップ３０８においてイベントに基づいた動作の実行が続くとして示されるけれども、動作が実行されると同時に通知が送信され得るか、または動作が実行された後に通知が送信され得ることが理解されることは注目されるべきである。この方法において、ステップ３０４は、通知フラグが設定されるステップ３１４として示され、その後、ステップ３０６ではなく、ステップ３１６および３１８が同時に実行される。あるいは、通知フラグは、動作が実行される前に設定される。ステップ３１６において、通知が送信され、そしてステップ３１８において、イベントに基づいた動作が実行され、そしてステップ３２０で表されるように、これらのステップ３１６と３１８との両方が完了するときに、通知フラグがステップ３２２においてクリアされる。
【００８３】
以下は、通知イベントの一部の例であり、それは、
１．  ＳＡＳバス上のエラー（ＥＲＲＯＲ）
２．  ＳＡＴＡバス上のエラー（ＥＲＲＯＲ）
３．  ＳＡＴＡドライブ（または、ＳＡＴＡデバイス）上のエラー（ＥＲＲＯＲ）
４．  内蔵セルフテスト（ｂｕｉｌｔ−ｉｎ  ｓｅｌｆ  ｔｅｓｔ；ＢＩＳＴ）を実行する要望
である。
【００８４】
以下は、デバイス１６によって１つ以上のイニシエータに送信される通知の一部の例であり、それは、
１．  デバイスビットＦＩＳを、
Ｎ＝１（Ｎは、通知を示し、ＦＩＳのフィールド内に現れる）
Ｉ＝０（Ｉは、割込みを示し、ＦＩＳのフィールド内に現れる）
に設定すること
２．  デバイスビットＦＩＳを、
ＮおよびＩのそれぞれが、１または０である
に設定すること
３．  デバイスビットＦＩＳを、
Ｐｏｒｔ  Ｓｅｌビットが、０に等しくない
に設定すること
４．  デバイスビットＦＩＳを、他の事前に規定されたビット（それは、理由コードを識別する理由コード（すなわち、通知の理由を識別するために用いられるコード）を含み得る）に設定すること
である。通知は、一般にプリミティブの形態であり、例えば、システムのトポロジの変化を公表し得る。Ｓｅｔ  Ｄｅｖｉｃｅ  Ｂｉｔ  ＦＩＳに対するフォーマットは、ＳＡＴＡ  Ｒｅｖ．２．６規格によって規定されるように、図１６において示される。
【００８５】
代替の実施形態において、イニシエータは、メールボックス内に情報を格納した後、通知フラグをステップ３０２とステップ３０４との間の相互通知において設定し得る。さらに代替としては、通知フラグは、別のイニシエータに伝達されることを意図される情報を伝える理由コードとともに設定され得る。
【００８６】
本発明のさらに別の実施形態において、イニシエータは、デバイス１６上のイベントによって割込み駆動され、このことは、従来技術のシステムによって必要とされるような、イベントの位置を見出すためにエクスパンダにクエリすることを必要としない。さらに代替としては、イニシエータは、デバイス１６上のイベントによって割込み駆動され、このことは、ドロップされるエクスパンダへのリンクを必要とせず、従ってシステムの性能を改善する。
【００８７】
さらに代替としては、デバイス１６がイニシエータに通知を生成するときに、イニシエータドライバは、ステータスをポーリングすることを回避するために、イニシエータドライバ自体への割込みとして通知フレームまたはプリミティブを用い得る。割込みの発生または検出の際に、イニシエータは、割込みを処理するために分岐する。この方法において、イニシエータは、ステータスをポーリングする必要がなく、そのことは、システムの性能を改善する。さらに、リンクはドロップされず、そのことがまた、システムの性能を改善する。
【００８８】
図８は、図７のステップ３０４における通知フラグの設定と、図７のステップ３１０における通知フラグのクリアとの間の時間の間に、デバイス１６とイベントを通知される１つ以上のイニシエータとによって実行されるステップのフローチャート４００を示す。
【００８９】
図８のステップ４０２において、イニシエータ、例えば、Ｉ０は、デバイス１６と通信するために、「オープン」されるようにＳＴＰ接続を要求する。次に、４０４において、通知フラグが設定されているか否かが、デバイス１６によって決定され、設定されている場合には、ステップ４０６において、通知がすでにイニシエータＩ０に送信されているか否かについての別の決定が行われる。ステップ４０４において、通知フラグが設定されていないことが決定される場合には、プロセスはステップ４０８に進み、そこでは通常動作が進行し、そしてステップ４１０において、フローチャート４００によって概説されたプロセスが終了する。ステップ４０６において、通知がすでにイニシエータ、Ｉ０に送信されていることが決定される場合には、プロセスは、ＳＴＰ接続がリトライされるステップ４１４に進み、そしてプロセスは、ステップ４１６において終了する。ステップ４１４のリトライは、イニシエータが、ステップ４０２におけるような、別のＳＴＰオープン接続を要求することを待機する結果をもたらす。ステップ４０６において、通知がすでにイニシエータＩ０に送信されていないことが決定される場合には、プロセスはステップ４１２に進行し、そこでは、デバイス１６が通知を送信する準備ができているか否かについての決定が行われ、準備ができている場合には、ステップ４１８において通知が送信され、そしてプロセスは、ステップ４１６に進む。４１２において、通知が送信されなかったことが決定される場合には、プロセスはステップ４１４に進む。
【００９０】
図９は、イニシエータフラグをクリアするために実行されるステップのフローチャート４２０を示し、図１３のステップ３１０において、それは、上記されたようにデバイス１６かまたはイニシエータによって行われ得る。通知フラグをクリアするデバイス１６の例を用いると、ステップ４２２において、イニシエータは、図７のステップ３０６においてデバイス１６から発生するイベントの通知を受信し、そしてイニシエータは、ステップ４２４において、通知に基づいた動作を実行する。そのような動作の例は、それに限定されないけれども、イニシエータによって送信されたコマンド（例えば、エラーに関して）をクリーンにするかまたはクリアすることであり、そしてデバイス１６もまた、そのコマンド（例えば、エラーに関する）をクリーンにするかまたはクリアし、プロセスは４２６において終了する。イニシエータが、そのエラーをデバイス１６がクリアしたことに気づかされる方法は、（１つ以上の）エラーがクリアされていない間は、ＳＴＰ接続が「オープン」されないので、デバイス１６とのＳＴＰ接続をオープンすることを、そのことに成功するまでトライまたはリトライすることによる。
【００９１】
図１０は、イニシエータフラグをクリアするために実行されるステップのフローチャート４３０を示し、図１３のステップ３１０において、イニシエータによって行われる。ステップ４３２において、イニシエータは通知を受信し、次に、ステップ４３４において、イニシエータは受信された通知に基づいた動作（例えば、イニシエータのコマンドを一掃することであるけれども、それに限定されない）を実行し、次に、ステップ４３６において、イニシエータは、ＳＭＰ接続を介して通知フラグをクリアすることを要求する。次に、４３８において、通知フラグのクリアがデバイス１６によって受容されているか否かが決定され、受容されていない場合には、プロセスはステップ４３６に戻って行き、受容されている場合には、プロセスはステップ４４０において終了する。ステップ４３８とステップ４３６との間のプロセスは、通知フラグのクリアがステップ４３８において受容されるまで、往復する。遅延がもしあれば、他のタスクによって占有されるデバイス１６によって引き起こされる。
【００９２】
ＳＭＰ接続応答は、理由コードおよび／または読み取りログデータおよび／または１つ以上のエラーと関連した情報を含み得る。
【００９３】
ここで、「Ｒｅａｄ  Ｌｏｇ  Ｄａｔａ」についての議論が提示される。「Ｒｅａｄ  Ｌｏｇ  Ｄａｔａ」は、ＳＡＴＡデバイスまたはドライブ内に発生した１つ以上のエラーについて、ＳＡＴＡドライブによって生成されたエラー情報である。代替の実施形態において、任意のタイプのログ情報またはデータ、すなわちログデータが、読み取りログデータの代わりに用いられ、従って企図され得る。従って、本明細書中の読み取りログデータのすべての議論および図は、等しくログデータにあてはまる。読み取りログデータは、従来技術のシステムに発生するエラー情報の損失を有利に回避する。例えば、ドライブがエラーを経験すると、ドライブがリセットされるときに、エラーについての情報がクリアされ、従って、非常に有用であり得る情報が失われる。読み取りログデータを読み取ることによって、情報のこの損失は回避される。さらに、ドライブリセットの後の複数のイニシエータからの情報の衝突は、読み取りログデータによって回避される。読み取りログデータによって有利に回避される別の問題は、タグの再マッピングにある。タグは、それらを異なるイニシエータに動的に割り当てるために、読み取りログデータにおいて再マッピングされ得る。タグは、イニシエータと関連づけられ、そして受信された情報をコマンドと相互に関係づけるために、イニシエータによって用いられる。
【００９４】
読み取りログデータは、イニシエータのタグとの一貫性を保証するために変更され得る。本発明の一実施形態において、本明細書中で上記された規格を用いれば、読み取りログデータは、「ｒｅａｄ  ｌｏｇ  ｅｘｔ」コマンドからの情報またはエラー情報を表しているＳＡＴＡドライブ上の他のデータであり得る。
【００９５】
読み取りログデータは、エラー情報あるいはデバイス１６および／またはイニシエータに関連する他のタイプの情報を含み得る。読み取りログデータをフェッチまたは取り出す様々な方法の例は、以下の通りであり、Ｒｅａｄ  Ｌｏｇ  Ｄａｔａの属性は、
１．  イニシエータが、選択された方法に基づいてフェッチし得ること
２．  読み取りログデータに対するＳＭＰ要求を発行すること
３．  フラグをクリアするＳＭＰ要求を発行すること−応答は読み取りログデータを含み得ること
４．  デバイス１６が、このデータを処理し（ｆｉｘ  ｕｐ）、ＳＴＰまたはＳＡＴＡを介してデータを送信し得ること
である。エラーログの例は、ＳＡＴＡ「ｒｅａｄ  ｌｏｇ  ｅｘｔ」コマンドである。
【００９６】
本発明の別の実施形態において、予備のタグ（ｒｅｓｅｒｖｅｄ  ｔａｇ）が用いられる。予備のタグは、割り当てられることに対して利用可能であるが、まだイニシエータタグに割り当てられていないタグである。イニシエータタグは、コマンドと関連づけられたタグであり、概して、イニシエータが特定の情報をタグが含まれるコマンドと関連づけることを可能にするコマンド内に含まれる。予備のタグは、入って来るイニシエータのコマンドに基づいて、イニシエータのタグから動的に割り当て可能であり、ここで、予備のタグが、ＳＡＴＡデバイスにコマンドを発行するために用いられる。入って来るイニシエータのコマンドは、デバイス１６によってイニシエータから受信されたコマンドである。
【００９７】
イニシエータによってアフィリエーションをクリアする際に、アフィリエーションをクリアするイニシエータに割り当てられたすべてのタグもまたクリアされる。本発明の一実施形態において、イニシエータは、連続した順序にある予備のタグを割り当てられ、それにより、タグとイニシエータとの関連は、タグの番号に基づいて知られる。あるいは、割り当てられた予備のタグは連続した順序にはない。デバイス１６は、割り当てられたタグを再要求するために、イニシエータと関連づけられたアフィリエーションをクリアする。
【００９８】
イニシエータは、上記されたように、ＳＭＰ接続を介して通知フラグを設定し得る。さらに、通知は、すべてのアフィリエートしたイニシエータまたはデバイス１６に依存するコマンドを有するすべてのアフィリエートしたイニシエータに行き得る。アフィリエーションは、ＳＡＳ規格に従った、イニシエータから（デバイス１６への）接続要求の受容を制限する方法である。従って、アフィリエーションは、所定の数のイニシエータからデバイス１６上への活動を可能にする。一旦所定の数に達すると、さらなるイニシエータは、イニシエータがそのアフィリエーションをクリアするまで、ＳＴＰを介してデバイス１６に通信し得ない。すなわち、テーブル１５０が満たされるときに、テーブルの最後の列内の「有効」ビットの１つがリセットされるまで、さらなるアフィリエーションが追加されないことがあり得、リセットされる「有効」ビットが存在する時点で、リセットされた「有効」ビットと同じ数の追加のアフィリエーションが、テーブル１５０に追加され得る。
【００９９】
図１１は、イニシエータによってログデータを読み取る（Ｒｅａｄ  Ｌｏｇ  Ｄａｔａ）ときに実行されるステップのフローチャート４５０を示す。図１１において、イニシエータｘ、Ｉｘが、例示的なイニシエータとして議論の目的のために用いられる。このことは、読み取りログデータをフェッチする多くの方法の１つである。
【０１００】
ステップ４５２において、Ｉｘは、利用可能な読み取りログデータの通知をデバイス１６から受信する。次に、ステップ４５４において、イニシエータＩｘは、ログデータを読み取ることを、ＳＭＰ接続を介して要求する次に、ステップ４５６において、読み取りログデータが準備できているか否かについての決定が行われ、準備できていない場合には、プロセスはステップ４６０に進み、そこでは、読み取りログデータがまだフェッチされていないか否かについての決定が行われ、フェッチされていない場合には、ステップ４６２において、「読み取りログデータは利用可能でない」という応答が戻される。ステップ４５６において、読み取りログデータが利用可能であることが決定される場合には、ステップ４５８において、読み取りログデータが戻され、図１１のプロセスが４６４において終了する。ステップ４６０において、それは、読み取りログデータがまだフェッチされていないことが決定される場合には、ステップ４６２が実行され、そこでは、「読み取りログデータは利用可能でない」が戻される。読み取りログデータがフェッチされる前または後に、通知が送信され得ることは注目されるべきである。
【０１０１】
図１２は、イニシエータ、Ｉ０に関連して実行される例示的なステップのフローチャート４８０を示し、それは、他のイニシエータ（この例においては、イニシエータＩ２である）に伝えられることを意図される情報を有する理由コードを設定する。ステップ４８２において、イニシエータＩ０は、理由コードとともに通知フラグを設定する（図７のステップ３０４）。次に、ステップ４８４において、デバイス１６は、通知をイニシエータＩ２に送信する。次に、ステップ４８６において、イニシエータＩ２は、（ステップ４８２において）Ｉ０によって設定されたフラグに付随するＩ０の理由コードに基づいた動作を実行する。上記の方法において、Ｉ２およびＩ０は通信し、それらの通信に基づいた特定の動作（イベントに基づいた動作）さえも実行する。
【０１０２】
図１３は、イニシエータＩ０とイニシエータＩｘｘとの間の情報を互いに利用可能にする、第二のメールボックスに関連して実行されるステップのフローチャート５００を示す。ステップ５０２において、イニシエータＩ０は、デバイス１６のメールボックス１３０の所定の位置に情報を格納する。次に、ステップ５０４において、Ｉ０は、Ｉ０の理由コードとともにフラグをメールボックス内に設定し、それにより、メールボックスを読み取るいかなるイニシエータも、Ｉ０によってメールボックス内に格納された情報に対する理由に気づくようになる。次に、ステップ５０６において、デバイス１６は、（１つ以上の）イニシエータに通知を送信し、それらのイニシエータに対してメールボックス内に格納された情報についての警告を行う。次に、ステップ５０８において、イニシエータ、Ｉｘｘは、Ｉ０によってステップ５０４において提供された理由コードに基づいてメールボックスを読み取る。この上記の方法において、Ｉ０およびＩｘｘは、デバイス１６のメールボックス１３０を用いて互いに通信する。
【０１０３】
図１４は、ＢＩＳＴなどのイベントを処理するために実行されるステップのフローチャート５１０を示すが、ＢＩＳＴに限定されない。図２０のステップ５１２において、イニシエータは、イベントを実行するためにデバイス１６に通知する。次に、ステップ５１４において、デバイス１６は、イベントフラグなどの適切なフラグを設定する。次に、ステップ５１６において、デバイス１６は、ステップ５１２においてイニシエータによって要求または通知されたイベントを実行する。イベントは、一例においては、ＢＩＳＴであり、従って、デバイス１６はＢＩＳＴを実行する。次に、ステップ５１８において、デバイス１６は、イベントを実行したことを示す通知を送信する。次に、ステップ５２０において、イベントフラグがクリアされる。
【０１０４】
図１５は、コマンドを再発行（または再送信）するために実行されるステップのフローチャート５３０を示す。コマンドは、それらがＳＡＴＡドライブの例えば、エラーまたはリセットに起因して処理されなかった場合には、再発行される必要がある。ステップ５３２において、通知フラグが設定される。次に、２つのステップが実行され、一方はステップ５３４であり、もう一方はステップ５３６である。ステップ５３４において、エラーのイニシエータに通知が送信され、ステップ５３６において、ＳＡＴＡドライブがリセットされる。本発明の例示的な方法において、ＳＡＴＡドライブをリセットすることが、システムの残りに対して同じものの（すなわち、この変化の）同報通信を引き起こさないことは注目されるべきである。同報通信をもたらす一方法は、同報通信プリミティブによることである。
【０１０５】
ステップ５３６の後、ステップ５３８が実行され、そこでは、非障害（ｎｏｎ−ｆａｉｌｉｎｇ）のコマンドがＳＡＴＡドライブに再送信される。ステップ５３４およびステップ５３８の後、ステップ５３４からステップ５３８までが完了しているか否かについての決定がステップ５４０において行われ、完了していない場合には、プロセスはそれの完了を待機する。決定が肯定的な結果をもたらす場合には、プロセスはステップ５４２に進み、そこでは、ステップ５３２において設定された通知フラグがクリアまたはリセットされる。上記のプロセスは、何らかの理由でＳＡＴＡドライブに送信されなかったコマンドを再発行し、それによって、イニシエータがコマンドを再送信し、かつ／またはコマンドを失う必要性を回避し、また、それによって、システムの性能、効率および完全性を増大させている。
【０１０６】
本発明が特定の実施形態によって記載されたけれども、その変更および修正は、当業者に対して疑う余地なく明白になることが予期される。従って、添付の特許請求の範囲は、本発明の真の精神および範囲内であるとして、すべてのそのような変更および修正を網羅するものと解釈されることが意図される。本発明を従来技術と組み合わせ、本発明の教示を含む複数の機能を実行するデバイスおよび方法を開発することは、当業者にとって明白である。そのようなデバイスおよび方法は、本発明の範囲内である。
【図１】
2010519617.tif 000003
【図２】
2010519617.tif 000004
【図３】
2010519617.tif 000005
【図４】
2010519617.tif 000006
【図５】
2010519617.tif 000007
【図６】
2010519617.tif 000008
【図７】
2010519617.tif 000009
【図８】
2010519617.tif 000010
【図９】
2010519617.tif 000011
【図１０】
2010519617.tif 000012
【図１１】
2010519617.tif 000013
【図１２】
2010519617.tif 000014
【図１３】
2010519617.tif 000015
【図１４】
2010519617.tif 000016
【図１５】
2010519617.tif 000017
【図１６】
2010519617.tif 000018
【国際調査報告】
2010519617.tif 000019