(57)【要約】  市販の消費者レベル記憶デバイスを使用して高度ストレージ機能を提供するための方法及びシステムが提供される。高度記憶システムは、コンピュータシステムと１つ又はそれ以上の物理ディスクドライブとの間に接続されたコンポーネントである。高度記憶システムのホストインタフェースは、コンピュータシステムのホストコントローラに良く知られている消費者レベルの記憶ハードウェアのコマンドを実装する仮想ディスクドライブとして、該ホストインタフェース自体をコンピュータシステムに提示する。同様に、高度記憶システムの記憶デバイスインタフェースは、接続されている物理記憶デバイスの実際のトポロジーに関係なく、消費者レベルホストコントローラとして該記憶デバイスインタフェース自体を１つ又はそれ以上のディスクドライブに提示する。本システムは、ユーザが低コストの消費者レベルハードウェアを結合して高性能ストレージ機能をコンピュータシステムに追加する簡単な方法を提供する。【選択図】なし
2009508192.tif 000002
【特許請求の範囲】
【請求項１】
１つ又はそれ以上の仮想ドライブとして物理ドライブを提示するためのシステムであって、
仮想コマンドを受け取るよう構成されたホストインタフェースコンポーネントと、
前記仮想コマンドを１つ又はそれ以上のマップコマンドにマッピングするよう構成されたマッピングコンポーネントと、
前記マップされたコマンドを１つ又はそれ以上のデバイスに送るよう構成されたデバイスインタフェースコンポーネントと、
を含むシステム。
【請求項２】
前記マッピングコンポーネントが、前記システムが製造されるときに構成される、
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記マッピングコンポーネント構成が、ハードウェアピンのセットの接続を修正することによって変更可能である、
ことを特徴とする請求項１に記載のシステム。
【請求項４】
前記マッピングコンポーネント構成が、ポリシーテーブルを修正することによって変更可能である、
ことを特徴とする請求項１に記載のシステム。
【請求項５】
前記マッピングコンポーネント構成が、新しいデバイスを前記デバイスインタフェースコンポーネントに取り付けることに応答して自動的に変更される、
ことを特徴とする請求項１に記載のシステム。
【請求項６】
前記デバイスインタフェースコンポーネントが、記憶デバイスをカスケードすることができるように、前記システムの第２インスタンスのホストインタフェースコンポーネントに接続される、
ことを特徴とする請求項１に記載のシステム。
【請求項７】
ホストコンピュータシステムにアクセス可能な前記カスケードされた記憶デバイスが、前記ホストコンピュータシステムによって固有にサポートされる記憶デバイスの数を上回る、
ことを特徴とする請求項６に記載のシステム。
【請求項８】
前記デバイスインタフェースコンポーネントが、カスケードされた物理デバイスにアクセスするためのルートを自動的に選択する、
ことを特徴とする請求項６に記載のシステム。
【請求項９】
前記ホストインタフェースコンポーネントが、前記マップされたコマンドに対する応答が受け取られる前に仮想コマンドに対する応答を送る、
ことを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ホストインタフェースコンポーネントが、前記デバイスインタフェースコンポーネントに接続された記憶デバイスによってサポートされる速度よりも速い速度で通信する、
ことを特徴とする請求項１に記載のシステム。
【請求項１１】
前記システムの構成を管理するための構成コンポーネントを更に含む、
ことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記ホストインタフェースコンポーネントが、ＳＡＴＡコマンドを使用して前記コンピュータシステムと通信する、
ことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記デバイスインタフェースコンポーネントが、ＳＡＴＡコマンドを使用して少なくとも１つのデバイスと通信する、
ことを特徴とする請求項１に記載のシステム。
【請求項１４】
前記ホストインタフェースコンポーネントが、ＳＡＴＡポートマルチプライヤコマンドを受け付ける、
ことを特徴とする請求項１に記載のシステム。
【請求項１５】
前記ホストインタフェースコンポーネントが、ＳＡＴＡ  ＮＣＱコマンドを受け付ける、
ことを特徴とする請求項１に記載のシステム。
【請求項１６】
マップされるコマンドが物理コマンドである、
ことを特徴とする請求項１に記載のシステム。
【請求項１７】
マップされるコマンドが仮想コマンドである、
ことを特徴とする請求項１に記載のシステム。
【請求項１８】
前記１つ又はそれ以上のデバイスの少なくとも１つが物理デバイスである、
ことを特徴とする請求項１に記載のシステム。
【請求項１９】
前記１つ又はそれ以上のデバイスの少なくとも１つが仮想デバイスである、
ことを特徴とする請求項１に記載のシステム。
【請求項２０】
１つ又はそれ以上の仮想ドライブとして物理ドライブを提示するための記憶システムにおける方法であって、該方法が、
仮想コマンドを受け取る段階と、
前記仮想コマンドを１つ又はそれ以上のマップコマンドにマッピングする段階と、
前記マップコマンドを１つ又はそれ以上のデバイスに送る段階と、
前記１つ又はそれ以上のマップコマンドに対する応答を受け取る段階と、
前記応答に基づいて仮想応答を送る段階と、
を含む方法。
【請求項２１】
構成情報を受け取る段階を含み、前記仮想コマンドをマッピングする段階が、前記受け取られた構成情報を使用する段階を含む、
ことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記構成情報が、前記システムが製造されるときに受け取られる、
ことを特徴とする請求項２１に記載の方法。
【請求項２３】
前記構成情報が、新しいデバイスを前記デバイスインタフェースコンポーネントに取り付けたことに応答して自動的に変更される、
ことを特徴とする請求項２１に記載の方法。
【請求項２４】
前記マップされたコマンドを送る段階が、記憶デバイスをカスケードすることができるように、前記システムの第２インスタンスにコマンドを送る段階を含む、
ことを特徴とする請求項２０に記載の方法。
【請求項２５】
ホストインタフェースを介してアクセス可能な前記カスケードされた記憶デバイスが、前記ホストインタフェースによって固有にサポートされる数を上回る、
ことを特徴とする請求項２４に記載の方法。
【請求項２６】
前記仮想応答が、前記マップコマンドに対する応答が受け取られる前に送られる、
ことを特徴とする請求項２０に記載の方法。
【請求項２７】
仮想コマンドが、マップコマンドが物理デバイスに送られる速度よりも速い速度で受け取られる、
ことを特徴とする請求項２０に記載の方法。
【請求項２８】
マップコマンドが物理コマンドである、
ことを特徴とする請求項２０に記載の方法。
【請求項２９】
マップコマンドが仮想コマンドである、
ことを特徴とする請求項２０に記載の方法。
【請求項３０】
前記１つ又はそれ以上のデバイスの少なくとも１つが物理デバイスである、
ことを特徴とする請求項２０に記載の方法。
【請求項３１】
前記１つ又はそれ以上のデバイスの少なくとも１つが仮想デバイスである、
ことを特徴とする請求項２０に記載の方法。
【請求項３２】
仮想コマンドを受け取る段階と、
前記仮想コマンドを１つ又はそれ以上のマップコマンドにマッピングする段階と、
前記マップコマンドを１つ又はそれ以上のデバイスに送る段階と、
前記１つ又はそれ以上のマップコマンドに対する応答を受け取る段階と、
前記応答に基づいて仮想応答を送る段階と、
を含む方法によって、物理ドライブを１つ又はそれ以上の仮想ドライブとして提示するように記憶システムを制御するための命令を包含するコンピュータ可読媒体。
【請求項３３】
前記デバイスインタフェースは、記憶デバイスをカスケードすることができるように前記システムの第２インスタンスに物理コマンドを送る、
ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２００５年８月２５日に出願された、名称「ＳＭＡＲＴ  ＳＣＡＬＡＢＬＥ  ＳＴＯＲＡＧＥ  ＳＷＩＴＣＨ  ＡＲＣＨＩＴＥＣＴＵＲＥ（スマートスケーラブル記憶スイッチアーキテクチャ）」の米国仮特許出願第６０／７１１，８６３号（代理人整理番号５９４７２−８０９２．ＵＳ００）に対する優先権を請求し、本仮出願は引用により本明細書に組み込まれる。
【背景技術】
【０００２】
記憶システムでは、耐故障性、スループット向上、記憶容量増大、及び拡大性などの特徴をもたらすために複数のディスクドライブを使用することが多い。例えば、ミラーリングは、２つ又はそれ以上のドライブを使用してデータのコピーを記憶し、ドライブの１つが故障した場合でも別のドライブからデータを読み取ることができるようにする。ストライピングによって、データを複数の小部分に分割することができ、該複数の小部分は、２つ又はそれ以上のドライブに並行して同時に書き込まれ（及び読み取られ）、スループットの向上をもたらすことができる。連結によって、２つ又はそれ以上のドライブが組み合わされ、単一のディスクドライブで利用可能となる記憶容量よりも大きな記憶容量が使用可能になる。このような特徴は、企業クラスのストレージソリューションでは一般的になっているが、消費者用のシステムでは希である。このようなシステムを構築するにはコストがかかり且つ複雑となるため、多くの消費者がこれらの高性能のストレージ機能を利用できないでいる。
【０００３】
また、市販の消費者レベルの記憶装置ハードウェアの設計制限により、これらの高性能のストレージ機能による利点をユーザが受けることができないでいる。例えば、多くのコンピュータシステムでは、単一のホストインタフェースによってアドレス指定することができるディスクドライブの数を制限している。Ｓｅｒｉａｌ  Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ（ＳＡＴＡ）１．０仕様（ｗｗｗ．ｓｅｒｉａｌａｔａ．ｏｒｇのウェブ上で利用可能）は、ホストに対して単一のディスクドライブの接続しかサポートしていない。その後のＳＡＴＡＩＩポートマルチプライヤ仕様（ｗｗｗ．ｓｅｒｉａｌａｔａ．ｏｒｇのウェブ上で利用可能）では、１つのホストが１５の物理ディスクドライブをアドレス指定することができる追加のアドレス指定方式が付加されたが、全てのホストがこのより新しい仕様をサポートしているとは限らず、ホストコンピュータシステムに複数のドライブを管理させるには複雑で構成の追加を伴うので、多くの消費者にとって困難である。最終的には、消費者は、企業クラスのコンピュータシステムに利用可能なハイエンドストレージ機能を提供することが可能な、使い易く安価なハードウェアを手に入れることはできないことになる。
【発明の開示】
【０００４】
市販の消費者レベル記憶デバイスを使用して高度ストレージ機能を提供するための方法及びシステムが提供される。高度記憶システムは、コンピュータシステムと１つ又はそれ以上の物理ディスクドライブとの間に接続されたコンポーネントである。高度記憶システムのホストインタフェースは、コンピュータシステムのホストコントローラによく知られている消費者レベルの記憶ハードウェアのコマンドを実装する１つ又はそれ以上の仮想ディスクドライブとして、該ホストインタフェース自体をコンピュータシステムに提示する。同様に、高度記憶システムの記憶デバイスインタフェースは、接続されている物理記憶デバイスの実際のトポロジーに関係なく、消費者レベルホストコントローラとして該記憶デバイスインタフェース自体を１つ又はそれ以上の物理ディスクドライブに提示する。最初に、高度記憶システムは、コンピュータシステムから仮想ドライブへのコマンドを受け取り、このコマンドを１つ又はそれ以上の物理コマンドにマッピングする。次に、マップされた物理コマンドは、物理ディスクドライブに送られ、コマンドの内容を実行する。最後に、物理ディスクドライブからの応答が結合され、仮想コマンドに対する単一の応答がコンピュータシステムに戻される。本システムは、ユーザが低コストの消費者レベルハードウェアを結合して高性能ストレージ機能をコンピュータシステムに追加する簡単な方法を提供する。
【０００５】
この要約は、詳細な説明において以下に更に説明される簡略化された形式での概念の選択をもたらすために提供される。本要約は、請求項に記載された対象の主要な特徴又は本質的な特徴を特定するためのものでもなく、更に請求項に記載される対象の範囲を限定するために使用されるものでもない。
【発明を実施するための最良の形態】
【０００６】
市販の消費者レベルの記憶デバイスを使用して高性能ストレージ機能を提供するための方法及びシステムが提供される。例えば、高度記憶システムは、耐故障性記憶システムを提供するために複数の既成のハードドライブの使用を可能にする。高度記憶システムは、コンピュータシステムと１つ又はそれ以上の物理ディスクドライブとの間に接続される構成要素である。高度記憶システムのホストインタフェースでは、これ自体は、コンピュータシステムのホストコントローラによく知られた消費者レベルの記憶ハードウェアのコマンドを実装する仮想ディスクドライブとしてコンピュータシステムに対して提示される。例えば、高度記憶システムは、単一のハードドライブとしてコンピュータシステムに表示することができる。同様に、高度記憶システムの記憶デバイスインタフェースでは、これ自体は、接続される物理記憶デバイスの実際のトポロジーに関係なく消費者レベルのホストコントローラとして１つ又はそれ以上のディスクドライブに対して提示される。例えば高度記憶システムは、単一の仮想ディスクドライブとしてコンピュータシステムに提示される２つの物理ドライブに接続することができ、各ディスクドライブは、システムに接続された唯一のドライブと考えることができる。コンピュータシステム、高度記憶システム、及びディスクドライブ間の各接続は、データチャネルを形成する。最初に、高度記憶システムは、コンピュータシステムから仮想ドライブへのコマンドを受け取り、このコマンドを１つ又はそれ以上の物理コマンドにマッピングする。例えば、記憶システムは、実際には２つの異なる物理ドライブ上に記憶されている１メガバイトのデータを仮想ドライブ上のロケーションから読み取るコマンドを受け取ることができる。次に、コマンドの内容を実行するために、マップされた物理コマンドが物理ディスクドライブに送られる。例えば、仮想読取りコマンドは、２つの別個の読み取りコマンドに分割され、これらが物理ディスクドライブの各々に送られ、各々がデータの異なる部分を読み取ることができる。最後に、物理ディスクドライブからの応答が組み合わされ、仮想コマンドに対する単一の応答がコンピュータシステムに返される。例えば、２つの別個のディスクドライブから読み取られたデータは、あたかも単一のディスクドライブから受け取られたものであるように単一の応答に組み合わされる。コストを低減するために、高度記憶システムを単一のチップ上に設けることができる。このシステムは、ユーザが低コストの消費者レベルのハードウェアを結合して、コンピュータシステムに高性能ストレージ機能を追加する簡単な方法を提供する。
【０００７】
幾つかの実施形態では、高度記憶システムは、消費者構成が必要でないように製造中に特定の特徴を提供するように構成されている。例えば、高度記憶システムは、接続される追加のディスクドライブを連結するよう構成することができる。消費者は、高度記憶システムと幾つかのハードドライブを購入する。新しいドライブが各々高度記憶デバイスに取り付けられると、コンピュータシステムは、容量が増えた単一の仮想ドライブとみなす。消費者は、後で追加のドライブを購入し、ホストシステムを再構成することなくより大きな記憶容量を追加することもできる。高度記憶システムはまた、データの損失を防ぐためにミラーリングを可能にするよう構成することもできる。消費者が追加のハードドライブを接続すると、各ハードドライブ上のデータが他のドライブにミラーリングされ、これによって１つのドライブが故障した場合に、別のディスクドライブ上のデータにアクセスする（例えば、読み取り、書き込み、その他）ことができるようになる。高度記憶システムの構成は、一連のハードウェアピン又はジャンパを介して、或いは製造中に特定のファームウェアイメージをシステムにフラッシュすることによって行うことができる。例えば、システムは、ポリシーテーブルを使用して、動作指令形式で構成情報を定義することができる。デバイス内の制御論理が決定ポイントに達し、複数の可能性から一連の動作を選択しなくてはならない場合、テーブルを参照し、該テーブルが指示する動作を実行する。これにより、ポリシーテーブルのコンテンツを変更することで、同じハードウェアを使用して異なる特徴を簡単に表すことが可能になる。ポリシーテーブルの特定のポリシーを無効にするハードウェアピンを設けることができ、ポリシーテーブルを修正することなく付加的な構成可能性を実現する。
【０００８】
幾つかの実施形態では、高度記憶システムは、他のこのようなシステムと共にカスケードされ、付加的なストレージ機能を提供することができる。例えば、ホストコンピュータシステムに高度記憶システムの１つのインスタンスを接続することができ、この最初のインスタンスに高性能コンピュータシステムの別のインスタンスを接続することができる。このようにして、平均的な消費者が複雑な記憶トポロジーを容易に構築することができる。例えば、接続されたデバイスを連結するよう構成された高度記憶システムの１つのインスタンスは、ホストコントローラに接続することができ、接続されたドライブのミラーリングを可能にするよう構成された付加的なインスタンスは最初のインスタンスに接続することができ、大容量のミラーリングされた仮想記憶デバイスが生成されるようになる。ホストシステムは、単一の大きなディスクドライブだけを調べることができ、接続された記憶デバイスと通信するために標準のディスクドライブコマンドを使用することができる。高度記憶システムの各インスタンスは、ホストインタフェース上で受け取られた仮想コマンドを記憶インタフェース上の接続されたドライブの各々に送られる物理コマンドに変換する（次いで、カスケードされた高度記憶システムインスタンスによって仮想コマンドとして扱うことができる）。
【０００９】
幾つかの実施形態では、高度記憶システムは、ホストと高度記憶システムとの間の肯定応答サイクルと、接続されたデバイスと高度記憶システムとの間の肯定応答サイクルとを区別する。例えば、高度記憶システムは、コマンドを実行する物理ドライブがオペレーションの成功又は失敗を肯定応答する前でも、ホストインタフェース上で受け取られた仮想コマンドに応答してデータが書き込まれたことを推論的に肯定応答することができる。複数の物理ドライブが高度記憶システムを使用してカスケードされているトポロジーでは、コマンドが受け取られた時間とコマンドが終了し肯定応答された時間との間の各レイヤでの遅延により生じる待ち時間を低減することで、推論的肯定応答により性能が向上する。本システムはまた、成功を示す要求に応答し、次いで成功するまで物理コマンドを再トライすることによって、失敗した物理コマンドの再トライをホストコンピュータシステムから非表示にすることができる。場合によっては、最終的には失敗した１つのチャンクの書き込みの成功を高度記憶システムが推論的に肯定応答する場合、システムが全体的な記憶オペレーションの失敗をレポートすることができるように、チャンクに大量のデータを書き込むなど、全体的な記憶オペレーションが断片的に行われる。これにより、システムは、オペレーションの成功又は失敗に関するホストシステムの認識の完全性を維持しながら、付加的な性能を得ることができる。
【００１０】
幾つかの実施形態では、高度記憶システムは、幾つかの低速のデータチャネルを集約して１つのより高速のデータチャネルにする。例えば、高度記憶システムが、１．５ギガバイト／秒（Ｇｂｐｓ）のデータ転送速度を有するＳＡＴＡ  Ｉ仕様を実装する２つの物理ディスクドライブに接続された場合、高度記憶システムは、３．０Ｇｂｐｓのデータ転送速度を有して、コンピュータシステムにＳＡＴＡ  ＩＩ仕様ホストインタフェースを提示することができる。高度記憶システムは、ディスクドライブから並行して読み取り及び書き込みを行うので、コンピュータシステムは、２つのドライブの組み合わされたスループットによる利点が得られる。
【００１１】
幾つかの実施形態では、高度記憶システムは、複数のドライブ及びカスケード高度記憶システムコンポーネント間で記憶コマンドを送るためのルートを自動的に選択する。高度記憶システムは、メッシュトポロジーを使用し、ドライブとホストコンピュータシステムとの間のホップの数を最小にすることによって待ち時間を低減するようにして各ドライブにアクセスすることができる。例えば、複数の高度記憶システムコンポーネントは、メッシュを形成するように接続することができる。コマンドは、多くの異なる方法でメッシュ内を転送させることができる。例えば、ドライブへのコマンドは、１０個の高度記憶システムコンポーネントのチェーンを介して送られるが、これは、コマンドを終了させるのに極めて長い待ち時間をもたらすことになる。その代わりに、高度記憶システムコンポーネントは、互いに通信してカスケードディスクドライブまでの最速パスを選ぶことになる。
【００１２】
幾つかの実施形態では、高度記憶システムは、新しいドライブが取り付けられたときにこれ自体を自動的に再構成する。例えば、ユーザがシステムに第４のドライブを取り付けると、高度記憶システムは、このドライブを他のドライブと自動的に連結し、既存の仮想ボリュームのサイズを大きくする。同様に、高度記憶システムは、新しいドライブを他のボリュームに対するミラーとして自動的に使用することができる。高度記憶システムの構成、既存のドライブ及び新しいドライブのサイズ、及びドライブの速度などの幾つかの要因に基づいた決定を行うことができる。例えば、ミラーリングを行う必要があることを構成が示した場合には、高度記憶システムは、単一の７５ギガバイト（ＧＢ）の接続ディスクドライブを使用して、３つの他の２５ＧＢの接続ドライブをミラーリングすることができる。同様に、２つの１．５Ｇｂｐｓドライブが既に接続されている場合、本システムは、２つのオリジナルドライブに並行して書き込むことができる同じ時間で書き込むことができるので、新しい３．０Ｇｂｐｓドライブをミラーとして構成することができる。本システムは、外部構成を必要としないので、他の記憶システムが使用できない状況で使用することができる。例えば、セットトップボックス、パーソナルビデオレコーダ、ＭＰ３プレーヤー、及び他の組み込みデバイスは全て、記憶機能の追加及び耐故障性などの高度機能による利点を得ることができるが、構成ユーザインタフェース、或いは場合によっては他の記憶システムが必要となる構成ユーザインタフェースの表示用ハードウェアは存在しないことがある。
【００１３】
幾つかの実施形態では、高度記憶システムは、取り付けた物理ドライブのシリアルナンバーを仮想対物理変換状態情報に記録する。ドライブの識別は、新しいドライブ又は以前認識されたドライブの取り付けなどの外部事象に応答したより高機能なポリシーを可能にする。ドライブが挿入されると、ドライブは既知の物理デバイスのリストと比較される。新しく取り付けられたドライブが認識されたが、異なる物理インタフェースに取り付けられた場合、この位置変更を考慮するよう変換情報が自動的に更新される。ドライブが認識されなかった場合、高度記憶システムの幾つかの実施形態は、利用できる可能な拡張アクセスモード（例えば、ミラーリング、ストライピング、連結）のいずれかで新しいドライブ（又はその一部）を追加するよう変換情報を更新することになる。高度記憶システムの幾つかの実施形態では、新しい物理ドライブは変換情報に追加されず、これによって追加のユーザ動作が取られるまで新しいドライブへのアクセスができないようにすることができる。高度記憶システムは、物理ドライブへのアクセスを安全にするために種々のドライブロッキング機能を提供することができる。最新のＳＡＴＡディスクドライブは、ドライブをロック及びアンロックし、ドライブ自体の内部にパスワードを記憶するようなホストからのコマンドをサポートしている。１つの実施形態では、ドライブアクセスコマンドの仮想対物理変換は、このようなドライブロッキングコマンドのサポートを含む。例えば、（仮想）ドライブをロック（又はアンロック）する要求をホストから受け取った場合、コマンドは、物理ドライブの適切なセットに転送される。このような実施形態では、ホストデバイスが仮想ドライブをホストデバイス自体にバインドすることが可能となり、仮想ドライブの全ての物理ドライブコンポーネントを（適切なパスワードなしには）他のどのようなホストデバイスによってもアクセスできないようにする。幾つかの実施形態では、高度記憶システムは、全てのドライブロッキングタスクを内部的に実行する。新しい物理ドライブが取り付けられると、ドライブロック要求が該ドライブに送られ、パスワードが仮想対物理変換状態情報内に記憶される。続いて、仮想ドライブへのアクセス要求がホストインタフェース上で受け取られると、アクセス要求は、適切な物理ドライブに対するアクセスのセットに変換され、これらは各々、前に記憶されていたパスワードを使用するドライブアンロック要求よりも優先して動作する。これは、物理ドライブを高度記憶システムの特定のインスタンスにバインドし、これらの物理ドライブを他のいずれのホストデバイスによっても（適切なパスワードなしには）アクセスできないようにする。
【００１４】
図１は、１つの実施形態における高度記憶システムのコンポーネントを示すブロック図である。ホストコンピュータシステム１００は、高度記憶システム１５０に接続され、該高度記憶システム１５０は、１つ又はそれ以上のディスクドライブ（例えば１８０及び１９０）に接続されている。ホストコンピュータシステム１００は、ディスクドライブ又は高度記憶システム１５０などの記憶デバイスと通信するためのホストコントローラ１０５を含む。高度記憶システム１５０は、ホストインタフェースコンポーネント１５５、構成コンポーネント１６０、仮想対物理マッピングコンポーネント１６５、及びデバイスインタフェースコンポーネント１７０を含む。ホストインタフェースコンポーネント１５５は、ホストコントローラ１０５と通信し、記憶コマンドを実行する。ホストコントローラ１０５から受け取られた記憶コマンドは、高度記憶システム１５０によってホストコンピュータシステム１００に提示された仮想ドライブへの仮想コマンドとして処理される。構成コンポーネント１６０は、ドライブが幾つ接続されているか、及びどのストレージ機能（例えばストライピング、ミラーリング、及び連結）を提供するように各ドライブが使用されているかなど、高度記憶システム１５０についての構成情報を記憶している。仮想対物理マッピングコンポーネント１６５は、構成コンポーネント１６０によって記憶されている構成に基づいて、ホストインタフェース１５５から受け取られた仮想コマンドをデバイスインタフェース１７０に送出される物理コマンドにマッピングする。仮想対物理マッピングコンポーネント１６５はまた、ホストインタフェース１５５を介してデバイスインタフェースコンポーネント１７０から受け取られた物理応答をホストコンピュータ１００に送られる仮想応答にマッピングする。デバイスインタフェースコンポーネント１７０は、１つ又はそれ以上の物理ディスクドライブ（又は追加の高度記憶システム）と通信し、記憶コマンドを実行する。
【００１５】
システムが実装されるコンピューティングデバイスは、中央処理ユニット、メモリ、入力デバイス（例えば、キーボード及びポインティングデバイス）、出力デバイス（例えば、ディスプレイデバイス）、及び記憶デバイス（例えば、ディスクドライブ）を含むことができる。メモリ及び記憶デバイスは、システムを実施する命令を含むことができるコンピュータ可読媒体である。更に、データ構造及びメッセージ構造は、通信リンク上の信号など、データ送信媒体を介して記憶又は送信することができる。インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、ポイントツーポイントダイヤルアップ接続、携帯電話ネットワークなどの種々の通信リンクを使用することができる。
【００１６】
本システムの実施形態は、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルド又はラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電子機器、デジタルカメラ、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステム又はデバイスのいずれかを含む分散型コンピューティング環境などを含む種々のオペレーティング環境で実施することができる。コンピュータシステムは、携帯電話、パーソナルデジタルアシスタント、スマートフォン、パーソナルコンピュータ、プログラム可能家庭用電子機器、デジタルカメラなどとすることができる。
【００１７】
本システムは、１つ又はそれ以上のコンピュータ或いは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な関連において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか又は特定のアブストラクトデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラムモジュールの機能は、種々の実施形態で説明されるように組み合わせ又は分散することができる。
【００１８】
図２は、１つの実施形態におけるカスケード高度記憶システムデバイスのトポロジーを示す。ホストコンピュータ２０５は、高度記憶システムコンポーネント２１０に接続されている。高度記憶システムコンポーネント２１０は、単一の標準ディスクドライブ２７０としてホストコンピュータ２０５に表示される。高度記憶システムコンポーネント２１０は、第１ディスクドライブ２１５、第２ディスクドライブ２２０、及び別の高度記憶システムコンポーネント２２５に接続されている。高度記憶システムコンポーネント２２５及び関連のディスクドライブ２３０及び２４０は、この実施形態では別のディスクドライブ２５０として第１高度記憶コンポーネント２１０に表示することができ、或いは２つのコンポーネントが、プライベート通信チャネル（独立接続又はデータチャネルを通じて送られるカスタムプロトコルなど）を有することができ、これにより、２つのコンポーネントが互いを認識し構成情報を交換することが可能になる。第２高度記憶システムコンポーネント２２５は、第１ディスクドライブ２３０及び第２ディスクドライブ２４０に接続されている。本システムは、多くの方法で構成することができる。例えば、第１高度記憶システムコンポーネント２１０は、２つのドライブ２１５及び２２０の連結を可能にするよう構成することができ、第２高度記憶システムコンポーネント２２５は、ディスクドライブ２３０及び２４０の他のペアを使用して連結ディスクドライブ２１５及び２２０のミラーリングを可能にするよう構成することができる。
【００１９】
図３は、１つの実施形態におけるシステムの仮想対物理マッピングコンポーネントの処理を示すフロー図である。高度記憶システムのホストインタフェースからコマンドが受け取られると、コンポーネントが呼び出される。ブロック３１０で、コンポーネントは、高度記憶システムによって提供される仮想ディスクドライブに向けたコマンドを受け取る。ブロック３２０で、コンポーネントは、仮想コマンドを１つ又はそれ以上の物理コマンドにマッピングする。ブロック３３０で、コンポーネントは、マッピングによって生成された次の物理コマンドを取得する。ブロック３４０で、コンポーネントは、物理コマンドを適切な物理デバイスに送る。ブロック３５０で、コンポーネントは、コマンドに対する物理デバイスからの応答を受け取る。幾つかの実施形態では、コンポーネントは、物理デバイスからの応答を待機しなくてもよい。例えば、コンポーネントは、コマンドが成功すると仮定して、全ての物理応答が受け取られる前に仮想コマンドに応答することができ、或いはコンポーネントは、物理応答をチェックする前に全ての物理コマンドが送られるまで待機してもよい。決定ブロック３６０で、マッピングによって生成された物理コマンドがまだある場合には、コンポーネントはブロック３３０にループして次の物理コマンドを取得し、物理コマンドがない場合には、コンポーネントはブロック３７０に進む。ブロック３７０で、コンポーネントは、もしあれば、受け取った物理応答に基づいて仮想応答を生成する。ブロック３８０で、コンポーネントは、コンポーネントが仮想コマンドを受け取ったコンピュータシステム又はデバイスに仮想応答を送る。次いでコンポーネントは終了する。
【００２０】
図４は、１つの実施形態における仮想応答を生成するための仮想対物理マッピングコンポーネントの処理を示すフロー図である。ブロック４１０で、コンポーネントは、ディスクドライブ又は他のデバイスに送出された物理コマンドに対する物理応答を待機する。決定ブロック４２０で、物理コマンドが成功した場合、コンポーネントはブロック４３０に進み、成功しなければ、コンポーネントはブロック４６０に進む。ブロック４３０で、コンポーネントは、仮想応答に含まれるはずの物理応答からのあらゆるデータ（例えば、ディスクドライブからのデータを物理コマンドが読み取る場合など）を仮想応答に追加する。決定ブロック４４０で、送出された物理コマンドがまだある場合、コンポーネントはブロック４１０にループして、次の物理応答を待機し、物理コマンドがない場合、コンポーネントはブロック４５０に進む。ブロック４５０で、コンポーネントは、成功応答及びあらゆる含まれるデータを送ることによって、仮想コマンドの成功をレポートする。ブロック４６０で、コマンドが失敗した場合、コマンドは、仮想コマンドが成功しなかったことを示す失敗応答を送る。成功又は失敗応答が送られた後、コンポーネントは終了する。
【００２１】
追加の実施形態
ここで高度記憶システムの幾つかの追加の実施形態について説明する。第１の実施形態は、高度記憶システムのアーキテクチャ、いわゆるＳｔｅｅｌＶｉｎｅを説明する。Ｐｏｌａｒｉｓ、Ｐｉｃｏ、及びＭｉｌｋｙｗａｙなどの他の実施形態は、高度ストレージ機能を消費者市場が利用可能にするチップソリューション上で完全な記憶システムを提供するＳｔｅｅｌＶｉｎｅアーキテクチャのハードウェア実施形態を説明する。
【００２２】
ＳｔｅｅｌＶｉｎｅアーキテクチャは、全く新しい製品カテゴリー、すなわちストレージサブシステムオンチップ（ＳＳｏＣ）をもたらす最近定義されたＳＡＴＡ記憶インタフェース規格を構築する。ＳｔｅｅｌＶｉｎｅアーキテクチャベースのＳＳｏＣは、ＳＡＴＡ仕様の全てに準拠するが、新しく斬新な方法でＳＡＴＡ仕様を解釈し使用する。このアーキテクチャは、これまではハイエンドの企業規模の記憶サブシステムでのみ利用可能であった機能をハイボリューム、低コスト、且つ市販ベースのコンピューティング領域にもたらすために新しいＳＡＴＡ規格を使用する。
【００２３】
ＳｔｅｅｌＶｉｎｅコンポーネントは、物理ドライブのセットをフレキシブルに仮想化する機能、ネイティブコマンドキューイング（ＮＣＱ）のサポート、並びにＲＡＩＤ（−１、０、１、及び１０）機能など、高レベルエンタープライズ記憶機能を含むように標準的なポートマルチプライヤ概念を拡張する。この理由により、第１のＳｔｅｅｌＶｉｎｅ製品は、「高度」ポートマルチプライヤ機能を提供すると言われる。
【００２４】
幾つかの実施形態では、これらの製品は、高度にハードウェアでサポートされるマイクロコード集約的なストレージサブシステムオンチップ（ＳＳｏＣ）として実装される。標準的なＳＡＴＡホストアダプタ及びディスクドライブの観点から、これらの製品は、「ｂｕｌｇｅ  ｉｎ  ｔｈｅ  ＳＡＴＡ  ｃａｂｌｅ」として表示され、すなわち、ホストに対するターゲットとして表示され、その逆もまた同様である。利用可能な物理ドライブから種々のプロパティを有する仮想ドライブのイリュージョンを生成するために、ホストによって生成され且つ仮想ドライブに向けられるコマンドパケットが、取り付けられた物理ドライブに向けられる新しいコマンドパケットに変換される。ＳＳｏＣによって行われるこの変換は、コンポーネント内に包含される構成データに基づいてワイヤスピードで生じる。この変換はまた、単一の入力仮想コマンドに応答して、複数の物理ドライブコマンドの生成を含むことができる（例えば、ミラーリングされた仮想ドライブ上で複数の書き込みを行う、複数の連結されたドライブに及ぶ読み取りを行う、その他）。
【００２５】
高レベル記述における類似性に関わらず、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣが標準的な外部ＲＡＩＤコントローラとはアーキテクチャ的及び機能的に全く異なっている点に留意することは重要である。詳細には、ＳｔｅｅｌＶｉｎｅコンポーネントは、汎用プロセッサハードウェアのトップにソフトウェアとして実装されることはない。これは、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣが単純な低コストのシングルチップダムポートマルチプライヤコンポーネントの規模の遙かに低コストで複雑さが少ないワイヤスピード性能が得られることを意味する。多くの問題に対し単純なブルート−フォースソリューションを適用することによって、複雑さが低減され、管理コストが排除される。例えば、高度な信頼性を提供するために単純なミラーリングが使用される。このソリューションは、処理及びメモリリソースの点で従来のパリティ−ＲＡＩＤソリューションに比べあまりリソースを必要とせず、低（及び減少し続ける）コストのディスクドライブの支出でその信頼性が達成される。
【００２６】
幾つかの実施形態では、ＳｔｅｅｌＶｉｎｅアーキテクチャは、アプライアンスモデルにより記憶装置を提供する。ユーザは、起きていることについて何も理解する（或いは知ることも）ことを必要とせず、ユーザが要求する機能を単にユーザが理解している用語（例えば、大きい、速い、信頼できる、など）で、且つ提供されるサービスに対して支払う意思のあるコストで取得する。このアプライアンスベースの手法は、大量生産の製品を販売する助けとなる。大量生産のカテゴリーのユーザは、ＲＡＩＤの意味を知っていることは期待できず、ましてどの構成オプションが適切であるかを決定するのに十分な程度ＲＡＩＤがどのように働くかを理解することはできない。更に、アプライアンス手法は、ストレージサービスとホストコンピュータとの間のインタフェースを最小限にする。これは、要求されるストレージサービスがホストへの変更又は構成なしに取得できることを意味するので、ユーザにとって重要な利点である。ホストハードウェア、ＢＩＯＳ、ＯＳ、及びアプリケーションに対して物理ディスクのように見える記憶デバイスは、ホストに対して何も修正又は追加することなく高度な機能を提供することができる。
【００２７】
ポリシーとメカニズムの徹底した分離によって、ＳｔｅｅｌＶｉｎｅアーキテクチャは、ユーザセットアップを必要とせずに全てを行う工場セットアップから生じる固定構成（例えば、単一のドライブのように見えるマルチドライブユニット、すなわちデュプレクスドライブ、又は単一のパワーコネクタ及びホストポートを備えた３．５インチエンベロープの４つの２．５インチドライブ）から、ポリシーをユーザが定義することができ、アレイの各動作を徹底してモニターしてログすることを可能にする高スケーラブルなハイタッチＲＡＩＤアレイまで、広範囲の種々の使用ケースにおいてＳＳｏＣを適用することができる。
【００２８】
以下のセクションでは、ＳｔｅｅｌＶｉｎｅアーキテクチャに基づく製品が動作するシステムコンテキストを定義し、このアーキテクチャによって提供される主な特徴を説明し、更にＰｏｌａｒｉｓ及びＭｉｌｋｙｗａｙハードウェアを使用する記憶サブシステムに関連する主な実装問題の概要を提供する。
【００２９】
ＳｔｅｅｌＶｉｎｅ記憶サブシステムの概要
ＳＡＴＡは、ホストバスアダプタ（ＨＢＡ）とディスクドライブとの間のポイントツーポイント接続として設計されている。ＳＡＴＡリンクの帯域幅（すなわち、１．５Ｇｂｐｓ、３Ｇｂｐｓ、又は６Ｇｂｐｓ）が現在のハードドライブの帯域幅を超えるので、複数のドライブを単一のＳＡＴＡ（ホスト）ポートに接続し、最も遅いＳＡＴＡリンクの帯域幅性能を超えないようにできる。この理由のために、複数のドライブを単一のホストポートに取り付けられるようにするＳＡＴＡポートマルチプライヤ（ＰＭ）仕様が定義された。ＳＡＴＡ  ＰＭ仕様は、単純な多重タイプ又はハブタイプデバイスを定義し、シリコンイメージは、この仕様を拡張し、デバイスの新しいタイプである拡張型ポートマルチプライヤ（ＥＰＭ）を生成する。ＥＰＭは、ＰＭの基本的なハブ様機能に加えて、従来の大きく且つ高コストの複雑な記憶アレイコントローラに関連する機能を提供するストレージサブシステムオンチップ（ＳＳｏＣ）である。
【００３０】
ＳｔｅｅｌＶｉｎｅコンポーネントは、物理ドライブのコレクションを幾つかの仮想ドライブに変え、その各々は、仮想ドライブが構成される物理ドライブに比べてより拡張された特性（例えば、より大きい、より速い、或いはより信頼できる）を有することができる。更に、より高度なＳｔｅｅｌＶｉｎｅコンポーネント（例えば、Ｍｉｌｋｙｗａｙ）は、コンポーネントをファブリックに接続可能にすることによってスケーラビリティを提供する追加のメッシュルーティング機能を有する。これにより、物理ドライブの潜在的に大きなセットをホストの潜在的に大きなセットが利用可能な仮想ドライブのセットにマッピングすることが可能になる。
【００３１】
コンポーネントのＳｔｅｅｌＶｉｎｅファミリーの１つの設計目的は、ホストに対して完全にトランスペアレントな方式で要求される物理ドライブ拡張の全てを実施することである。事実上、ＳｔｅｅｌＶｉｎｅコンポーネントは、ワイヤで「バルジ」のように表示され、すなわちホストに対しＰＭのように見え、ドライブに対しＨＢＡのように見える。ホストの観点から、ＳｔｅｅｌＶｉｎｅコンポーネントによって提供される仮想ドライブと同じプロパティ（例えば、サイズ、速度、又は信頼性）を備えた物理ドライブとを区別することが事実上不可能になる。これは、多様なホストシステムとの相互運用性を保証し、カスタムホストサイド（アプリケーション、ドライバ、ＢＩＯＳなど）ソフトウェアの大きなスーツを開発、インストール、及びサポートする必要性を排除する。
【００３２】
ＳｔｅｅｌＶｉｎｅファミリーにおける初期製品（すなわち、独立型ＰＭ及びＥＰＭ（Ｐｏｌａｒｉｓ）、並びにスケーラブルＥＰＭ（Ｍｉｌｋｙｗａｙ））は、単一の高集積ストレージサブシステムオンチップ（ＳＳｏＣ）に完全な記憶サブシステム機能を提供するよう設計されている。ＳｔｅｅｌＶｉｎｅコンポーネント（関連のオンチップ組み込みソフトウェアを有する）は、ほぼ完全な記憶サブシステム機能を提供するが、完全な記憶サブシステムを作成するために少数の付加的なコンポーネント（例えば、外部ＥＥＰＲＯＭ、ＬＥＤ、ＬＭ８７環境制御コンポーネント、その他）を必要とする場合がある。完全なサブシステムに必要とされるコンポーネント、並びに完全なＰｏｌａｒｉｓベース記憶サブシステムを含む主要エンティティの全てを以下に説明する。
【００３３】
ＳｔｅｅｌＶｉｎｅアーキテクチャのアプリケーション
以下の段落では、ＳｔｅｅｌＶｉｎｅアーキテクチャが記憶インタフェースの階層でどこに適合するか、このアーキテクチャが現在他の既存のアーキテクチャにどのように関係するか、及びこのアーキテクチャに基づく製品がどのように表示されるかに関して説明する。
【００３４】
ＳｔｅｅｌＶｉｎｅアーキテクチャは、仮想ドライブが作成される元の物理ドライブに比べてより拡張された特性を有する仮想ドライブを作成する概念に基づいている。このアーキテクチャでは、これらの拡張は、物理ドライブが有するホストへの同じインタフェースを提示する場合に提供される。この結果、ＳｔｅｅｌＶｉｎｅアーキテクチャは、既存のホストソフトウェアへの追加又は修正を必要とすることなく、ＳＡＴＡ記憶をサポートするあらゆるシステムに利点を提供することができる。これは、ＳｔｅｅｌＶｉｎｅアーキテクチャを、ＢＩＯＳ、デバイスドライバ、ファイルシステム、ＯＳ、又はアプリケーションソフトウェアから独立させ、互換性テスト要件の一般的に大きな負担なしで導入できるようにする。また、高度記憶機能と、ＲＡＩＤハードウェアの配備に通常関連するホストシステムとの間の予測できず望ましくないタイプの対話についてのあらゆる機会が排除される。
【００３５】
この低レベルの抽象化で記憶機能拡張を導入する機能は、広範囲の利点を提供する。ＳｔｅｅｌＶｉｎｅアーキテクチャは、記憶インタフェース階層の最低レベルの１つ、すなわちブロックアクセスインタフェースに重点を置く。これよりも低いレベルは、ドライブの所与のタイプの物理インタフェースレイヤー、リンクインタフェースレイヤー、及びトランスポートインタフェースレイヤのみである。ドライブプロトコルのファミリー（例えばＳＣＳＩ）内には、多くの異なるサブプロトコル（例えば、Ｕｌｔｒａ３２０）、並びに物理、リンク、及びトランスポートインタフェースの多くの異なるタイプ（例えば、ＳＡＳ、光／銅ＦＣ、その他）がある。ディスクドライブの種々のタイプによって提示されるネイティブインタフェースには多くの相違点が存在し（このドライブのブロックレベルプロトコルの仕様もまたこれらの仕様とは大きく異なる可能性がある）、最新のディスクドライブによって提供されるブロックアクセスの一般的な抽象化は、ドライブの全てのタイプ間で共通のままである。
【００３６】
極めて一般的な意味で、現在普及している全てのディスクドライブは、以下の原理に従う読み取り／書き込みブロックセマンティクスの共通のセットを提供する。
イニシエータ（例えばホスト）が、選択されたターゲットデバイス（例えば物理ドライブ）にコマンドを送出する；
コマンドは、実行されるコマンドのタイプ（例えば、読み取り、書き込みなど）を指示する演算コード、開始ブロックのアドレス、及び開始に続くブロックが影響を受ける数のカウントを含む；
コマンドが読み取りオペレーションである場合、ターゲットデバイスは、所与のブロックアドレスから始まるドライブから読み取られるブロックの要求数で応答する；
コマンドが書き込みオペレーションである場合、ドライブに書き込まれるブロックの指示数（所与のブロックアドレスで始まる）が、コマンドに従うイニシエータによって提供されることになる。
【００３７】
詳細及び専門用語は異なるが、ブロックレベルインタフェースの一般的な性質は、包含されるドライブの種類に関わらず同じである。今日の最も一般的なドライブプロトコルは、ＳＣＳＩ及びＡＴＡとして公知である。これらのプロトコルは各々、ターゲットデバイス（例えば、論理ユニット番号（ＬＵＮ）対ターゲットポートアドレス）及び記憶ロケーション（例えばブロック番号対論理ブロックアドレス）を参照する異なる方法を有する。しかしながら、ＳＣＳＩとＡＴＡの両方は、ほとんど同様の方式で動作し、すなわち所与開始アドレスに基づいて固定サイズユニットのある所与の数（すなわちブロック又はセクター）の読み取り及び書き込みオペレーションを提供する。
【００３８】
ＳｔｅｅｌＶｉｎｅと他の記憶サブシステムアーキテクチャとの比較
ＳｔｅｅｌＶｉｎｅアーキテクチャの理解を助けるために、現在の主要な記憶アーキテクチャを調べてみる。記憶アーキテクチャの最も単純で最も一般的なタイプは、ダイレクトアタッチドストレージ（ＤＡＳ）として公知である。ＤＡＳでは、ディスクドライブが、ＨＢＡによって個々のホストに取り付けられている。複数のドライブを単一のＨＢＡポートに接続できるようにするこの手法には幾つかの変形形態（例えばマルチ−ドロップバス又はハブ／多重通信回路／スイッチを包含する）があるが、通常は、各ドライブがいずれかの時点で単一のホストに接続されていると言える。ＤＡＳモデルは、低コスト及び低い複雑度で記憶装置をホストに提供し、このコストは、ホストに取り付けられるドライブ、ケーブル、及びＨＢＡの数の関数であり、複雑度は、ＨＢＡのインストレーション（及びこれに必要なドライバ及びサポーティングソフトウェア）、及びＨＢＡの記憶ポートへのドライブの取り付けに関係している。１つよりも多いホストを含むシステムでは、この手法は、ストレージリソースが区切られていること、及び各ドライブが単一のホストにバインドされていることから生じる、利用度が乏しいという欠点がある。このような状況では、幾つかのホストが容量を取り過ぎ、他のホストは容量が少なすぎる可能性がある。唯一のソリューションは、追加のドライブを付加することである。しかしながら、ＤＡＳアーキテクチャにおけるドライブの追加又は移動は、ドライブの追加又は取り外しのためにホストを頻繁に終了させる必要があるので、複雑でコストのかかる（時間及び労力の点で）運用となる。これに加えて、ＤＡＳサブシステムの信頼性及び可用性は、要求よりも幾分低下する傾向にある。これは、いずれかのホスト、ドライブ、又はケーブリングハーネスの故障により影響されるドライブのデータへのアクセスが失われることになる事実に起因する。
【００３９】
記憶エリアネットワーク（ＳＡＮ）は、大規模企業システム用のＤＡＳアーキテクチャの欠点に対処するために開発されたものである。このアーキテクチャ法では、ドライブのコレクションを（ある程度）フレキシブルな方式でホストのセットに接続できるようにする専用記憶ネットワークが定義される（すなわち、ファイバチャネル（ＦＣ））。ＳＡＮでは、ドライブを細分し、これらの種々のパーティションを指定ホストに割り当てることができる。特定のホストが機能しない場合には、代わりのホストがドライブのセットを引き継ぐこともできる。このアーキテクチャは、ドライブ（及びその一部）をフレキシブルに（且つ幾らか動的に）ホストに再割り当てすることができる利点を有し、これによってＤＡＳアーキテクチャで可能になるよりも大きなデータの可用性及び高いドライブの利用度がもたらされる。しかしながら、ＳＡＮアーキテクチャは、記憶装置（ドライブ、ケーブリング、及びコントローラを含む）の価格と、記憶サブシステムのセットアップ及び管理の複雑さの両方の点でかなりのコスト負担をもたらす。
【００４０】
ＤＡＳ及びＳＡＮアーキテクチャの両方は、ブロックレベルで動作する記憶サブシステムである。しかしながら、ネットワークアタッチドストレージ（ＮＡＳ）として知られる次のアーキテクチャでは、ファイルレベルの抽象化により動作する。ＮＡＳアーキテクチャは、ドライブのコレクションに（一般的にＤＡＳアーキテクチャによって）接続され、ネットワーク（通常はローカルエリア）を介して他のホストへのファイルアクセスを提供するファイルサーバーとして動作するホストを含む。ＮＡＳアーキテクチャは抽象化の異なるレベルで動作するので、その特性（例えば、価格、性能、複雑さ）と本明細書で説明される他のアーキテクチャの特性との間で直接比較を行うことはできない。
【００４１】
最後に、ＳｔｅｅｌＶｉｎｅアーキテクチャが図５に示されており、ＤＡＳとＳＡＮアーキテクチャの両方で特性を共有している。ある意味では、ＳｔｅｅｌＶｉｎｅアーキテクチャは、「ＳＡＮ−イン−ア−ボックス」を提供し、ここで、ドライブのアレイによって表わされる記憶容量は、簡単で費用対効果が大きい方法でホストのセットに関連付けることができる。ＳｔｅｅｌＶｉｎｅアーキテクチャは、ＤＡＳアーキテクチャのコスト及び単純さのレベルでＳＡＮアーキテクチャの融通性と可用性を提供する。更に、ＳｔｅｅｌＶｉｎｅアーキテクチャは、記憶階層のブロックレベルに対処し、同様にＮＡＳアーキテクチャにおけるファイルサーバー要素の利点をもたらす。
【００４２】
本明細書では種々のＲＡＩＤレベルには対処されない点に留意されたい。これらは、記憶アーキテクチャを表わさず、記憶機能の拡張レベルを提供するための一連の記憶サブシステム実装技術を表わす。ＳｔｅｅｌＶｉｎｅアーキテクチャの幾つかの実施形態では、性能及び信頼性の要求されるレベルは、単純なブルート−フォース手段（例えば、パリティ−ＲＡＩＤではなくミラーリング）によって作成され、価格／性能目標を満足し、初期ＳｔｅｅｌＶｉｎｅ製品に対して選択された大容量のコスト重視のターゲット市場に関する要件を満たしている。当業者であれば、ＲＡＩＤ機能（例えば、パリティＲＡＩＤ）を実装するのに他の一般的な方法も使用できる点は理解されるであろう。
【００４３】
ＳｔｅｅｌＶｉｎｅアーキテクチャの例示的な実施形態
仮想ドライブが作成される元の物理ドライブを超える様々な（及び拡張された）特性を有する仮想ドライブが作成されるＳｔｅｅｌＶｉｎｅアーキテクチャの機能は、幾つかの種々のシナリオに応用され、単一のホストに接続された少数のドライブからホストの大きなセットに供するドライブの大きなアレイにまで及ぶことができる。この範囲の下端では、幾つかの（例えば２から４つの）２．５インチドライブを単一のＳｔｅｅｌＶｉｎｅ  ＳＳｏＣと組み合わせて、標準的な３．５インチドライブのエンベロープ内に収まり且つ単一のＳＡＴＡポート及び単一のパワー接続部を有するモジュールを作成することができる。物理的に単一の３．５インチドライブのように見えるが、このタイプのユニットは、信頼性の高い（すなわちトランスペアレントにミラーリングされた）ドライブ、或いは複数の仮想ドライブ（各々がサイズ、性能、及び信頼性に関して独自の専用特性を有する）を含む種々の特徴を提供することができる。同様に、複数の（例えば２から４つの）３．５インチドライブを組み合わせて、単一のＳＡＴＡ及びパワー接続部を備えたブリックにすることができる。
【００４４】
ブリックは、記憶アレイの種々の異なるタイプの構成で基本構築ブロックとして使用することができる。図６は、ブリックで作成することができる構造の種々のタイプの幾つかを示す。図６ａでは、４ドライブブリックが標準的なデスクサイドＰＣタワー内の単一の記憶ユニットとして使用されている。このアプリケーションでは、ブリックは、存在する仮想ドライブの数に関係なく、マザーボードへの単一のＳＡＴＡ接続のみを占有する。これは、ＳＡＴＡポートが制限された数で利用可能である場合に有利とすることができる。図６ｂは、同じ基本ブリックを独立型の外部構成で示している。このアプリケーションでは、ブリックは、その固有の筐体及び電源を有し、外部ＳＡＴＡ（ｅＳＡＴＡ）接続によってホストに取り付けられる。独立型ブリックはまた、アレイのアウトオブバンドモニタリング又は制御用の追加のインタフェース（例えば、ＲＳ２３２、ＵＳＢ、イーサネットなど）を有することができる。ブリックはまた、構成情報をブリックのＳｔｅｅｌＶｉｎｅ  ＳＳｏＣにロードするか或いはブリックのＳｔｅｅｌＶｉｎｅ  ＳＳｏＣからセーブすることを可能にするためのメモリ−デバイスポート（例えばコンパクトフラッシュ）を有することができる。
【００４５】
ＳｔｅｅｌＶｉｎｅアーキテクチャのスケーラビリティな特徴を利用して、幾つかのブリックを組み合わせて、図６ｃに示されるようなラックベースの記憶アレイ（シェルフとして知られる）にすることができる。この実施例では、４つのブリックが冗長電源のペアを共有し、各ブリックが、追加機能（例えば、パリティＲＡＩＤ、ＦＣ又はＳＣＳＩなどの別の記憶インタフェースへの変換、その他）を提供することができる中央コントローラに接続されている。シェルフのドライブは、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣを介して全て接続することができ、ｅＳＡＴＡ接続によって１つ又はそれ以上のホスト或いはコントローラに接続することができる。
【００４６】
最後に、図６ｄは、複数のシェルフが共に接続されて記憶ラックを生成する実施例を示している。この種類の記憶ラックは、各シェルフ内のドライブがどのようにＳｔｅｅｌＶｉｎｅコンポーネントに接続されるか、及びシェルフのコンポーネントがどのように相互接続されているかに応じて、様々な異なるトポロジーで構成することができる。極端な場合、全ラックが単一のＳＡＴＡ接続を介してホストに接続される場合もある。
【００４７】
記憶アレイコントローラコンポーネント
典型的なＰｏｌａｒｉｓベースの記憶サブシステムは、図１２に示されるように、エンティティの３つのトップレベルタイプ、すなわちホスト、記憶アレイコントローラ、及びドライブからなる。この図はまた、ＳｔｅｅｌＶｉｎｅベースの記憶サブシステムの作成を始めるトップレベルハードウェア及びソフトウェアコンポーネントを示している。図示するように、ホストハードウェアは、記憶アレイコントローラに接続する記憶相互接続リンクにホストの内部Ｉ／Ｏバスを接続するホストバスアダプタ（ＨＢＡ）のある形式を含む。
【００４８】
幾つかの記憶アレイコントローラは、その主記憶相互接続リンクに加えて接続をサポートする。これらのリンクは、単発的な使用（例えば、工場で、フィールドでの再構成用に、その他）を対象とすることができ、或いはこれらのリンクは、記憶アレイコントローラへの動的アクセス（モニタリング、コード更新、ポリシー入力など）を可能にする「長期的な」取り付けを提供することができる。発明者らは、これらの「アウトオブバンド」メカニズムを補足的相互接続リンクと呼ぶ。これらのアウトオブバンド通信チャネルは、種々の通信技術（例えば、イーサネット、ＵＳＢ、ＲＳ２３２、ＷｉＦｉなど）によって実装することができ、広範囲にわたる異なる通信プロトコル（例えば、ＨＴＴＰ、ＴＣＰ／ＩＰ、専用プロトコル、その他）をこの通信チャネル上で階層化させることができる。アウトオブバンドチャネルによって提供される同じ機能は、「インバンド」通信チャネルによって、すなわち一次記憶相互接続リンク（例えばＳＡＴＡ）内のサブチャネルを作成することによって提供することができる。
【００４９】
補足的通信リンクに加えて、記憶サブシステムはまた、「フロントパネル」として本明細書で知られるＩ／Ｏデバイスの外部アクセス可能なセットを提供することができる。フロントパネルは、単純なＬＥＤ及びスイッチＩ／Ｏから音声出力を備えた高精細カラーのタッチスクリーンＬＣＤまでのいずれかを提供することができる。アウトオブバンドチャネルと同様、フロントパネルは、ユーザに記憶サブシステムについての状態情報を提示することができ、構成及び管理目的のためにユーザからの入力を取得することができる。フロントパネルはまた、記憶アレイコントローラの構成及び状態情報をバックアップし復元するのに使用することができる取外し可能な不揮発性記憶インタフェース（例えばＵＳＢ、コンパクトフラッシュなど）の形式をユーザに提供することができる。
【００５０】
多様なアウトオブバンドインタフェース、並びに広範囲の異なるタイプのフロントパネルをサポートするために、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣの現世代は、外部マイクロコントローラへの簡単なインタフェースを含むように設計されている。要求されるアウトオブバンド通信リンク並びにフロントパネルの要求形式に対処するために、適切な外部マイクロコントローラを選択することができる。外部マイクロコントローラは、外部制御インタフェースを介してＳＳｏＣに容易にインタフェース接続する。以下に説明されるように、この種類の外部マイクロコントローラはまた、所与の記憶サブシステムに対するポリシーを実施するために使用することができる。
【００５１】
上記のこれらの機能の各々は別個のマイクロコントローラによって処理することができ、或いはこれらの機能の幾つか（又は全て）を共通のマイクロコントローラに組み合わせることができる点は留意されたい。簡単にするために、この議論では、発明者らは、要求される機能の全てに対処する単一の外部マイクロコントローラについて説明する。本明細書での実施例は、単一のＳＳｏＣを使用するが、ＳｔｅｅｌＶｉｎｅアーキテクチャは、コレクションのリソースの合計を有する単一のＳＳｏＣのほとんど同じ性能及び機能を備えた、複数のＳＳｏＣを組み合わせて単一の論理エンティティにすることも可能である。従って、単一のＳＳｏＣは、スケーラブルなコンポーネントのコレクションの単純化された表現（例えばＭｉｌｋｙｗａｙ）として使用することができる。
【００５２】
ハードウェアコンポーネント
記憶アレイコントローラハードウェアは通常、ホストの記憶リンクへの複数のドライブの相互接続を管理するコンポーネント、並びにドライブの構築されたコレクションの物理パッケージングに関する様々なアクティビティを管理する他のハードウェアユニットを含む。これらの物理ドライブパッケージングに関するアクティビティは、総称してエンクロージャ管理（ＥＭ）と一般に呼ばれ、ＬＥＤ制御、及びパワー、ファン、温度、その他のモニターなどの機能を含む。ＳｔｅｅｌＶｉｎｅベースの記憶アレイコントローラハードウェアは、主に（１つ又はそれ以上の）ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣからなり、エンクロージャ管理、ホストと記憶アレイコントローラとの間のアウトオブバンド通信、及びＳｔｅｅｌＶｉｎｅ  ＳＳｏＣ用の外部ポリシー論理を処理するための追加のマイクロコントローラを含むことが多い。
【００５３】
Ｐｏｌａｒｉｓ  ＳＳｏＣ内では、シリコンイメージ専用組み込みマイクロコントローラ（内部的にＰｉｃｏとして知られる）は、全ての初期化、制御プレーン、仮想化、及び外部インタフェース機能を実行する。Ｐｉｃｏ  ＣＰＵは、ハーバードメモリアーキテクチャ（すなわち別個の命令及びデータメモリ）を備えた高性能の低コスト組み込み３２ビットＲＩＳＣプロセッサである。命令メモリは、６４ＫＢのオンチップＳＲＡＭからなり、データメモリは、１６ＫＢのオンチップＳＲＡＭから構成される。Ｐｏｌａｒｉｓチップ上の種々の機能ユニットと通信するために、別個の制御レジスタアドレススペースが使用される。
【００５４】
Ｍｉｌｋｙｗａｙ  ＳＳｏＣは、スイッチ間リンク（ＩＳＬ）接続のセット、ハードウェアサポートルーティングレイヤ、拡張組み込みプロセッサ（すなわち、ＰｉｃｏＩＩ）、及び内部相互接続のためのクロスバー（バスとは異なる）の追加を含む、Ｐｏｌａｒｉｓの機能のスーパーセットを提供する。スイッチ間リンク（ＩＳＬ）ポート及びルーティングハードウェアによって、Ｍｉｌｋｙｗａｙ  ＳＳｏＣを組み合わせて、共通記憶サブシステム内にホスト及びドライブポートのより多くの数を含むようにＰｏｌａｒｉｓの機能をスケーリングできるファブリックにすることが可能になる。スケーラブル記憶アレイコントローラを作成するためのＩＳＬリンク及びその使用の更なる説明は、以下のセクションにおいて示される。
【００５５】
ＰｉｃｏＩＩは、ＳＳｏＣのＳｔｅｅｌＶｉｎｅファミリー向けに設計された第２世代組み込みコントローラであり、Ｐｏｌａｒｉｓに見られるＰｉｃｏＩチップに対する幾つかの改善点を取り入れている。ＰｉｃｏＩＩに含まれるＰｉｃｏＩに対する拡張には、４つのアドレスブレークポイントレジスタ及びシングル−ステッピングデバッグモード（両方ともｇｄｂベースのデバッギングをサポートする）の追加、ブランチ命令アラインメント制限の緩和、及び未使用（ロード及びローテート）命令の除去がある。これらの相違点に関わらず、ＰｉｃｏＩ及びＰｉｃｏＩＩの両方を同じツールチェーンがサポートする。
【００５６】
ソフトウェアコンポーネント
上記で定義されたハードウェアコンポーネントに加えて、Ｐｏｌａｒｉｓベースの記憶サブシステムは、多様な異なるソフトウェアコンポーネントからなる。トップレベルでは、システムのこのタイプの内部にソフトウェアの幾つかの別個のカテゴリーがあり、各々は、存在するシステム内のレベルによって区別され、実行される内部環境、及びソフトウェア自体の性質（例えば、並行処理の程度、リアルタイム、その他）によって制約が加えられる。ホスト内のソフトウェアのタイプは、以下のカテゴリー、すなわちデバイスドライバ、システムソフトウェア、及びアプリケーションソフトウェアに分解することができる。
【００５７】
デバイスドライバは、ＨＢＡハードウェアによって記憶リンクを管理し、ホスト内のより高レベルのソフトウェア用の記憶サブシステムの特徴及び機能へのアクセスを可能にするコードである。このコードは、標準的ＰＭとは異なるものであるＰｏｌａｒｉｓにほとんど気付くことはないが、Ｐｏｌａｒｉｓデバイスを完全に使用するためにデバイスドライバが理解することができるＰＭ仕様のレジスタセットへの幾つかのベンダー指定拡張が存在する。更に、デバイスドライバは、サブシステム生成事象を伝送する非ポーリングベース手段をサポートする必要がある。これは、記憶サブシステム内の状態の有意な変化（例えば、オン−／オフ−ラインになるドライブ、ＥＭ事象、その他）をホストソフトウェアが気付くことができるようになるために、メカニズムのｉｏｃｔｌタイプの何らかのコールバック又はブロッキングをサポートする必要があることを意味する。同様に、インバンド通信（すなわち、ＳＡＴＡリンクを使用する）を介してＰｏｌａｒｉｓサブシステムと通信することが必要である場合、デバイスドライバは、これに対してサポートを提供しなくてはならない（或いは、少なくともこれが起こるのを禁止しない）。これは（通常）、高度にＯＳ（及びバージョン）固有のカーネル−レベルのコードであり、カーネルプログラミングの十分な理解とシステムハードウェアの大部分の深い知識（ホスト、ＨＢＡ、Ｐｏｌａｒｉｓ、ＥＭ、及びドライブの知識を含む）を必要とする。この効率は、全体的なシステムレベルの性能に反映される。
【００５８】
システムソフトウェアは、デバイスドライバと対話する低レベルシステムコードからなり、直接ユーザ対話を含まない機能を実行する。例えば、記憶サブシステムをモニターし且つあらゆる異常な状態（例えば、ドライブ故障、温度又は電圧偏位、その他）をレポートするデーモンは、バックグラウンドで実行し、デバイスドライバにその関心を登録し、モニターされた事象のいずれかが起こったときに通知することができる。同様に、デーモンは、ポリシー事象（例えばドライブオン−／オフ−ライン遷移）を処理し、ある事前に定められたポリシー論理の実行に応答してＳＳｏＣ状態への更新を実施する（例えば、新しいドライブが追加されたときに、所与の論理ドライブの終わりにこれを連結する、或いはミラーセットの再構築オペレーションを開始する）ために存在することができる。この種のコードは、システムレベル（必ずしもカーネルレベルではない）プログラミングの知識、並びにＳｔｅｅｌＶｉｎｅベースのサブシステムの特徴及び機能の適度に深い理解を必要とする。これは、高性能又はリソース制約コードではない傾向がある。
【００５９】
アプリケーションソフトウェアは、ＯＳのトップで標準的なアプリケーションプログラムとして実行され、通常、直接のユーザ対話、例えば記憶サブシステムによって提供された機能へのユーザアクセスを可能にするグラフィカルユーザインタフェース（ＧＵＩ）又はコマンドラインインタフェース（ＣＬＩ）コードを含む機能を実行する。この種のコードは、記憶サブシステムの特定の技術的詳細のいずれかよりも人的要因の態様により重点を置くことを必要とし、ベースとなる機能がどのように抽象化されユーザに提示されるかに焦点を置く必要がある。このコードはリソースが豊富な環境で実行され、ここでは、人間の対話に関連したものが唯一の性能上の問題となる傾向がある。
【００６０】
記憶サブシステム内に存在するソフトウェアは、２つの広いカテゴリー、すなわちファームウェアとマイクロウェアに分けられる。
【００６１】
ファームウェアは、記憶サブシステム内のサポーティングマイクロコントローラ上で実行されるコードである。このコードは、ＥＭ、外部通信、及びＳｔｅｅｌＶｉｎｅポリシー機能といった事柄を実施し、ホストソフトウェアよりもリソースが限られ且つ性能に影響を受けやすい環境で実行される傾向がある。或いは、このコードは、上記のホストについて説明されたシステムソフトウェアと本質的に類似している。このコードは、標準的なリアルタイムオペレーティングシステム（ＲＴＯＳ）或いはカスタムランタイム環境で実行可能である。ほとんどの場合、ファームウェアは、記憶サブシステムにおいてハードウェアの低レベル操作を行うことになる。極端な場合、ファームウェアは、イーサネット接続を介してサブシステムへの外部（アウトオブバンド）アクセスを可能にするためにウェブサーバーなどのかなり高レベルの機能を提供することができる。しかしながら、該ファームウェアが低コスト／低性能のマイクロコントローラ上で実行しなくてはならないことにより、類似のホストベースのバージョンとは異なる方法でこのコードを書き込むことが必要となる。
【００６２】
マイクロコードは、ＳＳｏＣ自体の機能を実装するためにＳｔｅｅｌＶｉｎｅコンポーネント上で実行されるコードの特別なタイプである。ＳｔｅｅｌＶｉｎｅコンポーネントは、シリコンコンポーネント（すなわちＰｏｌａｒｉｓ）及びマイクロコードコンポーネントからなる。マイクロコードは、ＳＳｏＣのオペレーションに密接に関連し、従って、チップ自体の最深の詳細部分の掘り下げた知識を必要とする。マイクロコードは、高度にリソースが制限され且つ性能に影響を受けやすい環境で実行される。マイクロコードは、高度な同時処理を伴い、制約の全てを満たすように特別なコーディング考慮事項を観察する必要がある。一般には標準的なＲＴＯＳが本明細書では使用できないときに、カスタム実行環境の一部の形式がこのコードに対して提供されることが多い。
【００６３】
スイッチ間リンク（ＩＳＬ）相互接続ファブリック
ツリー又はメッシュトポロジーであるか否かに関わらず、共に接続された（すなわちカスケードされた）高度記憶デバイスは、類似の高度記憶デバイスに相互接続されたことを判定することができる。この判定は、特定のポート、スイッチ設定、プロトコル信号、その他の使用に基づいて行うことができる。この判定がなされると、コンポーネントは、標準ディスクインタフェースプロトコル（例えばＳＡＴＡ）以外の通信方法を利用することができる。１つのこのような通信方法がインタースイッチリンク（ＩＳＬ）プロトコルである。ＩＳＬの１つの実施形態では、１つよりも多いパスが送信側と受信側デバイスとの間に存在する場合、ＩＳＬを実装している高度記憶デバイスは、最も効率の良いパスを使用してメッシュによりメッセージを転送することになる。ＩＳＬプロトコルは、任意の相互接続トポロジー内で効率的なメッセージベースの通信を提供する。ＩＳＬネットワーク内では、各高度記憶デバイスは、ネットワークのノードとみなされ、一意のノードＩＤを与えられる。ＩＳＬは、ノード間で情報を運ぶフロー制御ユニット（又はフリット）と呼ばれる小さなユニットに各メッセージを分割する。各フリットは、１つのユニットで送られるが、メッセージに対する次のフリットは、受信側ノードにおける輻輳に起因して止められる場合がある。各ＩＳＬリンクは全二重通信であり、各方向は、２つ又はそれ以上の仮想チャネル（ＶＣ）に論理的に分割される。メッセージのフリットの全ては、いずれかの所与のリンクの単一のＶＣを使用することになる。１つのＶＣ上のメッセージはフロー制御によりブロックされるが、異なるメッセージは、別のＶＣを使用してリンクを介して開始することができる。１つの実施形態では、ＶＣの１つは、短いメッセージ用に確保される。初期化時間において、及びノードがネットワークに対して追加又は取り除かれたときに、ＩＳＬノードは、「フラッドルーティング」メッセージを交換する。これらのメッセージは、発信側ノードのＩＤと、メッセージが往来する「ホップ」（又は仲介）ノードの数を包含する。互いのノードに対して最小のホップカウントでメッセージが到着したリンクを記憶することによって、ノードは、ネットワークにおいて互いのノードにメッセージを送るための最適な出力リンクを特定することができる。この情報は、ルートテーブル内に記憶される。既に知られているものよりも劣るホップカウントを含む所与のノードによる後からのフラッドルーティングメッセージは廃棄され、転送されない。これは、ルーティングプロセスが迅速に終了することを保証する。別のノードまでの距離（すなわちホップカウント）が１つよりも多いリンク上で同じである場合、メッセージはリンクのいずれによっても送ることができる。これは、リンク間のロードシェアリングを実施するために使用される。各メッセージの第１フリットは、要求される宛先ノードのノード番号を含む。メッセージの第１フリットがノードに到着すると、該フリットを調べて、メッセージに対する要求宛先を判断する。宛先が受信側ノードである場合、メッセージ（第１フリット及び同じリンク上の同じＶＣ上の１つ又はそれ以上の次のフリットからなる）が、ノードによって受け付けられ、メッセージで指定された仮想ドライブに送信される。受信側ノードでない場合、ルートテーブルが照会され、宛先ノードにメッセージを転送するための最適な出力リンクが決定される。１つよりも多いリンクが使用可能である場合、使用されたものよりも未使用のもの、或いは最近使用されたものよりもあまり使用されていないものに優先権が与えられる。
【００６４】
バランススケーラブルコンポーネント設計
バランスサブシステムは、単一のリソースが通常使用の間に「ボトルネック」として顕著になることがないような方式で設定されるものとして定義される。ＳｔｅｅｌＶｉｎｅアーキテクチャによって対処される主な問題は、単一のコンポーネントを使用し且つバランスを維持することによって、広範囲のサブシステムサイズの生成を可能にすることである。ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣの一般化された抽象モデルは、リンクの種々のタイプ（例えば、ホストＳＡＴＡ、ドライブＳＡＴＡ、及びＩＳＬ）に対するポートの未定義の数を有する。しかしながら、リンクの各タイプの特定数の選択は、ＳｔｅｅｌＶｉｎｅコンポーネントの設計において重要な問題である。ポートの各タイプの数の選択に加えて、ＳｔｅｅｌＶｉｎｅ機能（例えば、仮想化、拡張、その他）の実装に専用のリソース量は、結果として得られるＳＳｏＣのコスト及び性能の主な決定要因である。ＳｔｅｅｌＶｉｎｅアーキテクチャは、ホスト及びドライブ接続の数を広い範囲にわたってコンポーネントタイプのわずかな数（理想的には１）に（独立して）スケーリングできるように定義された。
【００６５】
単一の低コストのコンポーネントによる高度なスケーラビリティをサポートするために、より大きなサブシステムに構成することができるアトミックユニットを作成することが必要である。このアトミックユニットは、ホストポート及びドライブポートの広範囲の種々の数を有する記憶スイッチを作成するための共通ビルディングブロックとしての役割を果たす。この手法は、未使用のポートを有するスイッチに対する追加コストが発生するか、或いは種々のサイズスイッチの各インスタンスに対して別々のＮＲＥチャージを生じるいずれかの選択肢よりも優れている。更に、適切に定義されたビルディングブロックユニットは、最小サブシステムに対する機能の基本レベルの全てを実行するのに必要なリソースの最小量を含むと同時に、より多くのユニットを組み合わせて次第に大きなサブシステムを作成するときに、結果として得られるサブシステムがバランスを維持する（すなわち、あらゆる所与のリソースタイプの不十分な量に起因したボトルネックが発生しない）のを保証する十分なリソースを含む。
【００６６】
スケーラビリティは、ファブリックによって達成され、バランスは、アトミックビルディングブロックに含まれるリソースの定義とこれらのブロックが結合されるトポロジーとの組合せによって達成される。超立方体の次元数は、実施可能なスケーラビリティの程度を定義する。フレキシブルなルーティングファブリックによって、相互接続トポロジーは任意とすることができ、あるものは他のものよりも優れているようになる。待ち時間及び帯域幅は、スイッチスケーラビリティの周辺の主要な問題である。ホップカウントは待ち時間を定める。帯域幅は、次元及びトポロジーによって定められる。Ｎ次元超立方体は、これが平均ホップ長を最小にし且つ均一な二重帯域幅を提供する（すなわち、ファブリックを二等分する場所に関わらず等価集約帯域幅を取得する）ので、理想的なトポロジーである。超立方体の次元は、ＩＳＬポートの数によって定められる。最悪の場合、全てのホストが、ホストのノードから最も遠隔のドライブにアクセスしようとし、よって各ノードは、そのローカルホストから来る（リモートノードに進む）トラフィックとローカルドライブから来る（リモートノード／ホストに進む）トラフィックを両方同時にサポートしなくてはならないようになる。
【００６７】
高度のスケーラビリティを達成するため、更にその価格／性能特性を最適化するために、ＳｔｅｅｌＶｉｎｅコンポーネントは、ホスト、ドライブ、及びスイッチ間リンク、並びに関連するリソースの「バランスの取れた」数によって構成される。ここではバランスコンポーネント設計は、ホスト／ドライブ対話をサポートするために単一のチップが十分な（帯域幅及びコンピューテーション）リソースを有するものであると定義され、追加のチップが付加されると、各追加チップは、サブシステム全体をバランスが取れた状態で確実に維持するのに必要なリソースを提供する。
【００６８】
ポリシーとメカニズムの分離
このようなシステムの設計において、ポリシー（すなわち行うべきこと）とメカニズム（すなわち、どのように行われるか）を分離することが良好な設計実践であることが多い。ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣは、これらの原理を念頭において設計されており、幾つかの異なる設計オプションをもたらし、その主なタイプが以下に説明される。
【００６９】
ＳｔｅｅｌＶｉｎｅベースの製品では、マイクロコードの主な機能は、他の低レベルメカニズムのセット（例えば、ディスク間コピー、外部通信、リモートアクセス、その他）と共に、基本機能ＳＳｏＣ（すなわち、仮想及びＲＡＩＤ特徴が付加されたＳＡＴＡ  ＰＭ機能）を提供するメカニズムを実装することである。このコードは、サブシステムの要求される「定常状態」オペレーションの全てを実施する。しかしながら、ある「例外」事象（例えば、ドライブ故障、オンラインになる新しいドライブ、オフラインにするドライブ、その他）が起こった場合、この事象に応答する方法に関する決定を行う必要がある。「ポリシー」コンポーネントは、これらの事象を処理し、これらの各々に応答して取るべき適切な措置を決定する論理であると定義されている。この論理は、ポリシーモジュールとして知られたコードで実施され、これは幾つかの異なるロケーションで実装することができる（図７に表示）。
【００７０】
組み込みポリシー
第１の実施例のオプションでは（すなわち図７ａ）、ポリシーモジュールは、ＳＳｏＣ自体内に組み込まれている。ポリシー事象が起こると、ポリシーモジュールが呼び出され、チップは、どのような外部エンティティに照会することなく、何を行う必要があるかをチップ自らが決定する。ポリシー決定プロセスへの外部入力だけが、チップ上の汎用入力ピンによって提供されたストラッピングオプションからもたらされる。これらのストラッピングオプションピンの設定に基づいて、種々の動作が同じポリシーモジュールから引き出すことができ、或いは全く異なる組み込みポリシーを選択することができる。
【００７１】
ポリシー論理は、ＳＳｏＣのマイクロコードにおけるメカニズムとは分離され、ポリシーモジュールとコアメカニズムとの間に明確に定義されたインタフェースが存在する。任意のポリシーモジュールをＳＳｏＣにロードすることができる（チップのコード−スペース及びデータ−スペースが許す限り）。ポリシーモジュールの実行は通常、時間優先ではなく、よって処理能力への関心が最小である（及びポリシーモジュールは、ＳＳｏＣ内の適切に低下させたプライオリティレベルで実行しなくてはならない）。
【００７２】
組み込みポリシーのこのタイプは、種々の事象に応答する方法に関する決定の根拠となるかなり静的な情報にのみ依存する可能性があるので、極めて単純なポリシーを実施するためにだけ使用することができる。性能制約、並びにコード及びデータサイズ制限は、広い範囲に及ぶ複雑なコンピューテーションを必要とするポリシーの実施を禁止することになる。実際にポリシーに関する持続的状態情報は、スペースが極めて制限される可能性のあるＳＳｏＣのＥＥＰＲＯＭ内に記憶される。
【００７３】
組み込みポリシーの使用は、最もコストの影響を受けやすいアプリケーションにおいて、最も単純でユニバーサルなポリシーだけに制限するのが最善である。これは、ポリシーモジュールが容易な追加及び除去に対してモジュール化されていても、ポリシーモジュールが変更される度に（異なるマイクロコードを表わすので）ＳＳｏＣを完全に再確認する必要があるためである。更に、可能な場合、外部エンティティ又はユーザへの照会を必要とするどのようなポリシーも、組み込み形式では実装されない可能性が高い。
【００７４】
ローカル外部ポリシー
ポリシーモジュールを実装するための第２オプションが図７ｂに示されており、ここでポリシーモジュールは、ＳＳｏＣ自体の外部（しかしローカル）にあるマイクロコントローラ内に実装されている。より複雑なポリシーは、より緩やかな（但し、完全に制約されていない訳ではない）リソース制約で実施することができる。極めて低コストのシングルチップマイクロコントローラ（例えばＰＩＣ）が存在するので、この手法の追加コストを極めて低くすることができる。この手法は、ポリシーなし（すなわち純粋なメカニズム）ＳＳｏＣの生産及び検証を可能にし、ここで、小さなコンポーネント（Ｉ２ＣベースＥＥＰＲＯＭに相当）を追加することによってカスタマイズされたポリシーを付加することができる。或いは、より高機能のマイクロコントローラを使用することができ、記憶サブシステムへの外部（アウトオブバンド）インタフェース、例えばイーサネット、ＵＳＢ、又はＲＳ２３２リンク、コンパクトフラッシュ又はＰＣＭＣＩＡカードインタフェース、ＩＳ０７８１６スマートカードインタフェース、又は８０２．*、もしくはＢｌｕｅｔｏｏｔｈ無線リンクのサポートを提供することができる。
【００７５】
ポリシーの選択又は構成は、外部インタフェースによって行うことができる。この手法は、ポリシーモジュールに関連した状態情報を記憶サブシステムの外部に記憶できるようにする追加の利点を有する。外部プロセッサ（特に、外部通信リンク又は半導体メモリデバイスインタフェースを備えるもの）は、「オフ−サイト／リモート」ロケーションに対する重要状態をバックアップする手段を提供することができる。これは、ポリシープロセッサが交換される場合にドライブがアクセス不能にならないようにする。
【００７６】
外部ポリシーコントローラは、ユーザ介入なしに全ての実施可能な事象を処理できる、すなわち入力をユーザに要求することなく適切な事柄を実施するように構成されている。これは、多くの事象に対して、極めて単純化されたブルート−フォース又は最悪ケースタイプの動作を取る必要があることを意味する。例えば、システムに新しいドライブが現れたときに行うべきことに関する質問には、例えば、事前に定義された論理ドライブに決定論的な方法で新しいドライブを常に分散させる、新しいドライブを「フリープール」に割り当てる、ユーザ指示構成を待機する、その他など、状況に関わらず適切に動作する単純な応答によって答えなくてはならない。
【００７７】
ホストベースのポリシー
最後に、図７ｃに示されるオプションは、ポリシーモジュールがホストに実装されるケースを表わしている。任意の複雑な（及びステートフルな）ポリシーは、この手法によって実施することができ、同様にポリシーは人間との対話を必要とする。
【００７８】
このオプションは上記に定められたローカル外部ポリシーの実施例と同等とすることが可能であり、ここでホストは、ローカルマイクロコントローラに代わってポリシーモジュールを実行する。この場合、ホストベースのポリシーモジュールは、「デーモン」プロセス、すなわちユーザに可視のどのような表示もすることなく、ホスト上で実行されるアプリケーションと呼ぶことができる。ホストは、ローカル外部ポリシーケースにおいてポリシープロセッサと置き換わることができ、ホストデーモンと同じポリシーコンピューテーションを実行することができる。デーモンは、ホスト上にセットアップされ、サイレント実行され、記憶サブシステムからの事象に応答し、更新をＳＳｏＣの状態に送る。どのようなユーザ入力もなしにデーモンとしてホスト上で実行される完全に事前定義されたポリシーモジュール、或いはユーザ定義構成ファイル、ＣＬＩ、又はＧＵＩから構成され駆動されるポリシーモジュールを有することができる。
【００７９】
記憶サブシステムからの事象に応答して取るべき適切な動作を決定するために、ユーザに照会する必要のある多くの状況がある。上述されたデーモン手法（定常状態オペレーションでユーザとどのような対話も伴わないもの）に加えて、ポリシー決定プロセスにおいてユーザを関与させるポリシーを有することができる。ループ中に人間を含む（ｍａｎ−ｉｎ−ｔｈｅ−ｌｏｏｐ）ポリシーモジュールを作るために、ＣＬＩ及びＧＵＩベースの両方のアプリケーションを作成することができる。これらのアプリケーションは、記憶サブシステムからの事象を処理し、ユーザとの対話を生成し（例えばポップ−アップウィンドウを介して）、更に記憶サブシステムの状態を更新する。
【００８０】
記憶サブシステムとそれらのホストベースのポリシーモジュールとの間の対話は、インバンド（すなわちＳＡＴＡリンクを使用する）又はアウトオブバンド（すなわち、イーサネット、ＵＳＢ、ＲＳ２３２、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、その他などの何らかの補助接続を使用する）通信リンクによって実施することができる。外部ポリシーモジュールと通信するために使用されるプロトコル及びインバンド対アウトオブバンド通信リンクの使用は、以下のセクションで更に詳細に説明する。
【００８１】
ポリシー実施選択
ポリシーを実施するために上記のオプションのどれが使用されるかに関わらず、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣメカニズムとそのポリシーモジュールとの間のインタフェースは、論理的に同じ状態のままである。ＳＳｏＣメカニズムによって生成された事象（通常ドライブの出入りに関連するもの）は、ポリシーモジュールに進む。次いで、ポリシーモジュールは、ある論理を実行し、どの動作（通常ＳＳｏＣの仮想化テーブルを更新することを包含する）を応答で実行する必要があるかを判断する。これらの動作は、更新メカニズムを使用してＳｔｅｅｌＶｉｎｅ  ＳＳｏＣに適用される。
【００８２】
上述された３つのオプションに加えて、ＳｔｅｅｌＶｉｎｅベースの記憶システム用のポリシーモジュールを実装するために多様な複合ケースが存在することは注目すべきことである。例えば、ホストではない非ローカルマイクロコントローラを使用することができる。ＳｔｅｅｌＶｉｎｅ記憶装置を包含する大きなシステムには複数のホストが存在することができ、単一のホストは、より大きなシステムにおけるＳＳｏＣの各々に対してポリシー機能を実行すると仮定することができる。
【００８３】
上記に定められたオプションの各々（及び種々のハイブリッド選択）は、別の利点、コスト、機能、及び制限を有する。第１オプション（組み込みポリシー）は、シングルチップソリューションに関連した単純さ及び低コストの利点を有する。この手法によって多くの有用なポリシーを実施することができるが、これは、オプションの最も制限されたものである。第２オプション（ローカル外部ポリシー）は、シングルチップ手法よりもわずかに多いものからホストベース手法よりもわずかに少ないものまで、種々のコストの相応した大きな範囲で幅広い機能を提供する。外部ポリシーモジュールが他の機能（例えばエンクロージャ管理及び外部インタフェースプロセッサ）に使用されるマイクロコントローラ上に「ピギーバック」することができることにより、この手法が望ましいオプションになる。第３オプション（ホストベースのポリシー）は最も費用対効果の大きい（ホスト内に既に存在するリソースを利用する）ものと考えられるが、このオプションには重大な欠点がある。ホストベースのポリシーソリューションは、あらゆるホストと協働し且つ定められた機能を実施するのにユーザ介入を必要としない使い易いアプライアンスであるように見える記憶サブシステムを作成する目的に反するものである。ホストベースの手法は、ホスト上でソフトウェアをインストールする必要があり、該ソフトウェアはＯＳの多くのバージョンで使用するように作成し確認しなければならない。この手法はまた、小さな組み込みコントローラよりもユニット当たりで遙かに高価になる傾向があるホストリソースを消費する。更に、ホストの交換がポリシー／構成情報の損失を生じる場合、データへのアクセスが損なわれる可能性がある。
【００８４】
ＳｔｅｅｌＶｉｎｅ  ＳＳＯＣの特徴
ＳｔｅｅｌＶｉｎｅアーキテクチャの多くの異なる実現が存在する可能性があるが、アーキテクチャの中心を占めるコンポーネントは全て、共通の特性セットを共有し、共通の特徴セットを利用する。ＳＳｏＣのＳｔｅｅｌＶｉｎｅファミリー全体の一般的な特徴セットは、このセクションで定義され、特定の実施によって具現化される特徴のサブセット（Ｐｏｌａｒｉｓ及びＭｉｌｋｙｗａｙハードウェアに基づく）は、以下のセクションで説明される。
【００８５】
ホストの観点から、ＳｔｅｅｌＶｉｎｅコンポーネントは、物理ドライブ、或いは標準的なポートマルチプライヤの後の物理ドライブのセットのいずれかであるように見える。ホストに提示されているこれらのドライブは、（必ずしも）実在の物理ドライブではなく、実際には仮想ドライブである。これらは、仮想ドライブが作成される元の物理ドライブのプロパティとは異なる可能性のある付加的な（有利な）プロパティ（例えば、サイズ、速度、及び信頼性）を有するドライブとしてホストに見える。ＳｔｅｅｌＶｉｎｅコンポーネントの主な機能は、何らかの（静的又は動的に変更可能な）構成データと共に明確に定義されたルールセットに従って、利用可能な物理ドライブのセットに基づく仮想ドライブを作成及び維持することである。
【００８６】
ホストは、該ホストに提示されている仮想ドライブが実在の物理ドライブ（定義された付加的なプロパティを有する）でないことを検出することは（原理的に）できないはずである。この錯覚は、種々の実用的な目的のために無視される場合があるが、そうでなければ、全ての意図及び目的において、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣによって作成された仮想ドライブは、物理ドライブと区別することはできない。同様に、極めて劣化したケースでは、ＳｔｅｅｌＶｉｎｅコンポーネントは、標準、ダム、ＳＡＴＡポートマルチプライヤの機能と同一の機能を提供するよう構成することができる。
【００８７】
仮想ドライブの抽象化は、ホスト生成ＳＡＴＡコマンドストリームに対し変換を実行することによって作成される。これらの変換は、単純なテーブル−ルックアップオペレーションによって大部分実施することができ、ここで仮想ドライブに送られるコマンド（すなわち仮想コマンド）は、迅速且つ容易に１つ又はそれ以上の物理ドライブ上で（場合によっては複数の）コマンド（すなわち物理コマンド）に変換することができる。幾つかの場合には、変換は、コマンドの値の置換（例えば、ターゲットドライブ及び開始セクター）によって簡単に行うことができる。他の場合では、複数の物理コマンドは、例えば連結された物理ドライブにわたるため、及びミラーリングされたセットに対する書き込みを複製するためなど、単一の仮想コマンドに応答して生成される必要がある。前者の場合、簡単なテーブルルックアップ機能を使用して、仮想コマンドから物理コマンドへの変換を行うことができる。後者の場合、要求されるフォーク／ジョインタイプのオペレーションを行い、種々の例外条件（例えばドライブ故障、コマンド再試行、その他）を処理するために、実行される何らかの追加の論理があるはずである。
【００８８】
複数の仮想ドライブのサポートは、ポートマルチプライヤ仕様によって提供されたアドレス指定メカニズムを利用することによって達成される。極めて高レベルの観点から、ホストによって送出されたＳＡＴＡコマンドは、実行されるオペレーションのタイプを定義するパケットと、これに加えて所与のオペレーションを実行するのに必要な引数とからなる。コマンドの多くの異なるタイプが存在するが、関心のある主なものは、一連のディスクブロック（セクターとしても知られる）に対して読み取り又は書き込みオペレーションを実行するものである。通常の読み取りオペレーションは、引数として開始ブロックアドレス（通常、論理ブロックアドレス（ＬＢＡ）として知られる４８ビット値）と読み取られるブロック数とを有する。ホストは、このコマンドをドライブに送り、要求されるデータブロック（ディスク上の所与のロケーションからの）が戻される。同様に、書き込みオペレーションは、同じアドレス及びカウント引数を有するが、ディスク（ディスク上の所与のロケーション）に書き込まれるデータブロックを更に含む。これに加えて、ＳＡＴＡポートマルチプライヤ仕様は、最大１４個の異なる物理ドライブのどれが所与のコマンドのターゲットになるかを選択する追加の引数を含めることを可能にする。仮想ドライブを作成するために、ＳｔｅｅｌＶｉｎｅコンポーネントは、所与の仮想ドライブを定義する変換情報を選択するためにターゲットドライブ数を使用し、この情報に基づいて、適切な物理ＬＢＡ及びブロックの数を有する１つ又はそれ以上の物理コマンドを生成する。読み取り／書き込みデータは、これらの変換の一部としては修正されない。この仮想対物理コマンド変換の実施例が図８に示されている。ターゲットＩＤは、どのテーブルを使用するかを選択し、開始ＬＢＡ及びブロックカウント引数は、どのテーブルエントリが特定のコマンドを仮想化するのに使用されるかを定義する。
【００８９】
ＳｔｅｅｌＶｉｎｅコンポーネントの結合
ＳｔｅｅｌＶｉｎｅアーキテクチャは、ＳｔｅｅｌＶｉｎｅデバイスを「カスケード」する機能を提供し、単一のホストポートから多数の物理デバイスへのアクセスを可能にする。
【００９０】
ＳＡＴＡＩＩポートマルチプライヤ仕様は、４ビットのターゲットアドレス指定を提供し、最大１５個の物理ディスクドライブまでのアクセスを可能にする。本仕様は、ポートマルチプライヤをカスケードできないことを明確に記載している。この制約に対する理論的根拠は、より低いレイヤのデバイスへのディスクアドレス指定を拡張するメカニズムが存在しないことである。しかしながら、ＳｔｅｅｌＶｉｎｅの仮想化機能を使用して、この限界を克服することができる。例えば、ホストを単一のポートマルチプライヤ（ＳＡＴＡＩＩ仕様に従って実装される）に接続することができ、ここでポートマルチプライヤの各ドライブポートは、単一の仮想ディスクを実装するＳｔｅｅｌＶｉｎｅデバイスに接続される。ＳｔｅｅｌＶｉｎｅデバイスの下には、ポートマルチプライヤに単一の仮想ドライブを提示するために仮想化（例えば、連結、ストライピング、その他）された幾つかの物理ドライブが存在することができる。このようにして、ポートマルチプライヤ仕様の単一のレベルが克服される。
【００９１】
上記の実施例における低いレベルのＳｔｅｅｌＶｉｎｅデバイスは、代わりに、追加のＳｔｅｅｌＶｉｎｅデバイスに接続することができ、これらは、幾つかのより多くの物理ドライブを仮想化し、同様に単一の仮想ドライブを上記のデバイスに提示する点に留意されたい。ある意味では、上位ＳｔｅｅｌＶｉｎｅデバイスは、下位のＳｔｅｅｌＶｉｎｅデバイスによって提示される他の仮想ドライブから構成される新しい仮想ドライブを作成している。このようにカスケードすることができるＳｔｅｅｌＶｉｎｅデバイスのレイヤ数に事実上制限がないことは明らかである。単純なポートマルチプライヤ（すなわちポートマルチプライヤアウェアでない）と通信できないホストに対して、トップレベルデバイスはその代わりに、単一の仮想ドライブのビューを接続ホストに提供するＳｔｅｅｌＶｉｎｅデバイスになることができ、すなわち、トップレベル単純ポートマルチプライヤを使用することができるが、本ケースでは必要ではない点に留意されたい。
【００９２】
ＳｔｅｅｌＶｉｎｅデバイスの各レイヤが、アクセスできる物理ドライブの数を指数関数的に増加させるので、ホストに取り付けることのできる物理ドライブの数には事実上制限がない。しかしながら、使用可能なカスケードの深さには実用上の制限がある。例えば各レイヤは、追加の待ち時間が導入されることに起因して、全体の性能がわずかに低下すると予想される。
【００９３】
物理ドライブのセットが仮想化されると、実施された変換の基本的且つ重要な部分は、仮想ドライブにコマンドで送られた論理ブロックアドレス（ＬＢＡ）の一部分を用いて、データが始まるより低位のドライブ又は構成ドライブ（物理ドライブ又はカスケードされた仮想ドライブのいずれか）を選択し、ＬＢＡの残りの部分を用いて、コンポーネントデバイス内のロケーションを選択することである。すなわち、仮想化によって、ＬＢＡの一部は、ディスクアドレス指定のための追加ビットを提供することができるようになる。これは、ＳＡＴＡＩＩポートマルチプライヤ仕様に固有の４ビットアドレス制限をカスケード化が克服する手法である。
【００９４】
機能性の論理レイヤ
ＳｔｅｅｌＶｉｎｅアーキテクチャは、物理デバイスのセットからの仮想ドライブの作成に加え、かなりの機能性を提供する。拡張仮想ドライブ機能（例えば速度及び信頼性の向上）をもたらすのに必要な特徴部、及び単一のＳＳｏＣによって提供されるものを超えるドライブ及びホストの数をスケーリング可能にするのに必要な特徴部が、基本的ＳＡＴＡポート−マルチプライヤのような機能及び上記に定義された単純な仮想化に加えて設けられる。図９は、標準のＳｔｅｅｌＶｉｎｅ  ＳＳｏＣを示し、この外部インタフェースは、（１つ又はそれ以上の）ホスト、幾つかのドライブ、及び場合によっては他のこのようなＳＳｏＣ（単一のチップによってサポートされるホスト及びドライブの数を超えてスケーリング可能にするため）に接続する幾つかの高速ポートからなる。
【００９５】
ＳｔｅｅｌＶｉｎｅアーキテクチャの完全な特徴セットを論理的に独立したレイヤのセットとして以下に定義する。図９に示される機能の論理レイヤは、機能に対する階層、並びに各機能が存在する抽象化の相対レベルの使用の両方を提案する編成で表示されている。（これらのレイヤは、必ずしも別個の機能として実装される必要はなく、ひいてはこれらの特徴の全てが特定の製品に存在しなければならない訳ではない。）
【００９６】
以下のサブセクションでは、標準のＳｔｅｅｌＶｉｎｅコンポーネントの種々の論理機能を説明する。これらの機能は、ＳＡＴＡドライブをサポートするのに必要なメカニズム、多数のリモートドライブへのアクセス（ＳｔｅｅｌＶｉｎｅコンポーネントのコレクションから作られたファブリックを介して）を可能にする特徴、基本的な仮想対物理変換のための論理（すなわち、物理ドライブの領域から仮想ドライブを作成する）、仮想ドライブの特性の追加拡張（例えば速度又は信頼性）を提供するメカニズム、仮想ドライブを特定のターゲットＩＤ（所与のホストに対する）にマッピングするためのメカニズム、及びＳＡＴＡプロトコルから他の（場合によってはより高いレベルの）プロトコルへの変換を可能にする特徴を含む。
【００９７】
ＳＡＴＡレイヤ
幾つかの実施形態では、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣの主な外部インタフェース接続（すなわちホストポート及びドライブポート）は、全てＳＡＴＡインタフェースであり、この理由のために、ＳｔｅｅｌＶｉｎｅコンポーネントアーキテクチャの第１論理レイヤは、ＳＡＴＡインタフェースをサポートする段階を包含する。ＳＡＴＡＩ仕様のＳＡＴＡの物理レイヤ、リンクレイヤ、及びトランスポートレイヤによって定義された基本機能に加え、このレイヤは、ＳＡＴＡＩＩ仕様で定義されたネイティブコマンドキューイング（ＮＣＱ）プロトコル、並びにＳＡＴＡポートマルチプライヤ仕様で定義された特徴部に対するサポートを提供する。
【００９８】
ＳｔｅｅｌＶｉｎｅコンポーネントにはＳＡＴＡインタフェースの２つのタイプ、すなわちターゲット（すなわちホスト）ポートとイニシエータ（すなわちドライブ）ポートとがある。前述のように、ＳｔｅｅｌＶｉｎｅアーキテクチャは、１つのコンポーネントに含まれるリンクの各タイプの幾つかを選択する際のバランスを取るよう努める。これより以上では、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣのＳＡＴＡポート間に更なる区別は存在せず、タイプＳＡＴＡポートの各々は機能上同等でなくてはならず、ポートの特定のタイプの個々のインスタンス間には特殊化又は区別がないはずである。詳細には、ＳＡＴＡポートマルチプライヤ仕様が物理ドライブポート０の特別な処理を要求する場合（レガシーブートオペレーションをサポートするため）でも、ＳｔｅｅｌＶｉｎｅコンポーネント上の物理ドライブポート間に差異があってはならない。仮想化及びマッピング機能（以下で説明される）によっていずれかの物理ドライブを使用して仮想ドライブ０を作成することが可能となるので、これは必要なことである。
【００９９】
物理、リンク、及びトランスポートサブレイヤ
ＳｔｅｅｌＶｉｎｅコンポーネントに対して行われるハードウェア／ソフトウェア実装のトレードオフは、適切なポリシー／メカニズム分離の原理によって大きく影響を受ける。これらのガイドラインは、データパケットがある種のプロセッサ上で実行されるソフトウェアによって制御される手法を提案しているが、データ自体は、専用ハードウェアを介して流される。この手法は、データプレーン（すなわち、高性能、低レベル、データ移動メカニズム）を制御プレーン（すなわち、高いレベル、制御指向論理、より長い時間定数を有する、更にこれによって性能制約があまり厳しくない）と分離する。ここで取り上げるハードウェア／ソフトウェアトレードオフ手法は、ＳＡＴＡ物理、リンク、及びトランスポートレイヤの標準化された特徴の全てを実装するためにハードウェアメカニズムを設ける必要があると提案している。
【０１００】
これは、可能な限りハードウェアメカニズムがＳＡＴＡ仕様で定義された論理（すなわち状態機械）を実装し、標準的な方式でホストポート及びドライブポートが機能できるようにすることを意味する。しかしながら、種々のポリシーをこれらのメカニズムに適用できるようにするために「フック」が存在しなくてはならない。種々のＳＡＴＡポートが種々の標準的ＳＡＴＡ事象（例えば、初期化、アイドル、パワー管理、裁定、その他）に対する適切な応答を自動的に生成できる必要があるが、同時に、マイクロコード定義のソフトポリシー論理は、所与のポリシーに一致する方式で事象を検出、応答、及び生成する。これは、例えば、ハードウェアがＳＡＴＡパケットにおけるＣＲＣエラーを自動的に検出するメカニズム（すなわちＦＩＣ）を提供するのが適切である場合、例えば、即座にエラープリミティブを送る、事象をログする、及びＦＩＳをパスする、その他など、このような事象に応答して取るべき動作を決定するためにインプリメンテーションのポリシー部分次第のはずである。
【０１０１】
これは、メカニズムが、事象の発生する度に信号を単に生成し、ソフトウェアに任せてこれを処理する抽象化の低いレベルで設計しなくてはならないことを意味するものではない。そうではなく、適切なハードウェア／ソフトウェアトレードオフによって、ソフトウェアは、共通のポリシーケースに対して幾つかの事前に定義された（標準的な）動作を選択し、標準的でないケースに対して、すなわちＳＡＴＡ仕様で定義された動作に一致しないポリシーが実施される場合にはソフトウェア定義論理に逃れることができる。適切なメカニズム設計は、ポリシー選択をその既知の優先度だけに制限するだけでなく、機能的ビルディングブロックのセットから広範囲な種々の動作を構成できるようにする。このような設計手法の目標は、ポリシー決定を侵害することなく定義されたメカニズムの抽象化レベルを最も高い可能レベルまで高めることであり、すなわちハードウェアがメカニズムの使用範囲を制限するポイントまで、ハードウェアにおいてできる限り特徴機能の多くを具現化しようとすることである。
【０１０２】
これらの設計原理を維持しながら、入力ＦＩＳの多重分離化がハードウェアメカニズムにおいて処理され、例えば仮想ドライブに送られるＦＩＳをポートマルチプライヤ制御ポート、又は記憶エンクロージャ管理ブリッジに送信されるものと区別することは全く適切である。同様に、ソフトウェアが「標準的」動作を無効にする、例えば、自動ネゴシエーションフェーズの結果がどうであったに関わらずリンク速度を強制的に所与のレートにすることを可能にする機能によって、低レベルリンク機能（例えば、リンク速度の自動ネゴシエーション、アイドル生成、リンク裁定、パワー管理）をハードウェアで処理しなくてはならないことは適切である。また、ハードウェアメカニズムがドライブポートのためのシャドーレジスタ及びサポーティング論理を実装することは適切である。
【０１０３】
ＳＡＴＡメカニズムにより種々のポリシーを適用可能にする場合の実施例は、リンクレベル肯定応答がどのように処理されるかに関するものである。ＳＡＴＡポートマルチプライヤ仕様は、リンクレベル肯定応答をドライバによって行い、ＰＭを通してトランスペアレントに渡さなくてはならないが、性能最適化をホストパケットの推論的肯定応答を介して（適切なＣＲＣによって）達成できることを示している。この最適化は、特定の状況に適用することができ、ポリシー論理を遂行して、これを行う適切な時間、及び行うべきではない時間を判断する。
【０１０４】
別の実施例は、ホストとドライブとの間のパケットのキューイング又はバッファリングに適用されるポリシーを包含する。ドライブがサポート可能な速度よりも高速でホストリンクを動作可能であると仮定すると、ホストリンク利用度は、ドライブとホストとの間で直接接続が行われる場合に低下する可能性がある。ホストリンクは、可能な３Ｇｂｐｓの代わりに１．５Ｇｂｐｓの有効速度で動作することができる。ホストリンク利用度（ＳｔｅｅｌＶｉｎｅベースのシステム内の重要な性能制限のあるメトリックとすることができる）を改善する代替の手法は、ドライブからのＦＩＳのバッファリング段階、次いでホストにフルスピードでこれを送る段階を包含する。この技術は、幾つかの状況（すなわち、同じホストリンクを通じて１つよりも多いドライブがアクセスされる場合）でホストリンクのスループットを向上させると同時に、増加した待ち時間（単一のドライブのみにアクセスする場合にスループットを低下させる）の代償としてこれを行う。従って、これはバッファリングを行わなくてはならないとき（又は場合）のポリシー決定になる。ベースとなるハードウェアメカニズムは、所与の時点でポリシーモジュールによって行われる選択が何であれサポートをする。
【０１０５】
ポートマルチプライヤ
ＳＡＴＡＩＩポートマルチプライヤ（ＰＭ）仕様は、１つよりも多いターゲットデバイスを単一のイニシエータのリンクに接続できるようにする単純なアドレス指定方式を定義する。これは、複数のドライブを単一のホストポートに接続できるようにするものであり、３ＧｂｐｓのＳＡＴＡＩＩ帯域幅及び現在（ボリューム）のドライブの帯域幅（その読み取りヘッドチャネルは持続帯域幅の７００Ｍｂｐｓよりもかなり低く提供する）の場合に妥当である。
【０１０６】
ＰＭ仕様は、ハブ又はマルチプレクサ構成の標準的なソートで特定のドライブを選択するのに使用されるアドレス（ターゲットＩＤとして公知）のＦＩＳヘッダにおいて４つの予備ビットを定める。ターゲットＩＤフィールドは、最大１６の異なるターゲットの１つを選択するのに使用される。ＰＭは、単一のホストポートを有し、０からＮ−１までの（連続した）番号が付けられた最大１４個のドライブポート（ここでＮは、ＰＭインスタンスによって提供されるポートの総数）として定義される。ターゲットＩＤ０は、レガシー互換性を実施するのに使用される点で固有である。これは、ポート０に接続されたドライブが、ホストコントローラがＰＭアウェアでない（すなわち、ＦＩＳヘッダにおけるターゲットＩＤに気付かない、又は選択できない）場合でも、回転数を上げブート可能になることを意味する。ターゲットＩＤ１５は、ＰＭ自体とトークするのに使用されるポートと定義される。このポートは、３２ビット値としてアドレス指定及び読み取り／書き込みすることのできる（標準的な並びにベンダー定義の）レジスタのセットへのアクセスを提供する。
【０１０７】
もう１つのターゲットＩＤは、記憶エンクロージャ管理ブリッジ（ＳＥＭＢ）機能用のアドレスとして使用するために取り置くことができる。このアドレスは通常、ＰＭによってサポートされる物理ドライブの最大数のアドレスよりも１つ大きい（すなわち、ターゲットＩＤ  Ｎ＋１）ものである。この機能は、ブリッジとして働き、ホストとＰＭに接続された記憶エンクロージャプロセッサ（ＳＥＰ）との間でコマンド及び応答をトランスペアレントに転送する。
【０１０８】
ＳＡＴＡホストコントローラは、ＰＭアウェア（ＦＩＳヘッダ内の非ゼロターゲットＩＤフィールドを生成し応答できることを意味する）、或いは非ＰＭアウェア（ＦＩＳターゲットＩＤフィールドにゼロを入れるか、或いはこれを無視することを意味する）のいずれであってもよい。ＳＡＴＡホストコントローラはまた、コマンドベースのスイッチング、又はＦＩＳベースのスイッチングをサポートすることができる。コマンドベースのスイッチングは、ある時間において所与のターゲットデバイスへ１つのコマンドだけの送出を包含する。コマンドが終了した後でのみ、ホストは、新しいコマンドを別のターゲットに送出することができる。この手法はあまり高価でない（より単純で実装するのにリソースをあまり必要としないので）が、達成できる同時処理量が制限され、よって記憶サブシステムの性能を制限する。ＦＩＳベースのスイッチングでは、ホストは、種々のターゲットへの複数の未処理のコマンドを有し、未処理のコマンドを有するターゲットのいずれかから応答ＦＩＳが来ることに対処することができる。これは、各未処理コマンドに対して別個のコンテキストを維持し、応答を適切なコンテキストに関連付ける（「タグ付け」メカニズムにより）ことによって行われる。この手法は、付加的なハードウェアコスト及びホストコントローラにおける複雑さを代償として、より高いシステム性能もたらす。ホストコントローラがコマンドベース又はＦＩＳベースのスイッチングを実施するかどうかは、ＰＭ準拠デバイスには明白である。コンテキスト及びタグ付けの概念は、以下のＮＣＱのセクションで更に詳細に説明する。
【０１０９】
ＳｔｅｅｌＶｉｎｅコンポーネントは、仮想ドライブを選択するためにＰＭ仕様のアドレス指定特徴を使用する点に留意されたい。ＳｔｅｅｌＶｉｎｅコンポーネントはまた、（ターゲットＩＤ１５）ベンダー定義レジスタ、並びにＳＥＭＢ機能を使用することができる。これらのＰＭ特徴は、ＰＭ仕様の（精神でない場合）字義に合わせ、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣの固有の特徴をサポートするのに使用される。
【０１１０】
ネイティブコマンドキューイング（ＮＣＱ）
ＳＡＴＡベースシステムの性能に重大な影響を与える可能性のあるＳＡＴＡ仕様の別の特徴は、ネイティブコマンドキューイング（ＮＣＱ）として公知である。この特徴は、他の記憶インタフェース（例えばＳＣＳＩ）にも見られ、ある時点で所与のドライブ上で複数のコマンドが未処理であることを許容することを含む。これは、ドライブによるコマンド実行が厳密に同期する必要がないことを意味し、ホストは、これまで送出した全コマンドが終了する前に追加のコマンドをドライブに送出することができる。ＮＣＱは、コマンドがドライブで受け取った順序とは異なる順序でドライブにより実行することができることを示す。ＮＣＱの利点は、多くの側面があり、コマンド送出及びコマンド応答をオーバーラップさせることによる処理性能の向上を含み、これによって待ち時間を隠すことが可能となる（結果としてビジー記憶サブシステムの全体的なスループットを向上させる）。加えて、ドライブがある時間に１つよりも多いコマンドにアクセスすることができることは、ドライブが、要求されたシークオペレーションに対するプラッタの現在の回転位置についての知識が増大したことに基づいて、より効率的なディスクヘッドスケジューリングを行うことができることを意味する。
【０１１１】
ＮＣＱのサポートは、ワイヤのホスト端及びターゲット端の両方（並びにこれらの間のあらゆる場所）で複数の「コンテキスト」の作成が要求されるので、極めてリソース集約的とすることができる。各コンテキストは、未処理のトランザクションの状態（未処理ＦＩＳ、ＤＭＡ状態、エラー状態、その他のコピーを含むことができる）を保持する。この理由から、ＳＡＴＡ  ＮＣＱプロトコルをサポートするホストコントローラもドライブもあまり広範に利用可能ではなく、ＮＣＱは、これが利用可能になったときには、（少なくとも初期では）利用可能なＳＡＴＡ  ＨＢＡ及びドライブのサブセットにおける追加コスト特徴となる。それにも関わらず、このプロトコルを使用して、ＳｔｅｅｌＶｉｎｅベース記憶サブシステムによって提供される性能を向上させることができる。物理デバイスがＮＣＱプロトコルをサポートしない場合でも、ホストは、ＳｔｅｅｌＶｉｎｅデバイスによって同じターゲットデバイス上に複数の未処理コマンドを有することが可能となる。これは、オペレーションのパイプライン方式をサポートすることによって処理性能が向上し、コマンドの送出と実行とをオーバーラップさせることによって待ち時間を隠すことが可能となる。
【０１１２】
ＮＣＱプロトコルによって、１つのターゲットデバイスにつき最大３１個までの未処理コマンドを送出することが可能となる。ポートマルチプライヤでは、１つのＨＢＡポート当たりに最大１４個までのターゲットの存在を許容する。従って、ＳＡＴＡホストコントローラは、１つのホストポート当たりに最大（１４*３１＝）４３４個までの未処理コマンドを有することができる。これは、１つのホストコントローラ当たりに（極めて）大きな数のコンテキストを表示する。同様に、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣは、この未処理コマンドの最大数をサポートしなければならない場合、コンテキストの過度に大きな数をサポートしなくてはならなくなる。幸いにも、シミュレーションは、１つのターゲット当たりに４つよりも多い未処理コマンドをサポートすることに応答して減少リターンが存在することを示しており、ＮＣＱプロトコルは、進行中の未処理コマンドの最大数よりも少ないコマンドの存在を許容する。
【０１１３】
ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣは、エクスポートする１つの仮想ドライブ当たりに一定数の未処理コマンドを提供することができ、この数は、４３４の最大指定制限よりかなり小さくすることができる。実際には、ＳＳｏＣは、１つの仮想ドライブ当たりの未処理コマンドの動的可変の数をサポートすることができる。これは、各待機コマンドがＳＳｏＣに到着したときに共通プールからコンテキストを割り当てて、フリーコンテキストがなくなるまでビジービット（ＢＳＹ）がクリアされた状態のＦＩＳをホストに戻すことによって行うことができる。この時点では、ＳｔｅｅＬＶｉｎｅコンポーネントは、待っている仮想ドライブに対してＢＳＹビットをクリアする前にコンテキストが無くなるまで単に待つことができる。独立したＡＴＡレジスタセットが各ターゲットＩＤに対して（よって、各仮想ドライブに対して）ＨＢＡに存在するので、このアクティビティは、各仮想ドライブに対して独立してコマンド送出レートを「フロー制御」する効果がある。
【０１１４】
ＮＣＱプロトコルは、ＰＭへのサポートに無関係であり（但し、両方の特徴はＳｔｅｅＬＶｉｎｅアーキテクチャにおいてサポートされる）、ＮＣＱは、ＰＭアウェア又は非ＰＭアウェアホストコントローラのいずれかで使用できる点に留意されたい。
【０１１５】
仮想化レイヤ
仮想化レイヤは、１つ又はそれ以上の（ローカル又はリモートの）物理ドライブから仮想ドライブを作成する役割を担う。仮想化は、単に、物理ドライブ上のブロックの（場合によっては適正な）サブセットとして仮想ドライブを定義することからなる。この場合、必要とされることは、仮想ドライブのアドレススペースからのＬＢＡを物理ドライブ上の適切なアドレスに変換することである。仮想化はまた、複数の物理ドライブからの連続したブロックから構成される仮想ドライブの作成を可能にする。この場合、所与の仮想コマンドが、複数の物理ドライブに影響を与えるオペレーション（すなわち、２つの物理ドライブ間の境界にわたった読み取り／書き込みオペレーション）を定義することができ、従って、複数の物理コマンドを生成しなくてはならない。仮想化レイヤは、仮想コマンドを物理コマンドの適切な数（各々が適切なフィールド値を有する）に分割し、同時にこれらの物理コマンドからの結果を結合して結合仮想応答にする役割を担う。
【０１１６】
幾つかの実施形態では、仮想化レイヤは、ルックアップテーブル（ＬＵＴ）と状態機械のセットとの組合せを用いて実装される。このような実装では、ＬＵＴが、仮想コマンドの開始ＬＢＡ及びブロックカウントフィールドをこれらの物理値に変換し、場合によっては複数の物理コマンド用のフィールドを生成する役割を担う。状態機械は、複数の物理コマンドから単一の仮想応答へのフォーキング／ジョイニング、及びこれらのオペレーションから生じることができるあらゆる例外条件の処理を実行する役割を担う。仮想コマンドに応答して複数の物理応答を結合し、ホストに戻される仮想応答にすると同時に、ホストに配信される前に、複数の物理コマンドの送出から生じた例外を結合して仮想化例外にする（及び場合によっては除去される）。
【０１１７】
読み取り／書き込み仮想コマンドの開始ＬＢＡ及びブロックカウントフィールドは、１つ又はそれ以上のセクションに分解され、次いで変換されて、所与の物理ドライブの適切な部分にマッピングされる。しかしながら、仮想化のこの動作から生じる物理コマンドの数に関わらず、１つの不変量が常に維持され、すなわち、物理コマンドのブロックカウントフィールドの総和が、仮想コマンドのブロックカウントフィールドの総和に等しい。仮想化レイヤは、アドレスを変換し、時には複数のサブリファレンスとしてこれらを送出するが、ホストによって要求されるのと全く同じ読み取り／書き込みデータを生成する。
【０１１８】
仮想化レイヤが動作する基本ユニットは、ディスクブロックの連続した範囲であり、本明細書では領域と呼ばれる。１つ又はそれ以上の物理ドライブ領域は、この仮想化レイヤにより組み合わされて、仮想ドライブを作成する。本明細書では、複数のドライブからの領域の結合は、連結又はＲＡＩＤ−１（すなわち、ストライピング（ＲＡＩＤ０）よりも冗長性とあまり関係がない独立型／低コストのディスクアレイの特徴）として公知である。連結における領域の概念及びその使用を共に以下のサブセクションで説明する。
【０１１９】
物理ディスクの領域
本明細書では、領域は、単一の物理ドライブのブロックの連続する範囲（１から全ての数に及ぶ）として定義される。オーバーラッピング領域を定義することができ、単一の領域は、ドライブ全体を含むように定義することができるが、１つの領域は、複数の物理ドライブにまたがることはできない。
【０１２０】
図１０では、仮想ドライブ（Ｖi）が、単一の物理ドライブの一部分からなる単一の領域から作成される。図示の物理ドライブ（Ｐj）は、０（ドライブの第１ブロック）からＭj（ドライブの最後のブロックのＬＢＡ）に及ぶブロックアドレススペースを有する。この図に使用された注記は、領域が定義される物理ドライブについての識別子（Ｐj）、並びに領域に対する開始ブロックアドレス（Ｓ0）及びブロックカウント（Ｃ0）を含む、タプル（Ｐj、Ｓ0、Ｃ0）として領域（Ｒ0）を表わしている。所与の物理ディスクの定義された領域は、仮想ドライブＶiとしてホストに提示することができる。このような仮想ドライブは、（Ｒ0）、その開始ＬＢＡ（０）、及びその最大ＬＢＡ（この場合、（Ｃ0−１）に等しいＭi）に基づく領域を表わすタプルによって定義される。
【０１２１】
図示された実施例では、領域に送出された読み取り／書き込みアクセスコマンドが、所与の仮想コマンドによって影響を受ける領域Ｒiのサブセットを定義する別のタプルとして示されている。このタプルは、その開始ＬＢＡ（Ｓv）及びブロックカウント（Ｃv）の点で仮想コマンドを記述している。実施例はまた、仮想化から生じた物理コマンドを示しており、これは、トランザクションの開始（物理）アドレス（Ｓ0＋Ｓv）及びブロックカウント（Ｃv）を包含するタプルからなる。この単純な場合では、コマンドタイプは同じままであり、ブロックカウントフィールドが仮想化プロセスの一部のとして変化しない点に留意されたい。
【０１２２】
これは、仮想ドライブのブロックアドレススペースを領域のアドレススペースに変換するという仮想化レイヤの最も基本的な目的を示している。これらの２つのアドレススペース間には単純な線形関係が存在するので、この変換は、ＬＵＴなどの実装で容易に行われ、付加的な論理は必要ではない。仮想化レイヤのアプリケーションの実施例は、単一のより大きな物理ドライブから複数のより小さな仮想ドライブの作成、複数のより小さな物理ドライブから単一のより大きな仮想ドライブの作成、及び複数の物理ドライブの高速領域から大きな平均よりも速い仮想ドライブの作成を含む。
【０１２３】
連結（ＲＡＩＤ−１）
仮想化レイヤの領域抽象化の拡張は、連結の概念、すなわち１つよりも多い領域の線形結合からなる仮想ドライブの作成である。この特徴を利用して、２つ又はそれ以上のより小さな領域のセット（異なる又は同じドライブのいずれかから）から単一のより大きな仮想ドライブを作成することができる。この特徴の最も簡単な使用は、複数の物理ドライブ全部を、セットの物理ドライブの全ての結合された容量を備えた単一の仮想ドライブに結合することである。
【０１２４】
図１１は、異なる物理ドライブからの２つの領域を単一の仮想ドライブに連結する実施例を提供する。この実施例では、仮想ドライブ（Ｖi）は、Ｖi（仮想アドレススペースに現れる順序で）、開始ブロックアドレス（０）、及び最大有効ブロックアドレス（Ｍi、結合された領域のサイズの和から１を引いたもの、すなわち（Ｃi0＋Ｃi1−１）に等しい）を含む領域のリストを包含するタプル（Ｌi、０、Ｍi）で表わすことができる。
【０１２５】
連結された仮想ドライブの作成に進むことのできる領域の選択に関しての制限はない（領域自体に加えられるもの以外、例えば非オーバーラッピング、連続、ブロックのグループ、その他）。
【０１２６】
拡張レイヤ
仮想化レイヤは、サイズのみが異なりそれ以外は構成される元の物理ドライブと同じ特性の全てを共有する仮想ドライブの作成と関連する。仮想化レイヤによって提供された基本機能に基づいて、拡張レイヤは、（場合によっては連結された）領域のセットから始まり、これらに付加的な機能の小さなセットを適用し、その構成成分の物理ドライブよりも拡張された特性を有する仮想ドライブを作成する。
【０１２７】
拡張レイヤは、ベースとなる物理ドライブの性能及び信頼性を拡張するために多様な方法で複数の領域を結合する。これらの特徴は、ＲＡＩＤ機能の異なる多様性を提供するシステムにおいて見られる特徴と多くの点で類似しているが、拡張レイヤは、幾つかの重要な点で異なる。このレイヤの特徴は、単一の低コストのＳＳｏＣに容易且つ安価に統合できる機能であると定義され、更に、「ワイヤ−スピード」（すなわち、ＨＢＡとドライブとの間の直接接続の性能と同等の性能レベル）で動作することができる。これは、ＳｔｅｅＬＶｉｎｅアーキテクチャのこの部分によって提供されるメカニズムが、実装が容易且つ安価である傾向があり、単純なブルート−フォース技術を使用することを意味する。例えば、単純なミラーリング（ＲＡＩＤ１）をパリティＲＡＩＤ（例えば、ＲＡＩＤ５）の代わりに使用して、処理パワー及びメモリの有意な量を必要とすることなく、単純で低コストの実装を可能にする。
【０１２８】
拡張レイヤの主な特徴は、ストライピング（ＲＡＩＤ０）、ミラーリング（ＲＡＩＤ１）、及びこの２つの組合せ（例えばＲＡＩＤ１０とＲＡＩＤ０１）を含む。これらの特徴は、仮想化レイヤによって定義された特徴の上部に階層化され、以下のサブセクションにおいて更に詳細に説明する。
【０１２９】
ストライピング（ＲＡＩＤ０）
アクセスパターンがランダム（例えば、あるソートのサーバー又はマルチユーザシステムにおいて）である場合、同時に移動する複数のヘッドの利点を得るために、ストライピングを十分大きくし、個々の読み取り／書き込みトランザクションがストライプ境界をあまり頻繁に横切らないようにしなくてはならないが、同時シークを行う統計的利点が得られないほど大きくする必要はない。局所性のいずれかのソートがある場合、或いは多くの連続した大きな読み取りがある場合、これは、要求される処理性能をもたらさない可能性があるが、マルチユーザシステムのファイルシステムに特有のソートのランダムアクセスによって、これは、極めて適切に働く結果となる。ストライピングの目的は、ヘッドを二倍にし、スループットを向上させること、すなわち粗粒度並行処理である。
【０１３０】
ミラーリング（ＲＡＩＤ１）
このアーキテクチャは、複数のミラードライブを可能にするが、Ｐｏｌａｒｉ及びＭｉｌｋｙｗａｙは、２方向及び４方向ミラーリング制約を有する。このアーキテクチャは、何らかの物理コマンドが失敗した（ドライブを非一貫性のないままである）場合に、書き込み及び失敗仮想コマンドを複製する。本アーキテクチャはまた、失敗例外を処理し、ロード／ウェアを共有するように読み取りを交互にする。本アーキテクチャは、セレクタとして開始ＬＢＡ（中間ワードビット）を使用し、ドライブの読み取りを開始するとスイッチしない。本アーキテクチャはまた、ドライブが交換されたか（ミラーリングセットに一貫性がない場合）どうかを判断するためにドライブシリアルナンバーを追跡する。
【０１３１】
幾つかの実施形態では、全ての書き込みがミラーリングセットの全メンバーに渡される。読み取りは、セット内の１つのドライブのみからもたらされるが、セクターは、一般に、同じドライブから読み取られる。本アーキテクチャは、読み取りを行うセット内のドライブを選択するために簡単な決定性スキームを使用する。良好な順次読み取り性能（＞１００ＭＢ）を確保し、ランダム読み取りにおける性能向上のためのシークオーバーラッピングを可能にするために、チャンクが大きな境界に配置される。
【０１３２】
ミラーリングセットが非一貫性であると判断された場合は、必ず再構築オペレーションを行わなくてはならない。再構築は、ミラーリングが同期されるまで再構築をアーキテクチャが続けるように不揮発性メモリにマーク付けされる。ディスクを同期しようとしている間、本アーキテクチャは、「ポインタ」の場所、すなわち分割線がコピーされたドライブエリアとコピーされていないドライブエリアとの間にある場所を追跡する。ポインタの後のブロック（すなわち、同期されているエリア）への書き込みが複製され、ポインタの前の書き込みは、同期されたドライブに行うことができる。
【０１３３】
幾つかの実施形態では、本アーキテクチャは、ポインタを不揮発性メモリ内に維持し、パワーオフになった場合、再構築が中断した場所をパワーが復帰したときにピックアップできるようにする。ポインタがインクリメントされる（すなわち、ブロックが書き込まれる）毎に不揮発性メモリに書き込むにはコストが高すぎる場合には、本アーキテクチャは、正規のチェックポイントでのみ不揮発性メモリを更新し、再起動時に行われる繰り返し作業の量を低減する。
【０１３４】
ＳｔｅｅＬＶｉｎｅ実装は、スケジューラの公平配分スタイルを使用して再構築機能を実施する。これによって、再構築アクティビティは、ホストによって使用されるもの以外の利用可能なリソースの全てを消費し、更にホストがリソースの全てを消費したいときには、再構築によって使用されるリソースの量に対してより少ない制限を与えるようにすることが可能となる。これは、ホストがロードを加えていない場合には、再構築アクティビティはリソースの全てを取得し、最短時間で再構築が完了することを意味する。ホストが１００パーセントのロードを加えている場合、再構築アクティビティは、リソースの保証された最小量（例えば２０パーセント）を取得し、これにより制限時間期間で再構築が完了するようになる。これは、ホストが、再構築アクティビティを最小量未満に規制しようとするときに、最大ポイントにしたいサイクル全てを取得して、このレベルに固定することを意味する。
【０１３５】
マッピングレイヤ
ＳｔｅｅＬＶｉｎｅアーキテクチャの次のレイヤは、マッピングレイヤとして知られる。マッピングレイヤは、ホストＦＩＳ内のターゲットＩＤフィールドと先のレイヤによって定義された仮想ドライブとの間の間接的措置の簡単なレベルを提供する。このマッピングは、ＬＵＴベース実装のオペレーションを提供し、ここで、マッピングテーブルの「ページ」の選択は、入力ＦＩＳターゲットＩＤフィールド内の値に基づいて行われる。
【０１３６】
この機能が僅かに興味深いものになるのは、物理ドライブが仮想ドライブに「アイデンティティマップ」される場合である。これは、仮想化レイヤが仮想ドライブを完全な物理ドライブからなる領域であると定義し、この仮想ドライブで行われた拡張が存在しないことを意味する。オペレーションのこのモードでは、ＳｔｅｅＬＶｉｎｅ  ＳＳｏＣは、ほぼポートマルチプライヤのように動作し、単純に所与のターゲットＩＤ（すなわち仮想ドライブ）に対する全てのコマンドを要求される物理ドライブに直接わたす。しかしながら、マッピングレイヤは、物理ドライブポートの再マッピングを可能にし、すなわち、ターゲットＩＤ０は、物理ドライブポート０にマッピングする必要はないが、物理ドライブポートのいずれかにマッピングすることができる。この特徴は、単純なポートマルチプライヤによって提供されるものよりも融通性の改善を提供し、物理ポートの再割り当て（例えばレイアウト又はパッケージングの便宜上から）に有用とすることができる。
【０１３７】
これに加えて、マッピングレイヤは、複数の「ビュー」の作成を可能にし、すなわち、どのターゲットＩＤが使用されるかに応じて、様々な異なる方法で所与の物理ドライブにアクセスすることができる。例えば、ブリックにおける４つのドライブを連結し、仮想ドライブナンバー０としてホストに提示することができる。同時に、ＳｔｅｅＬＶｉｎｅ  ＳＳｏＣは、１から４のターゲットＩＤナンバーを使用する個々の（アイデンティティ−マップされた）ドライブとしてドライブにアクセスできるように構成することができる。これは、仮想ドライブの個々の構成ドライブへの管理アクセスを可能にするため、例えば、リペア又はモニタリングアクティビティをサポートするのに有用である。
【０１３８】
変換レイヤ
ＳｔｅｅＬＶｉｎｅアーキテクチャがＳＡＴＡ記憶リンクプロトコルに基づく場合、幾つかの他の抽象上位レイヤ記憶プロトコル（例えば、ＳＣＳＩ、ｉＳＣＳＩ、ＣＩＦＳ、ＮＦＳ、その他）が存在する。ＳｔｅｅＬＶｉｎｅアーキテクチャにおける最上位レイヤは変換レイヤとして知られ、これは、ホストアクセスプロトコルをネイティブＳＡＴＡプロトコルから何らかの要求ホストインタフェースプロトコルに仮想的に変換することができるポイントである。更に、これは、ＳｔｅｅＬＶｉｎｅアーキテクチャによって提供された基本ブロック指向サービスをファイルレベルサービスに転換できる場所である。
【０１３９】
標準的なＳＡＴＡ特徴
ＳｔｅｅｌＶｉｎｅアーキテクチャＳＳｏＣは、種々のＳＡＴＡ仕様に準拠するものと定義されている。しかしながら、（仕様によって設定される制限内に留まりながら）仕様の特徴を用いる方式は、かなり自由に変更されている。例えば、ＡＴＡ仕様は、デバイスによって提供される機能及び特徴を宣言し使用可能にする適度にフレキシブルなメカニズムを提供し、ＳｔｅｅｌＶｉｎｅコンポーネントは、この仕様の態様を利用している。ＡＴＡ仕様は、どの（事前定義の）特徴をサポートするかをデバイスが宣言できるようにするデータ構造（すなわちＩＤＥＮＴ）及びプロトコル（アイデンティティコマンドを使用する）を定義する。更にＳＡＴＡは、ホストが、デバイスによって提供される特徴（例えば、ＤＭＡモード、マルチブロックオペレーションで転送されるブロック数、その他）のうちの特定のものを選択（又は使用可能に）できるようにする。ＳｔｅｅｌＶｉｎｅコンポーネントは、提供する仮想ドライブの各々に対して適切なＩＤＥＮＴデータ構造を合成し、コンポーネントがサポートする特定の特徴を指示する。
【０１４０】
ＳＡＴＡは、ＰＡＴＡドライブに対して書かれたソフトウェア（デバイスドライバ、ＯＳ、及びアプリケーションコードを含む）と下位互換性があるものと定義されている。ホストソフトウェアとＰＡＴＡ及びＳＡＴＡハードウェアとの間のメインインタフェースは、タスクファイルとして既知のレジスタのセットである。ＡＴＡレジスタセット（又はタスクファイル）は元々、データ、エラー／特徴、セクターカウント、セクターナンバー、シリンダーＬｏｗ、シリンダーＨｉｇｈ、デバイスヘッド、及び状態／コマンドレジスタとして定義されている８つの１バイトレジスタからなる。
【０１４１】
当初は、ドライブは、その物理属性である、シリンダー、ヘッド、及びセクターによってアドレス指定されていた。しかしながら、時間が経過するにつれ、アドレス指定のこの形式（Ｃ／Ｈ／Ｓとして知られる）は、論理ブロックアドレス（ＬＢＡ）として知られる、拡張され単純化された線形方式のアドレス指定に置き換えられてきた。下位互換性を維持するために、アドレス指定のこの新しい形式に元のレジスタセット定義が使用されている（すなわち、セクターナンバーレジスタは、ＬＢＡ［７：０］に対して使用され、シリンダーＬｏｗはＬＢＡ［１５：８］に対して、シリンダーＨｉｇｈはＬＢＡ［２３：１６］に対して、デバイスヘッドレジスタの部分はＬＢＡ［２７：２４］に対して使用されている）。これは、２８ビットブロックアドレス指定方式に提供されており、（一般的な５１２バイトブロックサイズを使用する場合）１２８ＧＢの最大アドレス指定可能範囲（利用可能なドライブサイズによってすぐに上回るサイズをもたらすことになる。これに応じて、ＡＴＡ規格は、「拡張レジスタ」を生成した。ＬＢＡ及びセクターカウントレジスタの各々に２バイトを連続して書き込むことができ、これによって８ビットレジスタだけ処理するレガシーソフトウェアと下位互換性のある方法で１６ビット値にまでレジスタを拡張する。この拡張は、４８ビットＬＢＡスペースを可能にし、この結果、１２８ＰＢの最大アドレス指定可能ドライブサイズ、すなわち、基本ストレージ技術におけるある種のブレークスルーがなければ、少なくとも数年は存続するはずのサイズをもたらす。
【０１４２】
ＨＢＡとデバイスとの間のＡＴＡトランザクションは、データの転送を包含しないコマンド（すなわち非データコマンド）とデータ転送コマンドとを含む。データの移動を包含するコマンドでは、ＡＴＡ仕様は幾つかの異なるデータ転送モードを定義し、各モードが連続した高レベルの性能を提供する。２つの主なデータ転送モードは、プログラムＩ／Ｏ（ＰＩＯ）と直接メモリアクセス（ＤＭＡ）として公知である。ＡＴＡレジスタセットはまた、制御ブロック（共にコマンドブロックと呼ばれる前述の８つのレジスタに加えて）として公知のレジスタペアを含む。制御ブロックレジスタは、交互状態／デバイス制御レジスタとドライブアドレスレジスタとを含む。
【０１４３】
ＳＡＴＡ仕様
ＳＡＴＡＩ仕様は、１．５ＧｂｐｓＳＡＴＡ  ＰＨＹ、リンク、トランスポート、及びプロトコルの基本特徴の全てを含む、ＳＡＴＡの第１世代を定義する。ＳＡＴＡＩＩ仕様は、ＳＡＴＡＩ仕様に対する拡張を提供し、仕様の全てのレイヤで付加的な特徴及び機能を提供する。ＰＨＹレイヤでは、この新しい仕様は、バックプレーン相互接続及び非同期信号リカバリのガイドライン、並びに高速（すなわち３Ｇｂｐｓ）リンク速度と、ホスト及びデバイスが最大共通リンク速度設定で到着できるようにする自動ネゴシエーションプロセスとを定義するのに必要な情報を提供する。
【０１４４】
プロトコルレイヤでは、新しいコマンドキューイング特徴をサポートするデバイスコマンドプロトコルに対し変更が行われている。ネイティブコマンドキューイング（ＮＣＱ）は、所与のデバイス上で複数のアウトスタンディングコマンドを送出可能にし、これらのコマンドを送出された順序以外の順序で戻すことができる新しいプロトコルの名称である。ＮＣＱサポートは、たくさんのコマンドが続いてあるときに高コストとなるコマンド当たりの割込みを有する代わりに、割込みを集約させることによってシステム性能を向上させる。また、ホストコントローラの複数のコンテキストにより、ドライブが要求するときは常に競合フリー状態リターンを可能にし、これは性能も向上させる。
【０１４５】
ＳＡＴＡＩＩ仕様に対する別の追加は、ポートマルチプライヤ（ＰＭ）機能として知られる特徴を提供する。この特徴によって、単一のＳＡＴＡホストポートを最大１５個までのドライブに接続できるようになる。この仕様は、ホスト及びドライブの両方にトランスペアレントな方法で、単一のホストポートから複数のドライブポートに展開させる単純な単一レベルのハブ状デバイスの作成を可能にする。ＰＭデバイスのカスケードは、仕様によって明確に禁止されている。
【０１４６】
ＰＭ仕様は、ＦＩＳヘッダの４つの未使用ビットを使用し、宛先ドライブポートに対するアドレス指定を可能にする。これらのビットは、ターゲットポートフィールドとして知られるフィールドを形成し、マルチプレクシングデバイスが要求される宛先（ドライブ）ポートを選択するのに使用する。通常のオペレーションでは、ＨＢＡは、ＰＭに送る各ＦＩＳヘッダにアドレスを付加する。ホストからのＦＩＳを受け取ると、ＰＭデバイスは、ＦＩＳヘッダにおけるアドレスフィールドを調べて、ターゲットポートフィールドをクリアにし、ＦＩＳを選択された宛先ポートに送る。同様に、ドライブポートから来るＦＩＳは、ＦＩＳのヘッダのその入力ポートアドレスを含むように修正され、ＦＩＳのＣＲＣは、ヘッダの変更を反映するように更新され、ＦＩＳは、ホストポートに転送される。入力ＦＩＳがそのＣＲＣチェックに失敗した場合、ＰＭデバイスは、不良ＣＲＣを伝播し、良好な（再生成された）ＣＲＣをＦＩＳに書き込むことによってこれをマスクする必要がある。
【０１４７】
Ｐｏｌａｒｉｓベース記憶サブシステム
Ｐｏｌａｒｉｓ、すなわち実装されるＳＳｏＣのＳｔｅｅｌＶｉｎｅファミリーの第１は、アーキテクチャの定義機能のサブセットを提供する。Ｍｉｌｋｙｗａｙは、ＳｔｅｅｌＶｉｎｅアーキテクチャ全体の第１の完全実施である。Ｐｏｌａｒｉｓは、シングルホストでファイブドライブの独立型製品として確定され、Ｍｉｌｋｙｗａｙは、複数のホストポート及び多数のドライブポートを有するサブシステムの構成を可能にする。広範囲の興味深い記憶サブシステムは、Ｐｏｌａｒｉｓベースのハードウェアで構成することができる。以下のセクションは、Ｐｏｌａｒｉｓの（拡張型）ポートマルチプライヤ機能及び関連するマイクロコードを使用した記憶アレイコントローラを構築を開始するハードウェア及びソフトウェアの両方について考察する。
【０１４８】
Ｐｏｌａｒｉｓ  ＳＳｏＣの一次外部インタフェースは、１つのＳＡＴＡＩＩホストポートと５つのＳＡＴＡＩＩドライブポートとからなる。更に、Ｐｏｌａｒｉｓ  ＳＳｏＣは、ＬＥＤドライバ、Ｉ2Ｃバス、及び幾つかのＧＰＩＯラインを含む、種々のマイナーＩ／Ｏインタフェースを有する。これらの外部インタフェースは両方とも、基本的な５ドライブ対１ホストのＳＡＴＡマルチプレクサ機能、並びにＰｏｌａｒｉｓ用に定義された「拡張型」機能の全てをサポートするのに必要十分である。
【０１４９】
内部的には、ハードウェアは、組み込みプロセッサ、データ移動エンジン、ＳＡＴＡポートの各々のリソース（すなわち、ＰＨＹ、リンク、及びトランスポート論理、及びリンク用ＦＩＦＯバッファとして働くレジスタのセット）、及び種々のサポート機能のための論理からなる。ポート毎のＦＩＦＯバッファの各々は、一方端でリンクに接続され、他方端で共通内部バスに接続されている。データ移動機能ユニットは、ＦＩＦＯバッファの定義されたセット間でデータを移動させることを目的とすることができる。データ移動機能ユニットは、ドライブからホスト及びホストからドライブへの転送に加えて、ドライブからドライブへの転送を行うことができる。
【０１５０】
内部リソース（ポート毎の論理、ＦＩＦＯ、データ−ムーバ、及び他のＶＯインタフェース論理など）は、ロード及び記憶装置を備えた組み込みプロセッサによってアクセスされ、その特別な制御レジスタアドレススペース（システム制御プロセッサ（ＳＣＰ）レジスタスペース内で定義された１６のレジスタの１６のバンクからなる）を介して処理される。これらのレジスタの一部（例えば、ＳＡＴＡ  ＰＨＹ、ＥＥＰＲＯＭ書き込み、ソフトリセット、その他を制御するもの）は、偶発的なアクセスに対して保護されている。
【０１５１】
Ｐｏｌａｒｉｓ  ＳＳｏＣは、外部Ｉ2Ｃ取り付けＥＥＰＲＯＭを利用し、マイクロコード、構成状態、及びポリシー関連の状態を包含する。マイクロコードは、電源投入時に自動的にＰｉｃｏ命令メモリに読み込まれ、コードが、簡単なハードウェアチェックサムメカニズムで有効にされる。
【０１５２】
Ｐｏｌａｒｉｓハードウェアは、Ｐｉｃｏプロセッサをリセットするソフトリセットレジスタを有するが、マイクロコードリロードを強制しない。ＣＯＭ−ＲＥＳＥＴアウトオブバンド信号がホストポート上で発生した場合、非マスク可能割込み（ＮＭＩ）が生成され、これがハードリセットを引き起こす（マイクロコードリロードを強制的に行う）。マイクロコードロード及び検証は、リアルタイムの１秒よりも短い時間で終了するよう設計されている。
【０１５３】
システム制御プロセッサ（ＳＣＰ）
Ｐｏｌａｒｉｓの設計では、ハードウェアにおける設計のデータプレーン部分を実装し、Ｐｉｃｏとして知られるシステム制御プロセッサ（ＳＣＰ）上で実行されるマイクロコードを用いてより高レベルの制御プレーン機能だけを実行しようとする試みが行なわれた。各リンクに対して、完全なＳＡＴＡ物理、リンク、及びトランスポートレイヤは、ハードウェア内に実装される。マイナーインタフェース機能のほとんど（例えば、Ｉ2Ｃ、ＥＥＰＲＯＭ、及びＬＥＤ）は、ある程度のハードウェアサポートを有し、バルクデータ移動の大半が専用ハードウェア機能ユニットによって行なわれる。Ｐｉｃｏのマイクロコードは、初期化、仮想化、ミラーリング、ストライピング、ポート間ＦＩＳ移動、例外条件処理、エンクロージャ管理機能、その他を含む、ＳＳｏＣによって提供される機能のほとんど全てを実装する役割を担う。
【０１５４】
ＳＳｏＣの機能のバルクを実装する場合、Ｐｉｃｏプロセッサの性能は、Ｐｏｌａｒｉｓベースシステムの全体的な性能に影響を与える。Ｐｉｃｏは、デュアル−イシューのＲＩＳＣ様の命令セット、３２レジスタの７段階パイプライン及びハーバードメモリアーキテクチャを備えた単純な組み込み３２ビット制御プロセッサである。ＰｉｃｏＩは、カウンタ−タイマー及び外部割込みをサポートするが、乗算又は除算演算のハードウェアサポートは提供しない。Ｐｏｌａｒｉｓで使用されるＰｉｃｏＩプロセッサは、浮動小数点をサポートせず、ＭＭＵなし、キャッシュなし、及びアウト・オブ・オーダー実行を行なわない。ＰｉｃｏＩプロセッサは、１５０ＭＨｚで動作し、命令メモリ用の６４ＫＢのＳＲＡＭとデータメモリ用の１６ＫＢのＳＲＡＭとを有する。
【０１５５】
以下に説明されるハードウェアリソースに加えて、ＳＣＰに対する基本サポートを提供するレジスタの付加的なバンクが存在する。これらは、一括してＣＰＵレジスタとして知られており、プロセッサ状態（ＰＳ）、割込みマスク、割込みペンディング、例外プログラムカウンタ、及びカウンタ／タイマーレジスタを含む。
【０１５６】
Ｇｎｕコンパイラスーツに基づく完全なツールチェーンがＰｉｃｏに対し開発されてきた。Ｐｉｃｏツールチェーンは、コンパイラ（ｇｃｃ）、アセンブラ（ｇａｓ）、デバッガ（ｇｄｂ）、並びにＧｎｕバイナリユーティリティ（ｂｉｎツール）を含む。
【０１５７】
スプリット−マージエンジン（ＳＭＥ）
内部データ−ムーバ機能（スプリット−マージエンジン（ＳＭＥ）として知られる）は、本質的には、ＳＣＰレジスタアドレススペース内のロケーション間（すなわち、レジスタ、ＦＩＦＯ、及びメモリ間）でダブルワードを移動させるインテリジェントオンチップＤＭＡコントローラである。ＳＭＥは、ＳＡＴＡポート間のデータ移動アクティビティの全てを担い、ストライピングとミラーリングの両方を含むドライブ仮想化機能をサポートする複雑な分散−収集オペレーションを実行することもできる。
【０１５８】
ＳＭＥはまた、ドライブツードライブコピーをサポートする。これは、ミラーリングセット再構築オペレーション、バックアップ、その他のオペレーションを行なうときのシステムレベル性能を提供する。この特徴は、Ｐｏｌａｒｉｓホストリンクに対するロードを低減するだけでなく、ホストに対するこれらの帯域幅集約的なデータコピーオペレーションの影響を低減する。これは、これらのコピーオペレーションが、かなりの数の処理サイクル、メモリ及びＩ／Ｏ帯域幅の点でホストに負担をかけず、Ｐｏｌａｒｉｓホストリンクを消費しないことを意味する。
【０１５９】
ホストＳＡＴＡポート
ホストポートは、ホストとＰｏｌａｒｉｓとの間のＳＡＴＡ接続のターゲットエンドを実装する。ホストポートに関連したリソースは、ＳＡＴＡプロトコルのＰＨＹ、リンク、及びトランスポートレイヤを実装するのに必要な論理、接続を制御するのに使用される制御及び状態レジスタのセット、並びに入力又は出力ＦＩＳヘッダ用のバッファとして働くレジスタのセットを含む。
【０１６０】
ホストポートの論理は、必要な電源投入及び低レベル同期アクティビティの全て、並びにＳＡＴＡリンクプリミティブのリンクレベルのハンドシェーキング及び交換を処理する。ＳＡＴＡプロトコル処理の幾つかの態様は、自動的に処理される（例えば、ＡＬＩＧＮ、ＣＯＮＴ、ＳＯＦ／ＥＯＦ、Ｘ−ＲＤＹ、ＨＯＬＤ、Ｒ＿ＩＰ、ＷＴＲＭ、その他のプリミティブの生成）。しかしながら、リンク上での幾つかのプリミティブの受け取りによって生成された割込みを処理し、他のリンクのプリミティブ（例えば、Ｒ−ＯＫ、Ｒ−ＥＲＲ、Ｐ−ＳＹＮＣなど）を生成するのは、Ｐｏｌａｒｉｓマイクロコード次第である。これは、ホストポートの制御及び状態レジスタの操作を介して行なわれる。ホストポート論理は、入力ＦＩＳ上でＣＲＣをチェックし、制御及び状態レジスタにチェックの結果を示す。同様に、論理は、出力ＦＩＳに対してＣＲＣを生成する。出力ＦＩＳ上で意図的に不良ＣＲＣの生成を可能にするために、特別な調節が行なわれている。部分論理が、ＦＩＳターゲットＩＤフィールドによって入力ＦＩＳのある低レベルの多重分離化を行なう。ポート論理は、アドレス１５に向けられたＦＩＳ（すなわちＰＭ１５）、並びにＳＥＭＢ論理にアドレス指定されたＦＩＳ（すなわち、ＰＭ  Ｎ＋１、ここでＮは、ホストポート制御及び状態レジスタの値を設定することによって定義される）を識別し、各場合において適切な割込みを生成する。割込みは、他の事象がホストポート上で起こったときに生成され、全ての割込みは、適切なポート制御レジスタへの書き込みによってクリアすることができる。
【０１６１】
入力ＦＩＳのヘッダは、自動的にバッファレジスタに預けられ、ＦＩＳの本体（又はペイロード）が、ＳＭＥによってターゲットデバイスに直接転送される。出力ＦＩＳのヘッダのバッファレジスタへの書き込み動作は、ポートをトリガし、ＦＩＳをホストに戻す。ポートの制御及び状態レジスタと同様に、バッファレジスタは、ＳＣＰレジスタアドレススペース内に存在し、ダブルワード（すなわち、３２ビット）値として読み書きされる。
【０１６２】
ドライブＳＡＴＡポート
Ｐｏｌａｒｉｓ上の５つのドライブポートは、Ｐｏｌａｒｉｓとこのドライブとの間のＳＡＴＡ接続のイニシエータエンドとしての役割を果たす。ドライブポートの全ては、互いにほぼ同一であり、ホストポートへの機能及び実装において大体同じである。ドライブポートは、その制御及び状態レジスタ内に幾つかの追加フィールドを含めることにより、例えば、ポート上でバイパス及びカットスルーオペレーションを可能にするためのビット、ポートのＳ状態シャドーレジスタ内にＸビットを処理するためのビット、並びに各ドライブポートに接続されたＦＩＯＦに関連するフィールドによってホストポートとは異なる。
【０１６３】
ホストポートの制御及び状態レジスタフィールドのスーパーセットを有することに加えて、各ドライブポートは、ＦＩＦＯとして管理されるフルＦＩＳ量分（すなわち８ＫＢ）のＳＲＡＭを有する。このＳＲＡＭは、ポートのドライブの各々との間で移動するＦＩＳをバッファするのに使用される。ドライブポートのＦＩＦＯは、ＳＭＥの制御下でＦＩＳ転送の発信元又は宛先のいずれかとして働くことができる。この設計は、ＦＩＳがＳＭＥエンジンによってドライブポートＦＩＦＯとの間で転送されることを予想しているが、ＳＣＰがＦＩＦＯを直接（ＤＷＯＲＤ境界に）読み取り及び書き込みすることができる。
【０１６４】
ＦＩＳの「カットスルー」ルーティングの実施をサポートし、バイトの全てが受け取られる前にその宛先ポートへのＦＩＳの転送を可能にするために、特別なハードウェア特徴がＰｏｌａｒｉｓに含まれる。この特徴に対するサポートは、ピーク性能レベルの達成を助け、そうでなければ、デバイスが（かなりの待ち時間ペナルティをもたらすが、デバイスのスループット指向の性能にわずかな影響しか与えない可能性がある）「蓄積転送」タイプのオペレーションを行なうので、各トランザクションにかなりの待ち時間が付加されることになる。ホスト−及びドライブ−ポートの論理内の特別な特徴によって、それぞれのポートの制御レジスタの操作を介してこの特徴が可能になる。
【０１６５】
また、制御レジスタは、ホストポート及びドライブポートの両方内に存在し、物理レベルＳＡＴＡインタフェース論理の構成を可能にする。
【０１６６】
エンクロージャ管理サポート機能
Ｐｏｌａｒｉｓ  ＳＳｏＣは、標準記憶エンクロージャプロセッサ（ＳＥＰ）にインタフェース接続するための標準ＳＡＴＡメカニズムをサポートする。前述のように、ＳＡＴＡ記憶エンクロージャ管理ブリッジ（ＳＥＭＢ）特徴によって、Ｐｏｌａｒｉｓコンポーネントは、ＳＡＦ−ＴＥ又はＳＥＳプロトコルのいずれかを介してＨＢＡとＳＥＰとの間のブリッジとして動作できる。
【０１６７】
ＳＥＰは、コスト、サイズ、及び複雑さにおいて広範囲に及ぶが、一般的にＳＥＰは、Ｐｏｌａｒｉｓコンポーネントよりも高コストでより大きくなり、ＳｔｅｅｌＶｉｎｅ  ＳＳｏＣよりもかなり多くのホストソフトウェアを包含する傾向がある。単純なエンクロージャ管理サービスに必要な基本特徴を使用可能にするために、ＳｔｅｅｌＶｉｎｅコンポーネントの基本特徴とより一致したコスト及び複雑さのレベルで、Ｐｏｌａｒｉｓは、より単純でより低コストの環境モニタリングチップ（例えば、ナショナル半導体ＬＭ８７）の使用をサポートすることができる。低コストＥＭコンポーネントのサポートは、マイクロコードで実装され、標準ＳＥＭＢプロトコルへのＳＩＭＧ専用拡張によって提供される。
【０１６８】
ＬＭ８７は、状態を提供し値を設定するために読み取り／書き込むことのできる一連の８ビットワイドレジスタを有する。ＬＭ８７トランザクションは、基本的に単純にパケットを読み取り（ｉ２ｃ  ａｄｄｒ、ｒｅｇ  ａｄｄｒ）、これに応答してデータバイトを取得し、パケットを書き込む（ｉ２ｃ  ａｄｄｒ、ｒｅｇ  ａｄｄｒ、ｄａｔａ  ｂｙｔｅ）。
【０１６９】
ＳＥＭＢの基本機能は単純なＩ2Ｃバスインタフェースによって提供することができるが、Ｐｏｌａｒｉｓは、ＳＥＭＢ機能に対する専用ハードウェアサポートを提供する。マスター／スレーブ対応ＩＣバスに加えて、ＤＭＡユニットのように機能し、ＥＭ  ＩＣバス上のＳＥＭＢメモリとデバイスとの間でデータのブロックを転送するのに使用することができるメモリ及び論理の（１ＫＢ）の専用ブロックが存在する。ＥＭＩ2Ｃバスは、２つの異なるＩ2Ｃターゲットアドレスでプログラムすることができる。
【０１７０】
ＳＥＭＢ  Ｉ2Ｃトランザクションは、明確に定義され且つ高度に様式化されているので、ＰｏｌａｒｉｓＳＥＭＢ論理は、これらのトランザクションに対するハードウェアサポートを提供する。詳細には、ＳＥＭＢ論理は（６又は７バイト）ＳＥＭＢパケットヘッダを自動的に受け取り、入力パケットの配置を処理するＰｏｌａｒｉｓマイクロコードへの割込みを生成する。
【０１７１】
ＳＥＭＢ論理は、各パケットの終わりに自動的にチェックサムを追加し、入力パケットに対してチェックサムを生成する（各パケットの終わりで受け取られた値に対してマイクロコードによって検証される）ように設定することができる。
【０１７２】
ＳＥＭＢ論理は、ＳＥＭＢメモリとＥＭ  Ｉ2Ｃバスとの間でデータを移動させ、ＳＭＥは、ホストとＳＥＭＢメモリとの間で（ＦＩＦＯとホストとの間でデータＦＩＳを移動させるときに行なわれるのと同じ方式で）データを移動させるのに使用される。
【０１７３】
ＳＥＭＢ論理は、ヘッダのみのパケット（すなわちデータがない）又はヘッダ及びデータパケットを有することができる入力ＳＥＰパケットヘッダを部分的に構文解析し分解することができる（ｓｅｐＳｔａｔフィールド、ＣＲＣなどを抽出する）。
【０１７４】
Ｎ回の選択の１つにＥＭ  Ｉ2ＣのＴｘデータレートを設定することができる。マイクロコードによって設定できるＳＥＭＢ論理に対する別個のリセット信号が存在する。マイクロコードは、ＥＭ  Ｉ2Ｃ上にＳＥＭＢがあるかどうかを調べるためにリセット時にプローブパケットを送り、ホストによって尋ねられたときに適切に応答して、ＰＭ  Ｎ＋１ポートに対する署名を返すことができるようにプローブパケットを通知する。
【０１７５】
ＳＥＭＢメモリは、ＳＣＰによるダブルワードアクセスで読み取り／書き込みを行うことができる。ＳＥＭＢ論理は、ハングＥＭ１２Ｃトランザクションを検出できるように、タイムアウト割込みを可能にするためのタイマーを含む。
【０１７６】
ＬＥＤ制御論理
ＳｔｅｅｌＶｉｎｅコンポーネントの別の特徴は、ＬＥＤによって物理ドライブ状態を決定する機能である。種々の記憶アプリケーションは、外部指示の種々のタイプを必要とし、従って、ＳｔｅｅｌＶｉｎｅコンポーネントは、種々のＬＥＤ動作をサポートしなくてはならない。例えば、企業製品は、故障を示す以外に与えられるＬＥＤ指示を要求しないが、消費者製品は、ドライブアクティビティとパワー指示の両方を要求する。
【０１７７】
Ｐｏｌａｒｉｓは、ＬＥＤ指示を点滅させ、同時にドライブアクティビティの自動表示を可能にするハードウェアサポートを有する。マイクロコードでこれらの機能を実行するオーバーヘッドは禁止されることになるので、これらの機能の両方に対するハードウェアサポートを提供することは重要である。Ｐｏｌａｒｉｓは、１つのドライブポート当たりに２つのＬＥＤ、ホストポート用に２つのＬＥＤ、及び４つのシステムＬＥＤを有する。ポート毎のＬＥＤペアは、ＬＥＤの状態によって種々の条件を表わす８つの異なるモードのうちの１つで動作することができる。各ＬＥＤは、オン、オフに設定することができ、又は点滅することができる。これらは、企業モードであるか否かに応じて異なるように動作する。ポート毎のＬＥＤのペアの１つは、アクティビティに応答して（数十ミリ秒の間にオン又はオフに）切り替わるようにプログラムすることができる。自動点滅モードは、選択されたＬＥＤに約１秒サイクル時間で状態を切り替えさせる。
【０１７８】
システムＬＥＤは、マイクロコードによって直接制御され、どのようなハードウェアサポート（システムＬＥＤをターンオン／オフすること以上の）もない。
【０１７９】
Ｐｏｌａｒｉｓでは、デバイスに対する実行マイクロコード、仮想化状態、及び他の構成情報の全てを記憶するのに使用される外部ＥＥＰＲＯＭにアクセスするためのサポートが提供される。
【０１８０】
Ｐｏｌａｒｉｓソフトウェアの概要
図１２に示されるように、Ｐｏｌａｒｉｓベースの記憶サブシステムのソフトウェアコンポーネントは、ソフトウェアの３つの異なるタイプからなる。この３つの部分は、３つの異なるロケーション、すなわちＳＳｏＣ上、ＳＳｏＣに対してローカルなボード上、及びホスト上に存在する。Ｐｏｌａｒｉｓ  ＳＳｏＣに基づく種々の記憶製品は、要求される機能を提供するのに必要なソフトウェアのタイプ及び量の仕様だけが異なる。ソフトウェアのこれらの種々のタイプの各々が利用可能な異なる量のリソースは、幾らか異なるように実装されることを要求する。ソフトウェアエンジニアリングにおける同様の最適実施は、当該のソフトウェアのタイプに関係なく、このソフトウェアの開発に適用される。
【０１８１】
Ｐｏｌａｒｉｓベースの記憶サブシステムにおけるソフトウェアのこれら３つの異なるカテゴリーの各々について、ホストソフトウェアから始めて、ローカルコントローラのソフトウェアに移り、更にＰｏｌａｒｉｓ  ＳＳｏＣに固有のソフトウェアで終わる、以下のサブセクションにおいて（高レベルで）説明する。これに加えて、記憶サブシステム内のソフトウェア間の種々の主なインタフェースについても説明する。これは、ポリシーモジュールを定義し実装するためのインタフェース、サブシステムのオペレーションをモニターするためのインタフェース、及びＰｏｌａｒｉｓ  ＳＳｏＣ内のマイクロコードを更新するためのインタフェースを含む。
【０１８２】
ホストソフトウェア
ホスト側で実行されるソフトウェアは、システムと、制約が少ない状態では標準的でリソース豊富なホスト環境で実行されるアプリケーションレベルソフトウェアとからなる。所与のＰｏｌａｒｉｓベース記憶製品に対して要求されるシステムレベルソフトウェアの量を最小にすることが望ましい。これは、各新ＯＳ及びプラットフォームリリースに対するドライバの連続的なポーティング及び互換性テストに関連する高コストに起因する。幾つかのシステムソフトウェアは、記憶サブシステムの特徴を既存のシステム管理コンソールにマッピングするポリシー又はアダプタなど、ユーザ対話なしに実行されるデーモンの形式で提供することができる。
【０１８３】
デバイスドライバ
最も低いレベルでは、デバイスドライバ内に実装される機能がある。これは、記憶サブシステムを形成する関心の事象の非同期通知の発生の結果として、コールバック（ｉｏｃｔｌｓへの）を生成する、及びＰｏｌａｒｉｓハードウェアの低レベル特徴への（ｉｏｃｔｌのような）アクセスを可能にするといった、種々の低レベル特徴を含むことができる。ＳｔｅｅｌＶｉｎｅアーキテクチャの目的の１つは、ホストに対してトランスペアレントな機能の追加を可能にすることである。これは、既存（レガシー）のデバイスドライバで適切に動作する記憶サブシステムをＰｏｌａｒｉｓハードウェアによって構築しなければならないことを意味する。所与のサブシステムの幾つかの特徴は、特別なデバイスドライバを介してのみアクセス可能とすることができるが、標準的なリリース済みのデバイスドライバによってサブシステムの値の多くを引き出すことが望ましい。
【０１８４】
アプリケーション
最上位レイヤには、ユーザと対話するＣＬＩ及びＧＵＩなどのユーザ対話アプリケーションがある。ＣＬＩは、スクリプト記述又は他の管理機能を使用可能にすることができる。ＧＵＩは、抽象化によってオペレーションを単純化することができる。
【０１８５】
外部インタフェースＡＰＩ／ライブラリ
本アーキテクチャは、システムの特徴にアクセスするための外部インタフェースライブラリを提供することができる。サブシステムとの通信がどのように抽象化されるかの詳細及び変更は、サブシステムの種々のコンポーネントとは無関係に行なうことができる。全てのホストＳＷ（デバイスドライバ以外）は、特徴への均一なアクセスを確保し、ポータビリティを向上させるために共通ライブラリを使用することができる。
【０１８６】
外部コントローラファームウェア
エンクロージャ管理、外部インタフェース処理、及び外部ポリシー実装のためのプロセッサを含む、組み込みコントローラの幾つかの異なる種類がＰｏｌａｒｉｓベース記憶サブシステムにおいて見られる。各機能は、個々のプロセッサによって処理され、或いは共通のプロセッサに共に集約され、これらのプロセッサ上で実行されるソフトウェアのタイプは、本質的に類似しており、本明細書ではファームウェアと呼ばれる。ファームウェアは、ホストソフトウェア及びマイクロコードの両方に共通の特性を有する。しかしながら、ファームウェア実行環境は通常、典型的なホスト環境よりも関連するリソースが少ないが、Ｐｏｌａｒｉｓマイクロコードに利用可能なものよりもかなり多い。ランタイム環境は、マイクロコード又は商用ＲＴＯＳ、或いはユニックスデリバティブ（Ｋｎｏｐｐｉｘ、ｅＣｏｓなど）に対して使用されるものと同じとすることができる。インタフェースパッケージは、外部インタフェースのどの種類が記憶サブシステムに提供されるかに応じて、要求される外部インタフェース（例えば、ウェブサーバー、プロトコル、リンクインタフェースなど）、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＵＳＢ、その他を提供するためのファームウェアモジュールである。例えば、Ｐｏｌａｒｉｓは、構成、モニタリング、又は更新のためのＣＬＩを実行するためにシリアル又はＵＳＢポートを提供することができ、或いはウェブサーバーを実行し、イーサネットに接続して、ウェブブラウザからの制御／モニタリングを可能にすることもできる。
【０１８７】
ＳＳｏＣマイクロコード
Ｐｏｌａｒｉｓ  ＳＳｏＣ上で実行されるコードは、マイクロコードとして一般に公知であり、共通サービス部分、アプリケーション固有部分、及び（オプションとして）組み込みポリシーモジュールを含む、幾つかの主要部分からなる。種々の特徴セットが種々の製品に対して定義されているので、マイクロコードに対する変更は、ポリシーモジュールに限定される必要がある。
【０１８８】
ノー−タッチアプライアンスからハイタッチ管理システムに及ぶ、広範囲の種々の使用モデルが存在する。一部が使用されるモードによっては、概して追加ソフトウェアのないものからソフトウェアの幅広い量までが必要になる。
【０１８９】
結論
上記のことから、高度記憶システムの特定の実施形態を例証の目的で本明細書で説明してきたが、本発明の精神及び範囲から逸脱することなく種々の修正を行い得ることは理解されるであろう。例えば、記憶デバイスは一般に、ディスクドライブの観点から上記で言及されたが、フラッシュデバイス、テープドライブ、及び他のストレージ技術のようなディスクベースでない種々の異なる記憶デバイスを使用することができる。同様に、記憶インタフェースはＳＡＴＡインタフェースの観点から説明してきたが、パラレルアドバンスドテクノロジーアタッチメント（ＰＡＴＡ）、ユニバーサルシリアルバス（ＵＳＢ）、ファイヤワイヤ、及びファイバチャネルなどの他の記憶インタフェースを高度記憶システムと共に使用することができる。高度記憶システムはまた、カスタムＡＳＩＣ上などのハードウェア又はソフトウェアのいずれかにおいて、或いは汎用コンピュータシステムを使用することによって実装することができる。従って、本発明は、添付の請求項以外によって限定されるものではない。
【図面の簡単な説明】
【０１９０】
【図１】１つの実施形態における高度記憶システムのコンポーネントを示すブロック図である。
【図２】１つの実施形態におけるカスケードされた高度記憶システムデバイスのトポロジーを示す図である。
【図３】１つの実施形態におけるシステムの仮想対物理マッピングコンポーネントの処理を示すフロー図である。
【図４】１つの実施形態における仮想応答を生成するための仮想対物理マッピングコンポーネントの処理を示すフロー図である。
【図５】１つの実施形態における種々の記憶アーキテクチャを示す図である。
【図６】１つの実施形態におけるＳｔｅｅｌＶｉｎｅアーキテクチャの種々のアプリケーションを示す図である。
【図７】１つの実施形態におけるポリシーとメカニズムの分離を示す図である。
【図８】１つの実施形態における仮想コマンドから物理コマンドへの変換を示す図である。
【図９】１つの実施形態におけるＳｔｅｅｌＶｉｎｅコンポーネントの論理レイヤを示す図である。
【図１０】１つの実施形態における物理ディスク領域から仮想ドライブへの変換を示す図である。
【図１１】１つの実施形態における物理ディスク領域を連結することによる仮想ドライブの生成を示す図である。
【図１２】１つの実施形態における記憶サブシステムソフトウェアコンポーネントの高レベル図である。
【図１】
2009508192.tif 000003
【図２】
2009508192.tif 000004
【図３】
2009508192.tif 000005
【図４】
2009508192.tif 000006
【図５】
2009508192.tif 000007
【図６】
2009508192.tif 000008
【図７】
2009508192.tif 000009
【図８】
2009508192.tif 000010
【図９】
2009508192.tif 000011
【図１０】
2009508192.tif 000012
【図１１】
2009508192.tif 000013
【図１２】
2009508192.tif 000014
【国際調査報告】
2009508192.tif 000015
2009508192.tif 000016
2009508192.tif 000017