ストレージ・コントローラのためのポリシー・ベースのデータ廃棄
【課題】ストレージ・コントローラで実行するためのポリシー・ベースのデータ廃棄を提供すること。
【解決手段】磁気ディスク・ドライブなどのメディア上に格納された論理ボリュームには、１つまたは複数の可能な廃棄ポリシー・エントリを割り当てることができる。ポリシー・エントリをコントローラに格納して実行する方がホスト・ベースの廃棄を実行するよりも効率が良く、ホストとコントローラとの間での貴重な帯域幅の使用が少なくて済む。加えてコントローラは、ストレージ・アレイ内の各ドライブの障害、機能低下、およびオフライン状況に気付き、それによって必要であれば廃棄操作を終了または修正することができる。それぞれのポリシー・エントリは、データ・ボリュームが格納されたメディアの場所で実行される書き込みパスの数およびメディアの場所で書き込むパターンを含む。ポリシー・エントリは、複数の書き込みパスそれぞれまたは第１の書き込みパスのみの、いずれでパリティ領域を更新するかも示すことができる。
【解決手段】磁気ディスク・ドライブなどのメディア上に格納された論理ボリュームには、１つまたは複数の可能な廃棄ポリシー・エントリを割り当てることができる。ポリシー・エントリをコントローラに格納して実行する方がホスト・ベースの廃棄を実行するよりも効率が良く、ホストとコントローラとの間での貴重な帯域幅の使用が少なくて済む。加えてコントローラは、ストレージ・アレイ内の各ドライブの障害、機能低下、およびオフライン状況に気付き、それによって必要であれば廃棄操作を終了または修正することができる。それぞれのポリシー・エントリは、データ・ボリュームが格納されたメディアの場所で実行される書き込みパスの数およびメディアの場所で書き込むパターンを含む。ポリシー・エントリは、複数の書き込みパスそれぞれまたは第１の書き込みパスのみの、いずれでパリティ領域を更新するかも示すことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にデータ消滅（廃棄（ｓｈｒｅｄｄｉｎｇ））に関し、具体的には、柔軟なストレージ・コントローラ・ベースの廃棄ポリシーを提供することに関する。
【背景技術】
【０００２】
ビジネス、セキュリティ、規制、または政治上の要件により、格納されているが古くなったかまたはもはや必要でない顧客データを、回復不能な（データ廃棄と呼ばれる）方法で確実に消去または削除する必要が生じる可能性がある。廃棄には、顧客データが格納された物理メディアの領域の上書きが含まれる。上書きは、通常、すべて０、すべて１などの様々なビット・パターンのうちの１つにデータを置き換える。さらに、上書き操作の際にエラーが生じる可能性があるため、セキュリティ・プロトコルの中には、オリジナル・データの残余物が確実に残らないようにするために複数の上書きパスを要求するものもある。したがって中には廃棄ポリシーとして、指定されたパターンを７回書き込むように要求する政府もある。さらに厳重な別のポリシーでは、データをその補数で上書きした後、すべて１で上書きし、その後すべて０で上書きし、最後に指定されたパターンで７回上書きするように要求するものもある。他の廃棄ポリシーも使用され、それらは適用および規制機関によって変わる場合がある。
【０００３】
従来、テープ・ドライブおよび光ドライブは、固定されたパターンで上書きを実行するかまたはボリューム全体を消去する固定型コマンドを実施してきた。ＩＢＭ（登録商標）Ｄａｔａ Ｒｅｔｅｎｔｉｏｎ ４５０などの新しいデータ保存製品は、磁気ディスク・ドライブを基にしており、サーバ（またはホスト）および外部ディスク・コントローラを含む。図１は、ホスト１１０、ストレージ・コントローラ１２０、および接続されたディスク・ドライブ（ＲＡＩＤアレイを備える場合がある）１３０を含む、例示的なデータ保存デバイス１００を示すブロック図である。ホスト１２０内のソフトウェア１２２は、論理ボリュームのどのセクタが廃棄されることになるのかを追跡し、廃棄操作の実行を指示する。
【０００４】
テープおよび光ドライブからデータを消滅させるために従来から使用されてきた固定型消去コマンドには、この新しい変化する規制廃棄要件を満たすほど十分な柔軟性はない。さらに、データ・セクタを上書きするために、ホストはあたかも実際のデータであるかのように上書きパターンをストレージ・コントローラに送信しなければならない。ネットワーク環境では、こうしたデータの伝送に費用のかかる帯域幅が使用される。
【０００５】
加えてストレージ・アレイ１３０では、通常、論理ボリュームのセクタはアレイ１３０の複数の物理ドライブにまたがって広がる。ドライブの１つが、オフラインであるかまたは機能低下状態という、コントローラ１２０には知られているがホスト１１０には知られていない状況にある場合がある。このような場合、オフラインまたは機能が低下したドライブ上のデータは、ホスト１１０が廃棄操作を成功したものとみなしても、廃棄されずに残っている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、様々な廃棄要件に対処し、帯域幅要件を削減し、オフラインまたは機能低下ドライブを考慮に入れる、柔軟な廃棄システムが求められている。
【課題を解決するための手段】
【０００７】
本発明は、ポリシー・ベースのデータ廃棄をストレージ・コントローラで実行するための方法、システム、コンピュータ・プログラム、およびコンピューティング・インフラストラクチャをデプロイするための方法を提供する。廃棄ポリシー・エントリは、ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関して作成される。ポリシー・エントリは、ボリュームを廃棄する旨のコマンドを受信するとポリシー・エントリに従ってコマンドを実行するコントローラに、格納される。ポリシー・エントリは、メディアの場所で実行される書き込みパスの数およびメディアの場所に書き込むパターンを含む。ポリシー・エントリは、複数の書き込みパスそれぞれまたは第１の書き込みパスのみの、いずれでパリティ領域を更新するかも示すことができる。ボリュームは任意数の可能な廃棄ポリシー・エントリに関連付けることが可能であり、ホストからの廃棄コマンドはどのポリシー・エントリを実行することになるのかを示す。
【０００８】
一実施形態では、廃棄コマンドは、ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内のベンダー特定ビットを使用することなどによって、ＳＣＳＩ ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドに埋め込まれる。使用されるビット数は、ボリュームについて使用可能なポリシー・エントリの数を表す。
【０００９】
ポリシー・エントリをコントローラに格納して実行する方がホスト・ベースの廃棄を実行するよりも効率が良く、ホストとコントローラとの間での貴重な帯域幅の使用が少なくて済む。加えてコントローラは、ストレージ・アレイ内の各ドライブの障害、機能低下、およびオフライン状況に気付き、それによって必要であれば廃棄操作を終了または修正することができる。
【発明を実施するための最良の形態】
【００１０】
図２は、本発明の廃棄管理がインプリメント可能なストレージ・コントローラ２００を示すブロック図である。コントローラ２００は、ホスト・インターフェース２０２を介して、直接またはネットワーク２６０を介してホスト２５０に接続される。コントローラは、１つまたは複数のデバイス・インターフェース２０４を介してディスク・ドライブまたはＲＡＩＤアレイ２７０にも接続される。データは、論理ボリュームを表す物理セクタ内の単一のドライブに格納することができる。アレイ２７０では、論理ボリューム３００のデータは個々のドライブにまたがって広がるセクタに格納される。どちらの構成でも、物理ストレージの論理ボリュームへのマッピングはコントローラ２００によって維持される。図３は、データ領域３０２およびパリティ領域３０４を有する例示的論理ボリューム３００を示す図である。コントローラ２００は、ソフトウェア命令が格納されたメモリ２１０、および命令を実行するように動作可能なプロセッサ２０６も含む。メモリ２１０に格納されたソフトウェア命令の中に、廃棄管理モジュール２１２がある。
【００１１】
廃棄管理モジュール２１２は、ドライブ２７０に格納された各論理ボリュームに関するポリシーを含む。ポリシーは、ボリュームが廃棄される間に実行されることになる上書きパスの数を表すパラメータと、オリジナルの顧客データを上書きする際に使用するパターンを表すパラメータとを含む。パターンのいくつかの例には、政府向け適用範囲に使用されるセキュリティ標準指定パターン、すべて０、すべて１、オリジナル顧客データの補数およびそれに続く他のパターン、オリジナル顧客データの論理ＯＲまたは排他ＯＲおよびそれに続く他のパターン、あるいは何らかの他の任意のパターンが含まれる（これらに限定されるものではない）。
【００１２】
ポリシーは、パリティ領域３０４で実行されることになる内容を示すパラメータも含むことができる。たとえば、フラグまたは他のインジケータを、パリティ領域が各上書きパス中に更新される予定の場合は第１の状態に設定し、パリティ領域が第１の上書きパス中にのみ更新される予定の場合は第２の状態に設定することができる。
【００１３】
ポリシーには数字または記述的な名前（以下「ポリシー・ハンドル」と呼ぶ）を割り当てることが可能であるため、ポリシー数の効果的な識別子とすることができる。一実施形態では、各論理ボリュームはそれらそれぞれのハンドルによって識別されるいくつかの可能な廃棄ポリシーを有することができる。したがって動作時には、ボリュームを廃棄するようにとのホスト２５０からコントローラ２００へのコマンドは、コントローラ２００によって実行されることになる廃棄ポリシーのハンドルを含むことができる。２ビットの廃棄コマンドは４つの可能な廃棄ポリシーのうちの１つを識別することになる。たとえば、ホスト２５０がＳＣＳＩコマンド・インターフェースを介してコントローラ２００に接続された一実施形態では、廃棄コマンドを、図４に示されるように、既存のｗｒｉｔｅ＿ｖｅｒｉｆｙコマンド４００の２つのベンダー特定ビット（ビット６および７など）４０２および４０４に埋め込むことができる。図５のテーブルに示されるように、２つのビットの異なる組み合わせによって、ボリュームで使用される予定の４つの使用可能な廃棄ポリシーが表される。別のテーブルを使用して、各論理ボリュームに使用可能な廃棄ポリシーを指定することができる。このテーブルは事前に定義されたポリシー・エントリ（図５）を参照するか、あるいは、実行されることになる書き込みパスの数を確立するエントリ（図６）を介したポリシー、オリジナル・データを上書きするためのパターン、および所望であればパリティの上書きを１回実行するかまたは上書きを複数回実行するか、を定義することができる。異なる数のビットを使用してより多くのまたはより少ない可能な廃棄ポリシーを提供することが可能であること、ならびに、ｗｒｉｔｅ＿ｖｅｒｉｆｙの他のビットおよび他のコマンドを使用して、ホスト２５０からコントローラ２００へポリシー選択を搬送することが可能であることを理解されよう。さらに廃棄管理モジュール２１２は、システム管理者が追加の廃棄ポリシーを定義および格納できるようにするためのインターフェースを提供することもできる。
【００１４】
以前の技法では、ボリュームを廃棄するにはホスト１１０（図１）がコントローラ１２０にオリジナルの顧客データを上書きする際に使用するパターンを伝送する必要があった。実際のところ、このパターンは実際のデータの形および実際のデータと同じサイズであったため、伝送には同じ帯域幅が必要であった。さらに、パターンが複数回書き込まれる場合、さらに多くの帯域幅を使用して複数回伝送しなければならない可能性があった。しかしながら、これに対して本発明では、ポリシーはコントローラ２００に格納され、これによって実行されるため、単一の廃棄コマンドそれ自体を伝送する以外のためにホスト２５０とコントローラ２００の間で貴重な帯域幅を使用する必要がない。
【００１５】
時には、ディスク・ドライブまたはアレイ２７０のドライブのうちの１つが障害を生じる、機能低下状態となる、またはオフラインとなり、ホスト２５０には知られずにコントローラ２００には知られている状況となる場合がある。ホスト２５０から廃棄管理が実行された場合、実際には全体または一部に障害が生じても、廃棄操作は成功したとみなされる可能性がある。本発明の廃棄管理はコントローラ２００でインプリメントされるため、コントローラ２００にこうした状況を認知する機能を提供する。たとえば、コントローラ２００はデフォルト時に、廃棄することになるデータがあるドライブ２７０またはドライブのうちの１つが機能低下またはオフラインになった場合、廃棄操作を終了させ、ホスト２５０に障害を通知することができる。別の方法として、コントローラ２００はデフォルト時に、使用可能な任意のデータを廃棄してホスト２５０に通知することもできる。さらに他の方法として、廃棄コマンドは、ドライブ２７０またはドライブのうちの１つが機能低下またはオフラインになった場合、２つの（または他の）操作のうちのいずれが実行されることになるかを示すこともできる。
【００１６】
以上、本発明について、完全に機能しているデータ処理システムとの関連において説明してきたが、当業者であれば、本発明のプロセスが命令および様々な形のコンピュータ読み取り可能メディアの形で配布可能であること、ならびに、本発明がその配布を実施するために実際に使用される特定タイプの信号搬送メディアに関係なく適用されることを理解されよう。コンピュータ読み取り可能メディアの例には、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの記録可能タイプのメディア、ならびに、デジタルおよびアナログの通信リンクなどの伝送タイプのメディアが含まれる。
【００１７】
本発明の説明は例示および説明の目的で提示されてきたものであり、本発明を網羅するかまたは開示された形に限定することは意図されていない。当業者には多くの修正および変形形態が明らかとなろう。実施形態は、本発明の原理、実用的な応用例を最も良く説明するため、ならびに他の当業者が企図された特定の使用に好適な様々な修正を伴う様々な実施形態に関して本発明を理解できるようにするために、選択および記載されたものである。さらに、上記では装置に関して説明したが、当分野のニーズは、廃棄操作を管理する方法、廃棄操作を管理するための命令を含むコンピュータ・プログラム、または廃棄操作を管理するためのコンピューティング・システムにコンピュータ読み取り可能コードを組み込むことを有するコンピューティング・インフラストラクチャをデプロイするための方法によっても満たすことができる。
【図面の簡単な説明】
【００１８】
【図１】例示的なデータ保存デバイスを示すブロック図である。
【図２】本発明の廃棄管理がインプリメント可能なストレージ・コントローラを示すブロック図である。
【図３】例示的な論理ボリュームを示す図である。
【図４】廃棄コマンドとして使用可能なＳＣＳＩ ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドのビットを示す図である。
【図５】廃棄コマンドのビットの値に基づいて選択される可能な廃棄ポリシーを示すテーブルである。
【図６】廃棄コマンドのビットの値に基づいて選択される可能な廃棄ポリシーを示す代替のテーブルである。
【符号の説明】
【００１９】
２００ ストレージ・コントローラ
２０２ インターフェース
２０４ インターフェース
２０６ プロセッサ
２１０ メモリ
２１２ 廃棄管理
２５０ ホスト
２６０ ネットワーク
２７０ ドライブまたはアレイ
３００ 論理ボリューム
【技術分野】
【０００１】
本発明は、一般にデータ消滅（廃棄（ｓｈｒｅｄｄｉｎｇ））に関し、具体的には、柔軟なストレージ・コントローラ・ベースの廃棄ポリシーを提供することに関する。
【背景技術】
【０００２】
ビジネス、セキュリティ、規制、または政治上の要件により、格納されているが古くなったかまたはもはや必要でない顧客データを、回復不能な（データ廃棄と呼ばれる）方法で確実に消去または削除する必要が生じる可能性がある。廃棄には、顧客データが格納された物理メディアの領域の上書きが含まれる。上書きは、通常、すべて０、すべて１などの様々なビット・パターンのうちの１つにデータを置き換える。さらに、上書き操作の際にエラーが生じる可能性があるため、セキュリティ・プロトコルの中には、オリジナル・データの残余物が確実に残らないようにするために複数の上書きパスを要求するものもある。したがって中には廃棄ポリシーとして、指定されたパターンを７回書き込むように要求する政府もある。さらに厳重な別のポリシーでは、データをその補数で上書きした後、すべて１で上書きし、その後すべて０で上書きし、最後に指定されたパターンで７回上書きするように要求するものもある。他の廃棄ポリシーも使用され、それらは適用および規制機関によって変わる場合がある。
【０００３】
従来、テープ・ドライブおよび光ドライブは、固定されたパターンで上書きを実行するかまたはボリューム全体を消去する固定型コマンドを実施してきた。ＩＢＭ（登録商標）Ｄａｔａ Ｒｅｔｅｎｔｉｏｎ ４５０などの新しいデータ保存製品は、磁気ディスク・ドライブを基にしており、サーバ（またはホスト）および外部ディスク・コントローラを含む。図１は、ホスト１１０、ストレージ・コントローラ１２０、および接続されたディスク・ドライブ（ＲＡＩＤアレイを備える場合がある）１３０を含む、例示的なデータ保存デバイス１００を示すブロック図である。ホスト１２０内のソフトウェア１２２は、論理ボリュームのどのセクタが廃棄されることになるのかを追跡し、廃棄操作の実行を指示する。
【０００４】
テープおよび光ドライブからデータを消滅させるために従来から使用されてきた固定型消去コマンドには、この新しい変化する規制廃棄要件を満たすほど十分な柔軟性はない。さらに、データ・セクタを上書きするために、ホストはあたかも実際のデータであるかのように上書きパターンをストレージ・コントローラに送信しなければならない。ネットワーク環境では、こうしたデータの伝送に費用のかかる帯域幅が使用される。
【０００５】
加えてストレージ・アレイ１３０では、通常、論理ボリュームのセクタはアレイ１３０の複数の物理ドライブにまたがって広がる。ドライブの１つが、オフラインであるかまたは機能低下状態という、コントローラ１２０には知られているがホスト１１０には知られていない状況にある場合がある。このような場合、オフラインまたは機能が低下したドライブ上のデータは、ホスト１１０が廃棄操作を成功したものとみなしても、廃棄されずに残っている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、様々な廃棄要件に対処し、帯域幅要件を削減し、オフラインまたは機能低下ドライブを考慮に入れる、柔軟な廃棄システムが求められている。
【課題を解決するための手段】
【０００７】
本発明は、ポリシー・ベースのデータ廃棄をストレージ・コントローラで実行するための方法、システム、コンピュータ・プログラム、およびコンピューティング・インフラストラクチャをデプロイするための方法を提供する。廃棄ポリシー・エントリは、ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関して作成される。ポリシー・エントリは、ボリュームを廃棄する旨のコマンドを受信するとポリシー・エントリに従ってコマンドを実行するコントローラに、格納される。ポリシー・エントリは、メディアの場所で実行される書き込みパスの数およびメディアの場所に書き込むパターンを含む。ポリシー・エントリは、複数の書き込みパスそれぞれまたは第１の書き込みパスのみの、いずれでパリティ領域を更新するかも示すことができる。ボリュームは任意数の可能な廃棄ポリシー・エントリに関連付けることが可能であり、ホストからの廃棄コマンドはどのポリシー・エントリを実行することになるのかを示す。
【０００８】
一実施形態では、廃棄コマンドは、ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内のベンダー特定ビットを使用することなどによって、ＳＣＳＩ ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドに埋め込まれる。使用されるビット数は、ボリュームについて使用可能なポリシー・エントリの数を表す。
【０００９】
ポリシー・エントリをコントローラに格納して実行する方がホスト・ベースの廃棄を実行するよりも効率が良く、ホストとコントローラとの間での貴重な帯域幅の使用が少なくて済む。加えてコントローラは、ストレージ・アレイ内の各ドライブの障害、機能低下、およびオフライン状況に気付き、それによって必要であれば廃棄操作を終了または修正することができる。
【発明を実施するための最良の形態】
【００１０】
図２は、本発明の廃棄管理がインプリメント可能なストレージ・コントローラ２００を示すブロック図である。コントローラ２００は、ホスト・インターフェース２０２を介して、直接またはネットワーク２６０を介してホスト２５０に接続される。コントローラは、１つまたは複数のデバイス・インターフェース２０４を介してディスク・ドライブまたはＲＡＩＤアレイ２７０にも接続される。データは、論理ボリュームを表す物理セクタ内の単一のドライブに格納することができる。アレイ２７０では、論理ボリューム３００のデータは個々のドライブにまたがって広がるセクタに格納される。どちらの構成でも、物理ストレージの論理ボリュームへのマッピングはコントローラ２００によって維持される。図３は、データ領域３０２およびパリティ領域３０４を有する例示的論理ボリューム３００を示す図である。コントローラ２００は、ソフトウェア命令が格納されたメモリ２１０、および命令を実行するように動作可能なプロセッサ２０６も含む。メモリ２１０に格納されたソフトウェア命令の中に、廃棄管理モジュール２１２がある。
【００１１】
廃棄管理モジュール２１２は、ドライブ２７０に格納された各論理ボリュームに関するポリシーを含む。ポリシーは、ボリュームが廃棄される間に実行されることになる上書きパスの数を表すパラメータと、オリジナルの顧客データを上書きする際に使用するパターンを表すパラメータとを含む。パターンのいくつかの例には、政府向け適用範囲に使用されるセキュリティ標準指定パターン、すべて０、すべて１、オリジナル顧客データの補数およびそれに続く他のパターン、オリジナル顧客データの論理ＯＲまたは排他ＯＲおよびそれに続く他のパターン、あるいは何らかの他の任意のパターンが含まれる（これらに限定されるものではない）。
【００１２】
ポリシーは、パリティ領域３０４で実行されることになる内容を示すパラメータも含むことができる。たとえば、フラグまたは他のインジケータを、パリティ領域が各上書きパス中に更新される予定の場合は第１の状態に設定し、パリティ領域が第１の上書きパス中にのみ更新される予定の場合は第２の状態に設定することができる。
【００１３】
ポリシーには数字または記述的な名前（以下「ポリシー・ハンドル」と呼ぶ）を割り当てることが可能であるため、ポリシー数の効果的な識別子とすることができる。一実施形態では、各論理ボリュームはそれらそれぞれのハンドルによって識別されるいくつかの可能な廃棄ポリシーを有することができる。したがって動作時には、ボリュームを廃棄するようにとのホスト２５０からコントローラ２００へのコマンドは、コントローラ２００によって実行されることになる廃棄ポリシーのハンドルを含むことができる。２ビットの廃棄コマンドは４つの可能な廃棄ポリシーのうちの１つを識別することになる。たとえば、ホスト２５０がＳＣＳＩコマンド・インターフェースを介してコントローラ２００に接続された一実施形態では、廃棄コマンドを、図４に示されるように、既存のｗｒｉｔｅ＿ｖｅｒｉｆｙコマンド４００の２つのベンダー特定ビット（ビット６および７など）４０２および４０４に埋め込むことができる。図５のテーブルに示されるように、２つのビットの異なる組み合わせによって、ボリュームで使用される予定の４つの使用可能な廃棄ポリシーが表される。別のテーブルを使用して、各論理ボリュームに使用可能な廃棄ポリシーを指定することができる。このテーブルは事前に定義されたポリシー・エントリ（図５）を参照するか、あるいは、実行されることになる書き込みパスの数を確立するエントリ（図６）を介したポリシー、オリジナル・データを上書きするためのパターン、および所望であればパリティの上書きを１回実行するかまたは上書きを複数回実行するか、を定義することができる。異なる数のビットを使用してより多くのまたはより少ない可能な廃棄ポリシーを提供することが可能であること、ならびに、ｗｒｉｔｅ＿ｖｅｒｉｆｙの他のビットおよび他のコマンドを使用して、ホスト２５０からコントローラ２００へポリシー選択を搬送することが可能であることを理解されよう。さらに廃棄管理モジュール２１２は、システム管理者が追加の廃棄ポリシーを定義および格納できるようにするためのインターフェースを提供することもできる。
【００１４】
以前の技法では、ボリュームを廃棄するにはホスト１１０（図１）がコントローラ１２０にオリジナルの顧客データを上書きする際に使用するパターンを伝送する必要があった。実際のところ、このパターンは実際のデータの形および実際のデータと同じサイズであったため、伝送には同じ帯域幅が必要であった。さらに、パターンが複数回書き込まれる場合、さらに多くの帯域幅を使用して複数回伝送しなければならない可能性があった。しかしながら、これに対して本発明では、ポリシーはコントローラ２００に格納され、これによって実行されるため、単一の廃棄コマンドそれ自体を伝送する以外のためにホスト２５０とコントローラ２００の間で貴重な帯域幅を使用する必要がない。
【００１５】
時には、ディスク・ドライブまたはアレイ２７０のドライブのうちの１つが障害を生じる、機能低下状態となる、またはオフラインとなり、ホスト２５０には知られずにコントローラ２００には知られている状況となる場合がある。ホスト２５０から廃棄管理が実行された場合、実際には全体または一部に障害が生じても、廃棄操作は成功したとみなされる可能性がある。本発明の廃棄管理はコントローラ２００でインプリメントされるため、コントローラ２００にこうした状況を認知する機能を提供する。たとえば、コントローラ２００はデフォルト時に、廃棄することになるデータがあるドライブ２７０またはドライブのうちの１つが機能低下またはオフラインになった場合、廃棄操作を終了させ、ホスト２５０に障害を通知することができる。別の方法として、コントローラ２００はデフォルト時に、使用可能な任意のデータを廃棄してホスト２５０に通知することもできる。さらに他の方法として、廃棄コマンドは、ドライブ２７０またはドライブのうちの１つが機能低下またはオフラインになった場合、２つの（または他の）操作のうちのいずれが実行されることになるかを示すこともできる。
【００１６】
以上、本発明について、完全に機能しているデータ処理システムとの関連において説明してきたが、当業者であれば、本発明のプロセスが命令および様々な形のコンピュータ読み取り可能メディアの形で配布可能であること、ならびに、本発明がその配布を実施するために実際に使用される特定タイプの信号搬送メディアに関係なく適用されることを理解されよう。コンピュータ読み取り可能メディアの例には、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの記録可能タイプのメディア、ならびに、デジタルおよびアナログの通信リンクなどの伝送タイプのメディアが含まれる。
【００１７】
本発明の説明は例示および説明の目的で提示されてきたものであり、本発明を網羅するかまたは開示された形に限定することは意図されていない。当業者には多くの修正および変形形態が明らかとなろう。実施形態は、本発明の原理、実用的な応用例を最も良く説明するため、ならびに他の当業者が企図された特定の使用に好適な様々な修正を伴う様々な実施形態に関して本発明を理解できるようにするために、選択および記載されたものである。さらに、上記では装置に関して説明したが、当分野のニーズは、廃棄操作を管理する方法、廃棄操作を管理するための命令を含むコンピュータ・プログラム、または廃棄操作を管理するためのコンピューティング・システムにコンピュータ読み取り可能コードを組み込むことを有するコンピューティング・インフラストラクチャをデプロイするための方法によっても満たすことができる。
【図面の簡単な説明】
【００１８】
【図１】例示的なデータ保存デバイスを示すブロック図である。
【図２】本発明の廃棄管理がインプリメント可能なストレージ・コントローラを示すブロック図である。
【図３】例示的な論理ボリュームを示す図である。
【図４】廃棄コマンドとして使用可能なＳＣＳＩ ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドのビットを示す図である。
【図５】廃棄コマンドのビットの値に基づいて選択される可能な廃棄ポリシーを示すテーブルである。
【図６】廃棄コマンドのビットの値に基づいて選択される可能な廃棄ポリシーを示す代替のテーブルである。
【符号の説明】
【００１９】
２００ ストレージ・コントローラ
２０２ インターフェース
２０４ インターフェース
２０６ プロセッサ
２１０ メモリ
２１２ 廃棄管理
２５０ ホスト
２６０ ネットワーク
２７０ ドライブまたはアレイ
３００ 論理ボリューム
【特許請求の範囲】
【請求項１】
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリを作成するステップと、
前記廃棄ポリシー・エントリをストレージ・コントローラに格納するステップと、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するステップと、
前記ボリュームに関する前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するステップと、
を有する、ストレージ・メディア上に格納されたデータを廃棄するための方法。
【請求項２】
前記廃棄ポリシー・エントリを作成するステップが、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を確立するステップと、
前記メディアの場所で書き込むパターンを確立するステップと、
を有する、請求項１に記載の方法。
【請求項３】
前記廃棄ポリシー・エントリを作成するステップが、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、フラグを第１の状態に設定するステップと、
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、フラグを第２の状態に設定するステップと、
をさらに有する、請求項２に記載の方法。
【請求項４】
前記廃棄ポリシー・エントリを作成するステップが、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを確立するステップを有し、
前記廃棄コマンドを受信するステップが、前記複数の廃棄ポリシー・エントリのうちのいずれが実行される予定であるかの指令を受信するステップを有し、
前記廃棄コマンドを実行するステップが、前記廃棄コマンドに示された前記ポリシー・エントリに従って前記ボリュームを廃棄するステップを有する、
請求項１に記載の方法。
【請求項５】
前記廃棄コマンドを受信するステップが、ＳＣＳＩコマンド・インターフェースを介して前記廃棄コマンドを受信するステップを有する、請求項４に記載の方法。
【請求項６】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項５に記載の方法。
【請求項７】
Ｎは２に等しく、それによって前記複数の可能な廃棄ポリシー・エントリの数は４である、請求項６に記載の方法。
【請求項８】
前記Ｎビットが前記ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内にＮ個のベンダー特定ビットを有する、請求項６に記載の方法。
【請求項９】
前記複数の可能な廃棄ポリシー・エントリを確立するステップが、前記ボリュームに関するテーブルを作成するステップを有し、
前記テーブルを作成するステップが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリを確立するステップと、
前記メディアの場所で書き込むパターンを示す第２のエントリを確立するステップと、
を有する、請求項４に記載の方法。
【請求項１０】
前記テーブルを作成するステップが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリを確立するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するステップをさらに含む、請求項１に記載の方法。
【請求項１３】
ホスト・デバイスが接続される際に介するホスト・インターフェースと、
ストレージ・デバイスが接続される際に介するストレージ・インターフェースと、
プロセッサと、
前記ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリと、
前記プロセッサによって実行された場合、
前記ボリュームを廃棄する旨のコマンドを前記ホスト・デバイスから受信するように、および
前記格納された廃棄ポリシー・エントリに従って前記ボリュームを廃棄する旨を指示するように、
動作可能な、廃棄管理ソフトウェアと、
を有する、ストレージ・コントローラ。
【請求項１４】
前記廃棄ポリシー・エントリが、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数と、
前記メディアの場所で書き込むパターンの指令と、
を有する、請求項１３に記載のストレージ・コントローラ。
【請求項１５】
前記廃棄ポリシー・エントリが、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
フラグをさらに有する、請求項１４に記載のストレージ・コントローラ。
【請求項１６】
前記廃棄ポリシー・エントリが、それによって前記受信したコマンドが複数の可能な廃棄ポリシー・エントリのうちのいずれが実行されることになるかの指令を含む、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを有する、請求項１３に記載のストレージ・コントローラ。
【請求項１７】
前記ホスト・インターフェースがＳＣＳＩコマンド・インターフェースを有する、請求項１６に記載のストレージ・コントローラ。
【請求項１８】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項１７に記載のストレージ・コントローラ。
【請求項１９】
Ｎは２に等しく、それによって前記複数の可能な廃棄ポリシー・エントリの数は４である、請求項１８に記載のストレージ・コントローラ。
【請求項２０】
前記Ｎビットが前記ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内にＮ個のベンダー特定ビットを有する、請求項１８に記載のストレージ・コントローラ。
【請求項２１】
可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリと、
前記メディアの場所で書き込むパターンを示す第２のエントリと、
を含む、前記複数の廃棄ポリシー・エントリを格納するためのテーブルをさらに有する、請求項１６に記載のストレージ・コントローラ。
【請求項２２】
前記テーブルが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリをさらに含む、請求項２１に記載のストレージ・コントローラ。
【請求項２３】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップをさらに含む、請求項１３に記載のストレージ・コントローラ。
【請求項２４】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するステップをさらに含む、請求項１３に記載のストレージ・コントローラ。
【請求項２５】
ストレージ・メディア上に格納されたデータを廃棄するために具体化されたコンピュータ読み取り可能コードを有する、プログラム可能コンピュータで使用可能なコンピュータ読み取り可能メディアに記録されるコンピュータ・プログラムであって、前記コンピュータ読み取り可能コードが、
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリを作成するため、
前記廃棄ポリシー・エントリをストレージ・コントローラに格納するため、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するため、および
前記ボリュームに関する前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するため、
の命令を有する、コンピュータ・プログラム。
【請求項２６】
前記廃棄ポリシー・エントリを作成するための命令が、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を確立するため、および
前記メディアの場所で書き込むパターンを確立するため、
の命令を有する、請求項２５に記載のコンピュータ・プログラム。
【請求項２７】
前記廃棄ポリシー・エントリを作成するための命令が、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、フラグを第１の状態に設定するため、および
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、フラグを第２の状態に設定するため、
の命令をさらに有する、請求項２６に記載のコンピュータ・プログラム。
【請求項２８】
前記廃棄ポリシー・エントリを作成するための命令が、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを確立するための命令を有し、
前記廃棄コマンドを受信するための命令が、前記複数の廃棄ポリシー・エントリのうちのいずれが実行される予定であるかの指令を受信するための命令を有し、
前記廃棄コマンドを実行するための命令が、前記廃棄コマンドに示された前記ポリシー・エントリに従って前記ボリュームを廃棄するための命令を有する、
請求項２５に記載のコンピュータ・プログラム。
【請求項２９】
前記複数の可能な廃棄ポリシー・エントリを確立するための命令が、前記ボリュームに関するテーブルを作成するための命令を有し、
前記テーブルを作成するための命令が、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリを確立するため、および
前記メディアの場所で書き込むパターンを示す第２のエントリを確立するため、
の命令を有する、請求項２８に記載のコンピュータ・プログラム。
【請求項３０】
前記テーブルを作成するための命令が、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリを確立するための命令をさらに含む、請求項２９に記載のコンピュータ・プログラム。
【請求項３１】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するための命令をさらに含む、請求項２５に記載のコンピュータ・プログラム。
【請求項３２】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するための命令をさらに含む、請求項２５に記載のコンピュータ・プログラム。
【請求項３３】
コンピュータ読み取り可能コードをコンピューティング・システムに組み込むステップを有し、前記コードは前記コンピューティング・システムと組み合わせて、
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する複数の可能な廃棄ポリシー・エントリを作成するステップと、
前記可能な廃棄ポリシー・エントリをストレージ・コントローラに格納するステップと、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するステップであって、前記廃棄コマンドは前記複数の廃棄ポリシー・エントリのうちのいずれが実行されることになるかの指令を含む、受信するステップと、
前記廃棄コマンドに示された前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するステップと、
を実行することが可能な、コンピューティング・インフラストラクチャをデプロイするための方法。
【請求項３４】
前記複数の可能な廃棄ポリシー・エントリのそれぞれを作成するステップが、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を示す第１のパラメータを確立するステップと、
前記メディアの場所で書き込むパターンを示すパラメータ・エントリを確立するステップと、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のパラメータを確立するステップと、
を有する、請求項３３に記載の方法。
【請求項３５】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップおよび前記ボリュームの一部を廃棄するステップを有するグループから１つの操作を選択するステップをさらに有する、請求項３３に記載の方法。
【請求項３６】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項３３に記載の方法。
【請求項１】
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリを作成するステップと、
前記廃棄ポリシー・エントリをストレージ・コントローラに格納するステップと、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するステップと、
前記ボリュームに関する前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するステップと、
を有する、ストレージ・メディア上に格納されたデータを廃棄するための方法。
【請求項２】
前記廃棄ポリシー・エントリを作成するステップが、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を確立するステップと、
前記メディアの場所で書き込むパターンを確立するステップと、
を有する、請求項１に記載の方法。
【請求項３】
前記廃棄ポリシー・エントリを作成するステップが、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、フラグを第１の状態に設定するステップと、
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、フラグを第２の状態に設定するステップと、
をさらに有する、請求項２に記載の方法。
【請求項４】
前記廃棄ポリシー・エントリを作成するステップが、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを確立するステップを有し、
前記廃棄コマンドを受信するステップが、前記複数の廃棄ポリシー・エントリのうちのいずれが実行される予定であるかの指令を受信するステップを有し、
前記廃棄コマンドを実行するステップが、前記廃棄コマンドに示された前記ポリシー・エントリに従って前記ボリュームを廃棄するステップを有する、
請求項１に記載の方法。
【請求項５】
前記廃棄コマンドを受信するステップが、ＳＣＳＩコマンド・インターフェースを介して前記廃棄コマンドを受信するステップを有する、請求項４に記載の方法。
【請求項６】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項５に記載の方法。
【請求項７】
Ｎは２に等しく、それによって前記複数の可能な廃棄ポリシー・エントリの数は４である、請求項６に記載の方法。
【請求項８】
前記Ｎビットが前記ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内にＮ個のベンダー特定ビットを有する、請求項６に記載の方法。
【請求項９】
前記複数の可能な廃棄ポリシー・エントリを確立するステップが、前記ボリュームに関するテーブルを作成するステップを有し、
前記テーブルを作成するステップが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリを確立するステップと、
前記メディアの場所で書き込むパターンを示す第２のエントリを確立するステップと、
を有する、請求項４に記載の方法。
【請求項１０】
前記テーブルを作成するステップが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリを確立するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するステップをさらに含む、請求項１に記載の方法。
【請求項１３】
ホスト・デバイスが接続される際に介するホスト・インターフェースと、
ストレージ・デバイスが接続される際に介するストレージ・インターフェースと、
プロセッサと、
前記ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリと、
前記プロセッサによって実行された場合、
前記ボリュームを廃棄する旨のコマンドを前記ホスト・デバイスから受信するように、および
前記格納された廃棄ポリシー・エントリに従って前記ボリュームを廃棄する旨を指示するように、
動作可能な、廃棄管理ソフトウェアと、
を有する、ストレージ・コントローラ。
【請求項１４】
前記廃棄ポリシー・エントリが、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数と、
前記メディアの場所で書き込むパターンの指令と、
を有する、請求項１３に記載のストレージ・コントローラ。
【請求項１５】
前記廃棄ポリシー・エントリが、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
フラグをさらに有する、請求項１４に記載のストレージ・コントローラ。
【請求項１６】
前記廃棄ポリシー・エントリが、それによって前記受信したコマンドが複数の可能な廃棄ポリシー・エントリのうちのいずれが実行されることになるかの指令を含む、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを有する、請求項１３に記載のストレージ・コントローラ。
【請求項１７】
前記ホスト・インターフェースがＳＣＳＩコマンド・インターフェースを有する、請求項１６に記載のストレージ・コントローラ。
【請求項１８】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項１７に記載のストレージ・コントローラ。
【請求項１９】
Ｎは２に等しく、それによって前記複数の可能な廃棄ポリシー・エントリの数は４である、請求項１８に記載のストレージ・コントローラ。
【請求項２０】
前記Ｎビットが前記ｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドの制御バイト内にＮ個のベンダー特定ビットを有する、請求項１８に記載のストレージ・コントローラ。
【請求項２１】
可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリと、
前記メディアの場所で書き込むパターンを示す第２のエントリと、
を含む、前記複数の廃棄ポリシー・エントリを格納するためのテーブルをさらに有する、請求項１６に記載のストレージ・コントローラ。
【請求項２２】
前記テーブルが、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリをさらに含む、請求項２１に記載のストレージ・コントローラ。
【請求項２３】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップをさらに含む、請求項１３に記載のストレージ・コントローラ。
【請求項２４】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するステップをさらに含む、請求項１３に記載のストレージ・コントローラ。
【請求項２５】
ストレージ・メディア上に格納されたデータを廃棄するために具体化されたコンピュータ読み取り可能コードを有する、プログラム可能コンピュータで使用可能なコンピュータ読み取り可能メディアに記録されるコンピュータ・プログラムであって、前記コンピュータ読み取り可能コードが、
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する廃棄ポリシー・エントリを作成するため、
前記廃棄ポリシー・エントリをストレージ・コントローラに格納するため、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するため、および
前記ボリュームに関する前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するため、
の命令を有する、コンピュータ・プログラム。
【請求項２６】
前記廃棄ポリシー・エントリを作成するための命令が、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を確立するため、および
前記メディアの場所で書き込むパターンを確立するため、
の命令を有する、請求項２５に記載のコンピュータ・プログラム。
【請求項２７】
前記廃棄ポリシー・エントリを作成するための命令が、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、フラグを第１の状態に設定するため、および
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、フラグを第２の状態に設定するため、
の命令をさらに有する、請求項２６に記載のコンピュータ・プログラム。
【請求項２８】
前記廃棄ポリシー・エントリを作成するための命令が、前記ボリュームに関する複数の可能な廃棄ポリシー・エントリを確立するための命令を有し、
前記廃棄コマンドを受信するための命令が、前記複数の廃棄ポリシー・エントリのうちのいずれが実行される予定であるかの指令を受信するための命令を有し、
前記廃棄コマンドを実行するための命令が、前記廃棄コマンドに示された前記ポリシー・エントリに従って前記ボリュームを廃棄するための命令を有する、
請求項２５に記載のコンピュータ・プログラム。
【請求項２９】
前記複数の可能な廃棄ポリシー・エントリを確立するための命令が、前記ボリュームに関するテーブルを作成するための命令を有し、
前記テーブルを作成するための命令が、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームが格納される前記メディアの場所で実行されることになる書き込みパスの数を示す第１のエントリを確立するため、および
前記メディアの場所で書き込むパターンを示す第２のエントリを確立するため、
の命令を有する、請求項２８に記載のコンピュータ・プログラム。
【請求項３０】
前記テーブルを作成するための命令が、可能な各廃棄ポリシー・エントリに関して、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のエントリを確立するための命令をさらに含む、請求項２９に記載のコンピュータ・プログラム。
【請求項３１】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するための命令をさらに含む、請求項２５に記載のコンピュータ・プログラム。
【請求項３２】
前記ストレージ・デバイスが機能低下状態にある場合、前記ボリュームの一部を廃棄するための命令をさらに含む、請求項２５に記載のコンピュータ・プログラム。
【請求項３３】
コンピュータ読み取り可能コードをコンピューティング・システムに組み込むステップを有し、前記コードは前記コンピューティング・システムと組み合わせて、
ストレージ・デバイスのストレージ・メディア上の場所に格納されたデータ・ボリュームに関する複数の可能な廃棄ポリシー・エントリを作成するステップと、
前記可能な廃棄ポリシー・エントリをストレージ・コントローラに格納するステップと、
前記ストレージ・コントローラで、前記ボリュームを廃棄する旨のコマンドをホスト・デバイスから受信するステップであって、前記廃棄コマンドは前記複数の廃棄ポリシー・エントリのうちのいずれが実行されることになるかの指令を含む、受信するステップと、
前記廃棄コマンドに示された前記ポリシー・エントリに従って、前記ボリュームを廃棄する旨の前記コマンドを前記ストレージ・コントローラで実行するステップと、
を実行することが可能な、コンピューティング・インフラストラクチャをデプロイするための方法。
【請求項３４】
前記複数の可能な廃棄ポリシー・エントリのそれぞれを作成するステップが、
前記ボリュームが格納された前記メディアの場所で実行されることになる書き込みパスの数を示す第１のパラメータを確立するステップと、
前記メディアの場所で書き込むパターンを示すパラメータ・エントリを確立するステップと、
前記ボリュームのパリティ領域が複数の書き込みパスのそれぞれで更新される予定の場合、第１の状態に設定され、
前記ボリュームのパリティ領域が前記複数の書き込みパスのうちの第１の書き込みパスでのみ更新される予定の場合、第２の状態に設定される、
第３のパラメータを確立するステップと、
を有する、請求項３３に記載の方法。
【請求項３５】
前記ストレージ・デバイスが機能低下状態にある場合、前記廃棄コマンドの実行を終了するステップおよび前記ボリュームの一部を廃棄するステップを有するグループから１つの操作を選択するステップをさらに有する、請求項３３に記載の方法。
【請求項３６】
前記廃棄コマンドがＮビットのｗｒｉｔｅ＿ｖｅｒｉｆｙコマンドを有する、請求項３３に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００６−２３６３４３（Ｐ２００６−２３６３４３Ａ）
【公開日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願番号】特願２００６−３９２３６（Ｐ２００６−３９２３６）
【出願日】平成１８年２月１６日（２００６．２．１６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願日】平成１８年２月１６日（２００６．２．１６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]