JP2022550462A - 書き込み回数制限による不揮発性メモリの長寿命化 - Google Patents

Abstract

ストレージデバイスへの書き込みサイクルを制限する方法は、第１のサブシステムによって実行されるメモリへの書き込みの第１のセットの第１のカウントを追跡し、第１のカウントが第１のサブシステムの書き込み閾値を満たすことを判定することを含む。方法は、第１のカウントが第１のサブシステムの書き込み閾値を超えることに基づきブロッキング基準が第１のサブシステムによって満たされることを判定することと、ブロッキング基準がコンピューティングデバイスの第２のサブシステムによって満たされないことを判定することを含む。方法は、ブロッキング基準が第１のサブシステムによって満たされることに基づき第１のセットの書き込みがストレージデバイスに同期されることをブロックすることと、ブロッキング基準が第２のサブシステムによって満たされないことに基づき第２のサブシステムのメモリコンテンツをストレージデバイスに同期させることを含む。

Description

技術分野
本発明の様々な実装は、不揮発性メモリに関し、より詳細には、不揮発性メモリの寿命を延長するための書き込みサイクルの制限に関するものである。

背景
フラッシュストレージは、電気的に書き込みと消去が可能な不揮発性コンピュータメモリの一形態である。フラッシュストレージは、他の形態の不揮発性メモリと比較して様々な利点を有する。例えば、フラッシュストレージは、より経済的で信頼性が高く、より低い電力消費要件を有する。現在、スマートフォンやメモリースティック、デジタルオーディオプレーヤー、科学機器などに幅広く利用されている。

概要
一実装形態では、ストレージデバイスへの書き込みサイクルを制限する方法は、コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの書き込みの第１のセットの第１のカウントを追跡し、さらに、第１のカウントが第１のサブシステムの書き込み閾値を満たすことを決定することを含む。本方法は、第１のカウントが第１のサブシステムの書き込み閾値を超えることに基づいて、ブロッキング基準が第１のサブシステムによって満たされることを判定することと、さらに、ブロッキング基準がコンピューティングデバイスの第２のサブシステムによって満たされないことを判定することとを含む。この方法は、ブロッキング基準が第１のサブシステムによって満たされることに基づいて、第１のセットの書き込みがストレージデバイスに同期されることをブロックすることと、ブロッキング基準が第２のサブシステムによって満たされないことに基づいて、第２のサブシステムのメモリコンテンツをストレージデバイスに同期させることとを含む。

別の実施態様では、ストレージデバイスへの書き込みサイクルを制限するためのコンピュータプログラムプロダクトは、その上に具現化されたプログラム命令を有するコンピュータ可読ストレージ媒体を含む。プログラム命令は、プロセッサにある方法を実行させるためにプロセッサによって実行可能である。本方法は、コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの書き込みの第１のセットの第１のカウントを追跡し、さらに、第１のカウントが第１のサブシステムの書き込み閾値を満たすことを決定することを含む。本方法は、第１のカウントが第１のサブシステムの書き込み閾値を超えることに基づいて、ブロッキング基準が第１のサブシステムによって満たされることを判定することと、さらに、ブロッキング基準がコンピューティングデバイスの第２のサブシステムによって満たされないことを判定することとを含む。この方法は、ブロッキング基準が第１のサブシステムによって満たされることに基づいて、第１のセットの書き込みがストレージデバイスに同期されることをブロックすることと、ブロッキング基準が第２のサブシステムによって満たされないことに基づいて、第２のサブシステムのメモリコンテンツをストレージデバイスに同期させることとを含む。

さらに別の実施態様では、コンピューティングデバイスは、プロセッサと、メモリとを含む。プロセッサは、コンピュータ可読命令を実行するように構成され、メモリは、プロセッサによって実行されると、プロセッサに動作を実行させるコンピュータ可読命令を格納するように構成される。動作は、コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの書き込みの第１のセットの第１のカウントを追跡し、さらに、第１のカウントが第１のサブシステムの書き込み閾値を満たすことを判定することを含む。操作は、第１のカウントが第１のサブシステムの書き込み閾値を超えることに基づいて、ブロッキング基準が第１のサブシステムによって満たされることを判定することと、コンピューティングデバイスの第２のサブシステムによってブロッキング基準が満たされないことを判定することとを含む。動作は、ブロッキング基準が第１のサブシステムによって満たされることに基づいて、第１のセットの書き込みがストレージデバイスに同期されることをブロックすることと、ブロッキング基準が第２のサブシステムによって満たされないことに基づいて、第２のサブシステムのメモリコンテンツをストレージデバイスに同期させることとを含む。

これらの例示的な態様および特徴は、現在説明されている主題を制限または定義するためではなく、本願で説明される概念の理解を助けるために例を提供するために言及されている。現在説明されている主題の他の態様、利点、および特徴は、本出願全体を検討した後に明らかになるであろう。

本開示のこれらおよび他の特徴、態様、および利点は、以下の詳細な説明を添付図面を参照しながら読むと、よりよく理解される。

図１は、本明細書に記載される発明の特定の実施態様による、ストレージデバイスの寿命を保護するためのストレージ保護システムの概念図である。 図２は、本発明の特定の実施態様による、ストレージ保護システムが実行可能なコンピューティングデバイス、具体的にはユーティリティメータのアーキテクチャ図である。 図３は、本発明の特定の実施態様による、ストレージデバイスの寿命を保護するためにストレージデバイスへの書き込みを管理するための方法のフロー図である。 図４は、本発明の特定の実施態様による、ストレージデバイスの寿命を保護するように、違反を犯したサブシステムのブラックリストを管理するための方法のフロー図である。

詳細な説明

ＮＡＮＤや組み込みマルチメディアコントローラ（ｅＭＭＣ）などのフラッシュストレージ技術を利用するデバイスは、実行された書き込みおよび消去操作（すなわち、書き込みサイクル）の累積数の関数である限られた寿命を有する。書き込みサイクルが実行されると、フラッシュストレージは老化し、フラッシュストレージに書き込まれたデータは破損してしまう。具体的には、書き込み回数が多くなると、記憶保持時間（メモリに書き込まれたデータが有効である時間）が短くなる。最終的には、フラッシュストレージのあるブロックに対して多数の書き込みサイクルが発生すると、そのブロックは保持期間が極端に短くなり、使い物にならなくなる可能性がある。この書き込みサイクルによる老化現象は、不可逆的である。デバイスの様々なアプリケーションは、通常、デバイス上の不揮発性メモリを共有する。そのため、あるアプリケーションが誤動作したり、悪意を持って多数の書き込みサイクルを実行したりすると、結果として不揮発性メモリに障害が発生し、デバイス上の他のアプリケーションに影響を与える可能性がある。このように、多数の書き込みサイクルによって引き起こされる保持力の低下は、ソフトウェアの動作によって引き起こされ得るハードウェア障害である。

フラッシュストレージの保持期間に対する書き込みサイクルの影響により、フラッシュストレージの使用は、長期使用を意図したデバイスに組み込むことが不可能になっている。フラッシュドライブやスマートフォンなどのライフサイクルの短いデバイスは、しばしばフラッシュストレージを使用するが、何年もの寿命を意図した製品は、通常、磁気ストレージデバイスなどの他の何らかのストレージ技術を使用する。その結果、フラッシュストレージの利点は、そのようなデバイスに組み込まれず、これらのデバイスが、製造によりコストがかかるか、信頼性が低いか、またはより大きな電力要件を有するようになる方向に向かう。

本明細書で説明する実施態様では、ストレージ保護システムは、試行された書き込みの数を追跡し、これは、完了した書き込みと本明細書で説明するようにブロックされた書き込みの両方を含むことができる。サブシステムの試行された書き込みが、過剰を表すとみなされる書き込み閾値を満たす（例えば、等しいかまたは超える）場合、ストレージ保護システムは、この過剰を改善するための措置を講じることができる。例えば、ストレージ保護システムは、サブシステムを中断または停止してもよく、またはストレージ保護システムは、デバイス全体を再起動してもよい。したがって、本明細書で説明する実装は、サブシステムの書き込みサイクルを関連する書き込み閾値に制限する。さらに、いくつかの実装では、ストレージ保護システムは、ホワイトリストおよびブラックリストを維持する。ホワイトリスト上のサブシステムは、その書き込みサイクルが制限されることを免除されてもよく、一方、ブラックリスト上のサブシステムは、それぞれの書き込み閾値を満たした履歴を有するために、より厳しい罰則の対象となりうる。このように、発生する書き込みサイクルを制限することによって、ストレージデバイスの寿命が保護され得る。

装置のサブシステムの様々な書き込み閾値は、装置の所望の寿命に基づいて選択されてもよい。サブシステムにそのような書き込み閾値に従うか、または改善のリスクを負うことを要求することによって、ストレージ保護システムは、したがって、ストレージデバイス上で発生する書き込みサイクルを制限することができる。ストレージデバイスの寿命は書き込みサイクルの数に基づいているので、ストレージ保護システムは、このように、寿命が期待通りであることを保証し得る。その結果、デバイスの製造業者は、予測できない書き込みサイクルによってそのようなデバイスの寿命が悪影響を受けることを懸念せずにフラッシュストレージを利用することができ、また、本明細書で説明する実装は、書き込みサイクルに関して期待されるパラメータ内でデバイスが動作することを保証することができるので、その製造業者は、デバイス仕様を作成する際にそのようなデバイスの寿命をより正確に提供することができる。

図１は、本明細書に記載される発明の特定の実施態様による、ストレージデバイス１１０の寿命を保護するためのストレージ保護システム１００の概念図である。図１に示すように、ストレージ保護システム１００は、デスクトップコンピュータ、ノートブックコンピュータ、ユーティリティメータ、またはフラッシュストレージを利用する他のコンピューティングデバイス１２０に統合されてもよい。

コンピューティングデバイス１２０は、処理ユニット１３０、メモリ１４０、および本明細書においてストレージ１１０とも呼ばれるストレージデバイス１１０を含んでもよい。処理ユニット１３０は、メモリ１４０またはストレージ１１０に格納されたプログラムコードを実行するように構成されてもよい。例えば、処理ユニット１３０は、マイクロプロセッサであってもよいし、処理ユニット１３０は、メモリ１４０もしくはストレージ１１０、またはその両方が統合されたマイクロコントローラであってもよい。メモリ１４０は、データを格納し、処理ユニット１３０によって実行されるプログラムコードを格納するように構成された、ランダムアクセスメモリ（ＲＡＭ）などの揮発性メモリの一形態であってよい。ストレージ１１０は、データ及びプログラムコードを格納するように構成された不揮発性メモリであってもよい。例えば、ストレージ１１０は、ＮＡＮＤまたはｅＭＭＣなどのフラッシュストレージの一形態である。

いくつかの実装では、ストレージ保護システム１００は、サブシステムモニタ１５０およびブラックリストマネージャ１６０を含み、これらの各々は、コンピューティングデバイス１２０上で実行されてもよく、コンピューティングデバイス１２０と通信していてもよい。サブシステムモニタ１５０は、書き込み閾値のセットを利用してもよく、各書き込み閾値は、コンピューティングデバイス１２０の対応するサブシステム１７０に関連付けられる。具体的には、各書き込み閾値は、時間間隔（例えば、１時間）内に対応するサブシステム１７０によって実行されることを許可される書き込みサイクルの数を示すことができる。それぞれの書き込み閾値と比較した、間隔中にサブシステム１７０によって実行された書き込み試行に基づき、サブシステムモニタ１５０は、書き込み試行をブロックするか、サブシステム１７０をブラックリストに登録するか、または他の改善措置を実行してもよい。ブラックリストマネージャ１６０は、ブラックリスト１８０上のサブシステム１７０を管理してもよく、それらのサブシステム１７０に対して改善措置を実行してもよく、または必要に応じてブラックリスト１８０からそれらのサブシステム１７０を解放してもよい。

サブシステム１７０は、例えば、コンピューティングデバイス１２０にインストールされたアプリケーションパッケージ、オペレーティングシステム、または共通のタスクに向けて動作する１つ以上のプロセスのセットであり得る。サブシステム１７０は、１つまたは複数の関連するプロセスを含むことができ、サブシステム１７０に関連するそれらのプロセスを通じて書き込みを実行することができる。いくつかの実装では、コンピューティングデバイス１２０の設計者（例えば、製造者またはサービスプロバイダ）は、サブシステム１７０を定義する；例えば、設計者は、どのプロセスが一緒になってサブシステム１７０を形成するかを定義する。設計者は、さらに、各サブシステム１７０に対応する書き込み閾値を決定してもよい。いくつかの実装では、違反行為（例えば、そのそれぞれの書き込み閾値を超える）を犯したサブシステム１７０は、停止、強制終了、または書き込みアクセスの拒否などの改善措置のリスクを負う。

コンピューティングデバイス１２０の様々なサブシステム１７０に対する書き込み閾値を選択するために、設計者は、コンピューティングシステムに対する所望の寿命を決定することができる。ストレージ１１０の耐久性（すなわち、メモリブロックが使用不能になるまでの書き込みサイクル数）および所望の寿命に基づいて、設計者は、コンピューティングデバイス１２０が所望の寿命の間使用可能であり続けるように、その寿命を達成するための間隔（例えば、１日あたり）ごとの書き込みサイクルの総数を決定してもよい。設計者は、各そのような割り当てが書き込み閾値になるように、または書き込み閾値の基礎となるように、間隔あたりの書き込みサイクルの数をコンピューティングデバイス１２０に最初にインストールされた様々なサブシステム１７０に割り当ててもよい。各サブシステム１７０が、インターバルごとに同じ数の書き込みサイクルを割り当てるということは必要ない。むしろ、例えば、標準的な使用中に多くの書き込みを実行すると予想されるサブシステムが、標準的な使用中に少ない書き込みを実行すると予想されるサブシステムと比較して、間隔あたりの書き込みサイクルのより大きな部分を割り当てるように、割り当ては予想使用に基づいてもよい。

いくつかの実装では、様々な書き込み閾値は、コンピューティングデバイス１２０、たとえば、ストレージ１１０の専用パーティションに格納されてもよい。さらに、いくつかの実装では、書き込み閾値は動的である。例えば、新しいサブシステム１７０がコンピューティングデバイス１２０に追加されたとき、または書き込み閾値の対象とならない重要なプロセスが予想以上の書き込みを実行するとき、発生したまたは発生すると予想される追加の書き込みを収容するためにコンピューティングデバイス１２０の種々の書き込み閾値は下方調整されてもよい。例えば、新しいサブシステム１７０がコンピューティングデバイスに追加されたとき、例えば、サードパーティアプリケーションがインストールされたとき、他のサブシステム１７０の書き込み閾値は、新しいサブシステム１７０のための新しい書き込み閾値の追加に対応するために下方に調整されてもよい。具体的には、いくつかの実装では、新しい書き込み閾値は、他のサブシステム１７０の書き込み閾値から減算された書き込み量に等しいか、さもなければ、それに基づくものであってよい。書き込み閾値が調整されるとき、書き込み閾値の格納された値は、新しい値に調整されてもよい。動的書き込み閾値の使用を通じて、コンピューティングデバイス１２０においてサブシステム１７０が変化しても、ストレージ１１０の寿命は保護されることが可能である。

いくつかの実装では、ストレージ保護システム１００は、ホワイトリスト１９０、ブラックリスト１８０、またはその両方を利用する。ホワイトリスト１９０は、以下でさらに説明するように、好まれるサブシステム１７０を含んでもよく、ブラックリスト１８０は、好まれないサブシステム１７０を含んでもよい。いくつかの実装では、図１に示すように、ブラックリスト１８０は、ブラックリスト化されたサブシステム１７０への参照のセットとして実装され、ホワイトリスト１９０は、ホワイトリスト化されたサブシステム１７０への参照のセットとして実装される。

ホワイトリスト１９０は、書き込み閾値なしで自由に動作することが許可されているサブシステム１７０、または、書き込み閾値が事実上存在しないほど高く設定されているサブシステム１７０を含むことができる。いくつかの実装では、サブシステム１７０は、設計時にホワイトリスト１９０に追加され、ホワイトリスト１９０への追加は永続的である。さらに、いくつかの実装では、ホワイトリスト１９０は、コンピューティングデバイス１２０の管理者により手動で修正され得る。ホワイトリストされたサブシステム１７０は、例えば、ストレージ保護システム１００自体のプロセス、重要なプロセス、信頼できるプロセス、バーストで書き込みアクティビティを生成すると予想されるプロセス、またはデバッグのために利用されるプロセスなどを含むことができる。

ブラックリスト１８０は、その書き込み閾値を１回以上満たすという形で違反を犯したサブシステムを含んでもよい。違反を犯した結果、およびブラックリスト１８０に載った結果、サブシステム１７０は、ストレージ保護システム１００から罰則またはより厳しい要件に直面する可能性がある。例えば、ブラックリストに載ったサブシステム１７０は、ストレージ１１０への書き込みをブロックされてもよいし、以下に説明するような他の改善措置を受けてもよい。

ブラックリスト１８０及びホワイトリスト１９０は、様々な方法で実装することができる。例えば、ブラックリスト１８０とホワイトリスト１９０のそれぞれについて、ストレージ保護システム１００は、リストを表すデータ構造を維持してもよい。さらに、または代替的に、各サブシステム１７０は、サブシステム１７０がブラックリスト、ホワイトリスト、またはそのどちらでもないかを示すステータスと関連付けられる場合がある。例えば、ストレージ保護システム１００は、各サブシステム１７０をその関連するステータスにマッピングするテーブルまたは他のデータ構造を維持してもよく、または各サブシステム１７０は、それぞれのステータスを表す変数を含むまたは関連付けられるデータ構造によって表現されてもよい。そのような実装では、サブシステム１７０がブラックリスト１８０上にあるか、ホワイトリスト１９０上にあるか、またはそのどちらでもないかを決定することは、サブシステム１７０に関連付けられたステータスを決定することを含んでもよい。

いくつかの実装では、サブシステム１７０のステータスがブラックリストである場合、サブシステム１７０はブラックリスト１８０上にあると見なされてもよい。同様に、サブシステム１７０がブラックリスト１８０上にある場合、サブシステム１７０は、ブラックリストのステータスを有するとみなされてもよい。さらに、サブシステムのステータスがブラックリストに変更された場合、サブシステム１７０はブラックリスト１８０に追加されたとみなされてもよく、サブシステムのステータスがブラックリストから他のステータス（例えば、非ブラックリスト）に変更された場合、サブシステム１７０はブラックリスト１８０から削除されたとみなされてもよい。同様に、サブシステム１７０がブラックリスト１８０に追加されたときにサブシステムのステータスがブラックリストに変更されたとみなされ、サブシステム１７０がブラックリスト１８０から削除されたときにサブシステムのステータスが何らかの他のステータス（例えば、非ブラックリスト）に変更されたとみなされてもよい。同様に、サブシステム１７０のステータスがホワイトリストのステータスを有する場合、サブシステム１７０はホワイトリスト１９０上にあるとみなされてもよく、サブシステム１７０がホワイトリスト１９０上にある場合、そのサブシステム１７０はホワイトリストのステータスを有するとみなされてもよい。

上述したように、ブラックリスト１８０上のサブシステム１７０に対して、様々な改善措置が取られてもよい。しかし、いくつかの実装では、そのような改善措置が取られる前に、ストレージ保護システム１００は、どのサブシステム１７０が違反を犯しているかを特定しなければならない。いくつかの実装では、サブシステムモニタ１５０は、試みられた書き込みを監視し、違反を犯しているサブシステム１７０のストレージ１１０への書き込みアクセスをブロックし、違反を犯しているサブシステム１７０をブラックリスト化するように構成される。

サブシステムモニタ１５０は、ハードウェア、ソフトウェア、またはその両方の組み合わせとして実装され得る。例えば、サブシステムモニタ１５０は、処理ユニット１３０によって実行されるプログラムコードとして実装されてもよく、またはサブシステムモニタ１５０は、専用のハードウェアデバイスとして実装されてもよい。いくつかの実装では、サブシステムモニタ１５０は、信頼されたステータスを有し、したがって、メモリ１４０への書き込みを監視し、（例えば、ストレージ１１０への直接書き込みをブロックすることによって、またはストレージ１１０へのメモリコンテンツの同期をブロックすることによって）ストレージ１１０への書き込みをブロックし、または（例えば、ストレージへの直接書き込みを許可することによって、またはストレージ１１０へのメモリコンテンツの同期を許可することによって）ストレージ１１０への書き込みを許容することが可能である。

１つの実装では、サブシステムモニタ１５０は、メモリ１４０のためのドライバを含むか、またはそれにアクセスすることができる。したがって、サブシステム１７０がメモリ１４０に書き込むとき、サブシステムモニタ１５０は、書き込みを追跡し、書き込みをメモリ１４０にメモリコンテンツとして保存することを可能にし、それらのメモリコンテンツがストレージ１１０に同期されたかどうかを決定する。典型的には、プロセスがメモリ１４０にデータを書き込み、そのデータは、コンピューティングデバイス１２０の通常の動作においてストレージ１１０に同期される（すなわち、書き込まれる）。しかしながら、いくつかの実装では、サブシステムモニタ１５０は、メモリ１４０とストレージ１１０との間の同期を中断し、したがって、ストレージへの書き込みが実際に起こるかどうかを制御する。サブシステムモニタ１５０は、本開示で説明したように、サブシステム１７０がその書き込み閾値を満たしていない場合など、特定の条件が満たされたときに、メモリ１４０をストレージ１１０に同期させることを開始することができる。別の実装では、各サブシステム１７０は、データを書き込むためにアプリケーションプログラミングインターフェース（ＡＰＩ）を利用し、ＡＰＩを実装するライブラリは、書き込み動作が実行されるときにサブシステムモニタ１５０を呼び出す。上述したように、サブシステムモニタ１５０は、書き込みがメモリ１４０を修正することを可能にするが、ストレージ１１０への直接書き込みを防止してもよく、メモリ１４０のストレージ１１０への同期を防止してもよい。サブシステムモニタ１５０は、サブシステム１７０がその書き込み閾値を満たしていないときなど、書き込み条件が満たされたとき、メモリ１４０をストレージ１１０に同期させることを開始してもよいし、ストレージ１１０への直接書き込みを許可してもよい。

定期的に、サブシステムモニタ１５０は、コンピューティングデバイス１２０の様々なサブシステム１７０がメモリ１４０にどのように書き込んだかを記述する書き込み統計値を決定してもよい。さらに、または代替的に、いくつかの実装では、サブシステムモニタ１５０は、書き込みが試みられるたびになど、書き込み統計値を連続的に更新する。これらの書き込み統計に基づき、サブシステムモニタ１５０は、どのサブシステム１７０が違反を犯したかを決定してもよい。サブシステムモニタ１５０は、そのようなサブシステム１７０がストレージ１１０に書き込むのをブロックして、そのサブシステム１７０によってメモリ１４０に書き込まれたメモリコンテンツがストレージ１１０に同期されないようにしてもよい。さらに、または代替的に、サブシステムモニタ１５０は、そのようなサブシステム１７０をブラックリスト１８０に追加してもよい。さらに、いくつかの実装では、サブシステムモニタ１５０は、デバッグまたは報告目的のためなど、様々なコンピューティングデバイス１２０の書き込み統計が一緒に集約または比較され得る、ヘッドエンドシステムなどの集中型ロケーションに書き込み統計を報告してもよい。

サブシステムモニタ１５０は、サブシステム１７０が違反を犯した（例えば、その書き込み閾値を満たした）ときに、様々な改善措置を開始するように構成され得る。改善措置は、例えば、サブシステム１７０をブラックリスト１８０に追加し、サブシステム１７０がブラックリスト１８０上にある間、ストレージ１１０への書き込みアクセスを防止すること、違反を記録すること、１回または限定期間ベースで書き込み閾値の超過を許可すること、サブシステム１７０に関連するプロセスを一時的に停止すること、サブシステム１７０に関連するプロセスを終了すること、コンピューティングデバイス１２０を全体としてリセットまたは再起すること、または重要プロセスを除いてコンピューティングデバイス１２０内の種々のサブシステム１７０を終了する（すなわちセーフモードに入る）ことを含んでもよい。これらの改善措置の各々は、それぞれの利点を有する。サブシステム１７０の各違反において、サブシステムモニタ１５０は、１つまたは複数の改善アクションを開始することができる。いくつかの実装では、各サブシステム１７０は、改善措置の所定のセットに関連付けられ、サブシステム１７０が違反を犯したとき、サブシステムモニタ１５０は、違反に応答してその所定のセット内の各改善措置を開始してもよい。

ストレージ１１０への書き込みアクセスを防止する改善措置は、サブシステム１７０がその書き込み閾値を超えること、またはその書き込み閾値を予め定義された程度に超えることを直接防止してもよい。書き込み閾値が満たされたときにストレージ１１０への書き込みを防止する結果、ストレージ保護システム１００は、発生する総書き込みサイクルを制御することによって、ストレージ１１０の寿命を保護することができる。

違反のログを取るという改善措置は、ストレージ保護システム１００またはヘッドエンドシステムなどのリモートシステムが、書き込みの履歴を追跡することを可能にする。そのため、保護システム１００、ヘッドエンドシステム、または何らかの他のシステムまたはエンティティは、コンピューティングデバイス１２０が異常な動作をしているかどうかを識別することができ、または異常なサブシステム１７０を識別することができる。

書き込み閾値が１回限りまたは限定期間ベースで満たされることを可能にするという改善措置は、サブシステム１７０がそれぞれの書き込み閾値に関してある程度の余裕を持つことを可能にし得る。例えば、１回限りまたはまれなベースで書き込みのバーストを経験するサブシステム１７０の場合、そのようなバーストは、ストレージ１１０の寿命に影響を与える可能性がない場合がある。しかし、この場合、書き込み閾値を満たすことの発生を記録して、今後一定期間（例えば、サブシステム１７０がブラックリスト１８０上にある間）サブシステム１７０からの書き込みを防止するようにしてもよい。

サブシステムを一時的に停止する（例えば、サブシステム１７０に関連するプロセスを停止する）改善措置は、サブシステム１７０が再開されるまで、サブシステム１７０が書き込みを完了するのを遅延させる。したがって、サブシステム１７０の書き込み速度は、サスペンド期間（すなわち、サブシステム１７０のサスペンドと再開の間の時間）の関数に基づいて、効果的に低減され得る。いくつかの実施形態では、サブシステム１７０の書き込み速度を書き込み閾値以下の許容可能なレベルまで低減することを可能にするように、懸濁期間が選択される。さらに、サブシステム１７０の中断および再開は、サブシステム１７０内のロジックに対する最小限の破壊を可能にし得る。タイミングに鈍感なサブシステム１７０では、中断および再開操作の特別な取り扱いは必要なく、機能性は、より遅い速度であることを除いて通常通り継続することができる場合がある。

サブシステムを終了させる（例えば、サブシステム１７０に関連するプロセスを終了させる）改善措置は、少なくともサブシステム１７０が再起動するのにかかる時間、サブシステム１７０が書き込みを試みるのを停止してもよい。さらに、サブシステム１７０の再起動は、サブシステム１７０が過剰な書き込みの試みを実行する原因となっていた誤動作を修正してもよい。

重要なプロセスを除いてコンピューティングデバイス１２０内の様々なサブシステム１７０を終了させ、したがってコンピューティングデバイス１２０をセーフモードに移行させるという改善措置は、そのようなサブシステム１７０が過剰な書き込みを実行するのを停止し得る。場合によっては、サブシステム１７０は互いに相互作用し、したがって、あるサブシステム１７０の過剰な権利は、別のサブシステム１７０との相互作用によって引き起こされることがある。セーフモードに入ることで、ネットワーク通信や、コンピューティングデバイス１２０がユーティリティメータである場合、リソースの消費量の測定など、重要なプロセスの継続が可能になる場合がある。したがって、コンピューティングデバイス１２０は、その重要な機能の実行を継続してもよく、デバッグ、ソフトウェア更新、または消費報告目的のために、ヘッドエンドシステムなどの外部リソースと通信することができるかもしれない。

コンピューティングデバイス１２０を全体としてリセットまたは再起動する改善措置は、セーフモードに入ることと同じ利点を有するが、重要なプロセスが再起動またはリセットの間に一時的に停止されるので、潜在的により抜本的な解決策である。このより抜本的な措置は、特に、その違反が改善措置を促したサブシステム１７０が重要なプロセスである場合、または重要なプロセスと相互作用するサブシステム１７０である場合に、有用である場合がある。

いくつかの実装では、ブラックリストマネージャ１６０は、ブラックリスト１８０上のサブシステム１７０を管理することができる。例えば、各サブシステム１７０は、リリースタイマ、改善タイマ、またはその両方などの少なくとも１つのタイマと関連付けられてもよい。各そのようなタイマは、関連するサブシステム１７０がブラックリスト１８０に追加されるときに初期化（例えば、リセット）されてもよい。ブラックリストマネージャ１６０は、ブラックリストに登録されたサブシステム１７０に関連付けられたタイマを管理してもよく、そのようなタイマの満了時にブラックリストに登録されたサブシステム１７０に対してアクションを実行してもよい。

ブラックリストに登録されたサブシステム１７０に関連する場合、リリースタイマはリリース時間をカウントアウトしてもよく、その後、ブラックリストマネージャ１６０はサブシステム１７０をブラックリスト１８０からリリース（すなわち、削除）してもよい。したがって、ブラックリストマネージャ１６０は、関連するサブシステム１７０が違反のために一時的にしかブラックリストに載らないことを保証するために、リリースタイマを利用してもよい。いくつかの実装では、現在ブラックリストに載っているサブシステム１７０が別の違反を犯した場合、ブラックリストマネージャ１６０は、サブシステム１７０による直近の違反の後にリリース時間が経過するまでサブシステムのリリースが行われないように、リリースタイマをリセットしてもよい。このように、リリース時間は、サブシステム１７０がブラックリスト１８０から削除される後の、閾値時間として機能してもよい。

ブラックリストに登録されたサブシステム１７０に関連する場合、改善タイマが改善時間をカウントアウトし、その後、ブラックリストマネージャ１６０は、改善措置を開始する、またはサブシステムモニタ１５０によって以前に開始された改善措置を終了するなどの改善措置の少なくとも一部を実行することができる。一例では、サブシステムモニタ１５０は、サブシステム１７０をブラックリスト１８０に追加する際に、サブシステム１７０を停止させる。その場合、改善タイマは、所望のサスペンド期間に等しい改善時間をカウントアウトするために使用されてもよく、その満了時に、ブラックリストマネージャ１６０はサブシステム１７０を再開することができる。別の例では、サブシステム１７０がブラックリストに載っているとき、ブラックリストマネージャ１６０は、改善時間が満了した後、サブシステム１７０を（例えば、サブシステム１７０の一部またはすべてのプロセスを打ち切ることによって）打ち切り得る。このようにして、ストレージ保護システム１００は、サブシステム１７０が、シャットダウン前のタスクを実行することによって、または自身をシャットダウンすることによってなど、改善時間中に自身のシャットダウンに備えることができるようにすることができる。別の例では、ブラックリストマネージャ１６０は、改善時間が経過した後、コンピューティングデバイス１２０を全体として再起動してもよいし、コンピューティングデバイス１２０上のオペレーティングシステムをリセットしてもよい。したがって、改善タイマの使用は、コンピューティングデバイス１２０の様々なサブシステム１７０がシャットダウンの準備をすることを可能にし得る。このように、改善時間は、閾値時間として作用してもよく、その後、何らかの改善措置が実行または終了されてもよい。

タイマは、様々な方法で実装することができる。例えば、タイマは、カウントダウンタイマとして実装されてもよい。例えば、サブシステム１７０がブラックリスト１８０上に配置されるか、または既にブラックリスト１８０上にある間に違反を犯した場合、カウントダウンタイマとして実装された関連する解放タイマは、解放時間を表す値で初期化されてよく、時間が経過すると下方にカウントされてよい。リリースタイマがゼロに達すると、リリースタイマおよび関連するリリース時間が満了したとみなされ、ブラックリストマネージャ１６０は、そのような満了に応答して、ブラックリスト１８０からサブシステム１７０を削除してもよい。別の例として、サブシステム１７０がブラックリスト１８０に置かれるとき、カウントダウンタイマとして実装される関連する改善タイマは、改善時間を表す値で初期化されてもよく、時間の経過とともに下方にカウントされてもよい。改善タイマがゼロに達すると、改善タイマおよび関連する改善時間は、期限切れとみなされてもよく、期限切れに応答して、ブラックリストマネージャ１６０は、（たとえば、サブシステム１７０を終了する、またはコンピューティングデバイス１２０を再起動する）改善アクションを実行してもよく、または（たとえば、中断後にサブシステム１７０を再開する）改善アクションを終了してもよい。

しかしながら、いくつかの実装では、タイマは上向きにカウントされてもよい。この一例では、サブシステム１７０がブラックリスト１８０に載せられたとき、または既にブラックリスト１８０に載っている間に違反を犯したとき、上向きカウントタイマとして実装された関連リリースタイマは、ゼロの値で初期化されてよく、時間の経過とともにリリース時間に向かって上向きにカウントされてよい。リリースタイマがリリース時間に達すると、リリースタイマおよび関連するリリース時間は期限切れとみなされ、ブラックリストマネージャ１６０は、そのような期限切れに応答してブラックリスト１８０からサブシステム１７０を除去してもよい。別の例として、サブシステム１７０がブラックリスト１８０に配置されるとき、上向きカウントタイマとして実装される関連する改善タイマは、ゼロの値で初期化されてもよく、時間の経過とともに改善時間まで上向きにカウントされてもよい。改善タイマが改善時間に達すると、改善タイマおよび改善時間は期限切れとみなされ、期限切れに応答して、ブラックリストマネージャ１６０は改善措置を実行または結論付けてもよい。

各タイマは、そのタイマに関連する確立された時間単位に基づいて時間をカウントしてもよい。例えば、タイマは、時間を秒単位で表してもよく、秒単位で下降または上昇をカウントしてもよい。別の例として、タイマは時間をインターバルで表してもよく、その場合、タイマはインターバルの経過に従って下降または上昇をカウントしてもよい。時間測定の様々な単位がタイマによって使用されてもよいことは理解されるであろう。

図２は、本発明の特定の実施態様による、ストレージ保護システム１００が実行可能なコンピューティングデバイス１２０、具体的には、ユーティリティメータ２００のアーキテクチャ図である。例えば、限定するわけではないが、ユーティリティメータ２００は、水道メータ、ガスメータ、または敷地２２０上のリソース２１０の消費を測定する他のタイプのメータであってもよい。この目的のために、ユーティリティメータ２００は、リソース２１０の使用を示す信号を検出し、その信号に基づいて、敷地２２０上のリソース２１０の使用を決定する、計量エンジン２０５を含んでもよい。他のタイプのコンピューティングデバイス１２０と同様に、ユーティリティメータ２００は、処理ユニット１３０、メモリ１４０、およびストレージ１１０を含んでもよく、これらは、システムバス２３０を介して互いに接続されてもよい。例えば、限定するわけではないが、メモリ１４０はＲＡＭであってもよく、ストレージ１１０は、ＮＡＮＤメモリまたはｅＭＭＣなどのフラッシュストレージであってもよい。図２にはユーティリティメータ２００が示されているが、コンピューティングデバイス１２０はユーティリティメータ２００に限定されないことは理解されよう。むしろ、例えば、コンピューティングデバイス１２０は、コレクタ、ゲートウェイ、またはユーティリティメータ２００以外の別のコンピューティングデバイスであってもよい。

図３は、本発明の特定の実施態様による、ストレージデバイス１１０の寿命を保護するためにストレージデバイス１１０への書き込みを管理するための方法３００のフロー図である。この方法３００は、コンピューティングデバイス１２０によって実行されてもよい。例えば、方法３００は、コンピューティングデバイス１２０上の処理ユニット１３０によって実行可能な、サブシステムモニタ１５０に統合されたプログラムコードとして実装されてもよい。いくつかの実装では、この方法３００または同様のもののインスタンスは、書き込みがサブシステム１７０によって試行されるたびに実行されてもよい。さらに、または代替的に、図３には示されていないが、方法３００または同様のものは、定期的に（例えば、数秒ごとに）実行されてもよい。

方法３００の最初の実行（例えば、コンピューティングデバイス１２０の再起動後に方法３００が稼働する最初の時）の前に、コンピューティングデバイス１２０にインストールされた各サブシステム１７０に対してそれぞれの書き込み閾値が確立され得る。例えば、様々な書き込み閾値は、ストレージ１１０に符号化され、サブシステムモニタ１５０によってアクセス可能であってよい。書き込み閾値が動的である場合、書き込み閾値は必要に応じて更新されてもよく、方法３００の将来の各実行では、更新された書き込み閾値が使用されてもよい。いくつかの実施形態では、時間は、それぞれ数秒のような間隔に分割され、書き込み閾値は、対応するサブシステム１７０が所定の間隔において書き込み閾値を満たす場合に改善のリスクを負うように、個別的に各間隔に適用される。

いくつかの実装では、ストレージ保護システム１００は、完全にメモリ１４０で実行され、ストレージ保護システム１００を実装するプログラムコードは、方法３００の実行に先立って検証され得る。そのような実装では、コンピューティングデバイス１２０は、方法３００の最初の実行に先立って、書き込みを管理するこの方法３００を実装するプログラムコードをメモリ１４０にロードしてもよい。

さらに、方法３００の最初の実行に先立って、サブシステムモニタ１５０は、ブラックリスト１８０を確立してもよく、これは、過去に（たとえば、それぞれの書き込み閾値を超えることによって）悪い振る舞いをしたサブシステム１７０のリストであってよく、したがって罰則の対象になっている。ブラックリスト１８０は、方法３００の最初の実行が開始されたときに空であってもよいが、ブラックリスト１８０は、（例えば、メモリ１４０に）保存され、方法３００の様々な実行にわたって利用されることがある。ブラックリスト１８０上の各サブシステム１７０は、リリースタイマまたは改善タイマなどの少なくとも１つのそれぞれのタイマと関連付けられてもよい。

図３に示すように、方法３００のブロック３０５で、サブシステムモニタ１５０は、書き込みの試み（すなわち、ストレージ１１０への書き込みの試み）を検出する。例えば、メモリ１４０への書き込みは、書き込まれたメモリコンテンツが典型的にはその後ストレージ１１０に同期されるため、書き込み試行とみなすことができる。メモリの単一のブロックに書き込む各試行は、メモリの複数のブロックに書き込む試みが複数の書き込み試行、具体的には、ブロックごとに１つの書き込み試行と見なされる場合がある。

ブロック３１０において、サブシステムモニタ１５０は、書き込みの試みを実行したサブシステム１７０を識別する。どのサブシステム１７０が書き込みを試みたかを決定するために使用される技術は、サブシステム１７０がどのように定義されるかに部分的に基づいてもよい。例えば、サブシステム１７０がファイルのセットを含むように定義されている場合、サブシステムモニタ１５０は、書き込まれるファイルに基づいて書き込みの試みを実行したサブシステム１７０を識別してもよい。別の例として、サブシステム１７０がプロセスのセットを含むように定義される場合、サブシステムモニタ１５０は、書き込みの試みを実行するプロセスに基づいて、書き込みの試みを実行したサブシステム１７０を特定してもよい。

ブロック３１０において、サブシステムモニタ１５０は、書き込み試行を実行したサブシステム１７０の書き込み試行を記述する統計情報を更新する。たとえば、いくつかの実装では、サブシステムモニタ１５０は、アクティブな間隔（すなわち、開始され、まだ終了していない間隔）中に各サブシステム１７０によって行われた書き込み試行のカウントを維持する。いくつかの実装では、例えば、サブシステム１７０の書き込み試行または書き込みサイクル（すなわち、ストレージ１１０に実際に同期されたメモリブロック）の全時間総数、書き込み試行のレートなど、またはアクティブインターバルにおける書き込み試行の先行インターバル（すなわち、アクティブインターバルより前に発生したインターバル）との比較など、他の統計が維持されてもよい。これらの統計は、本明細書で説明するように使用するため、およびいくつかの実装では、デバッグ、報告、または他の目的のためにログに記録されてもよい。

いくつかの実装では、コンピューティングデバイス１２０は、様々なコンピューティングデバイス１２０を管理するための集中型ロケーションであるヘッドエンドシステムに統計情報を通信する。例えば、ヘッドエンドシステムは、様々なコンピューティングデバイス１２０から受信した統計を集約してもよく、追加的または代替的に、ヘッドエンドシステムは、ヘッドエンドシステムに報告する他のコンピューティングデバイス１２０の統計と比較して、統計に基づいてコンピューティングデバイス１２０が異常な態度で動作しているかどうかを識別することができる。

判定ブロック３１５で、サブシステムモニタ１５０は、サブシステム１７０がブラックリスト１８０上にあるかどうかを決定する。サブシステム１７０がブラックリスト１８０上にある場合（すなわち、サブシステム１７０が以前にブラックリスト１８０上に置かれ、まだブラックリスト１８０から削除されていない場合）、ブロック３２０で、サブシステムモニタ１５０は書き込み試行をブロックする。この場合、サブシステムモニタ１５０は、アクティブインターバル中に発生するサブシステム１７０のすべての書き込み試行をブロックしてもよい。より具体的には、例えば、書き込み試行をブロックするために、サブシステムモニタ１５０は、コンピューティングデバイス１２０のカーネルが、書き込み試行中にサブシステム１７０が書き込んだメモリコンテンツをストレージ１１０に同期させることを許さない。いくつかの実装では、サブシステムモニタ１５０は、書き込み試行がブロックされたことをサブシステム１７０に通知する（例えば、サブシステム１７０内のプロセスに通知する）。その場合、方法３００はその後終了し、サブシステム１７０による次の書き込み試行の際に再開することができる。

サブシステム１７０がブラックリスト１８０上にない場合、判定ブロック３２５において、サブシステムモニタ１５０は、サブシステム１７０がホワイトリスト１９０上にあるかどうかを決定する。サブシステムがホワイトリスト１９０上にある場合、ブロック３３０において、サブシステムモニタ１５０は、サブシステム１７０がストレージ１１０に書き込むことを許可する。具体的には、１つの実装では、サブシステムモニタ１５０は書き込みプロセスを妨害しないので、カーネルがサブシステム１７０によって書き込まれたメモリコンテンツをストレージ１１０に同期させることができる。別の実装では、サブシステムモニタ１５０は、書き込みの試みでサブシステム１７０によって書き込まれたメモリコンテンツをカーネルが同期させるよう要求する。その後、方法３００は終了し、サブシステム１７０による次の書き込み試行時に再開することができる。

サブシステム１７０がブラックリスト１８０にもホワイトリスト１９０にもない場合、方法３００は判定ブロック３３５に進む。判定ブロック３３５において、サブシステムモニタ１５０は、書き込みの試みが完了した場合（例えば、ストレージ１１０に同期した場合）、サブシステム１７０がアクティブ区間のその書き込み閾値を満たす（例えば、同等または超える）原因となるかどうかを決定する。書き込みの試みがサブシステム１７０にその書き込み閾値を満たさせないであろう場合、方法３００はブロック３４０に進み、サブシステムモニタ１５０は、サブシステム１７０がストレージ１１０への書き込み試行を完了することを許可する。その後、方法３００は終了し、サブシステム１７０による次の書き込み試行時に再開することができる。

しかしながら、サブシステム１７０がブラックリスト１８０およびホワイトリスト１９０のいずれにもなく、書き込み試行が、サブシステム１７０がアクティブ間隔のその書き込み閾値を満たす原因となる場合、方法３００は、ブロック３４５に進む。ブロック３４５において、これが、初期化以来（たとえば、コンピューティングデバイス１２０が最後に再起動してから）サブシステム１７０がその書き込み閾値を満たした最初の時間である場合、サブシステムモニタ１５０は、サブシステム１７０がその書き込み閾値を満たした最初の時間としてこれをログすることができる。得られたログは、デバッグ、報告、または他の目的のために使用されてもよい。いくつかの実装では、ログは、さらなる使用のために、ヘッドエンドシステムなどの集中型ロケーションに送信されてもよい。

図３には示されていないが、いくつかの実装では、これがサブシステムのその書き込み閾値を満たす最初の時間である場合、違反は許されるかもしれない。その場合、サブシステムモニタ１５０は、書き込みの試みを許可してもよく、したがって、サブシステム１７０によって書き込まれたメモリコンテンツが、ストレージ１１０に同期されるようにする。しかし、図３の例示的な方法３００では、これがサブシステムの書き込み閾値を満たす最初の時間であるかどうかの判断は、ロギング目的のためだけに使用され、書き込みの試みは、以下に説明するように依然としてブロックされる可能性がある。

いくつかの実装では、サブシステム１７０が過去にその書き込み閾値を満たしたかどうかにかかわらず、判定ブロック３５０において、サブシステムモニタ１５０は、書き込み試行が完了した場合、サブシステム１７０がアクティブインターバルの第２の書き込み閾値を満たすようになるかどうかを決定する。書き込み閾値と同様に、第２の書き込み閾値は、サブシステム１７０に関連付けられ、したがって、あるサブシステム１７０から別のサブシステムに変化してもよい。第２の書き込み閾値は、サブシステム１７０の書き込み閾値より高くてもよく、より具体的には、書き込み閾値に基づいてもよい。例えば、第２の書き込み閾値は、書き込み閾値の百分率であってよく、その百分率は、百分率よりも大きい。一例では、第２の書き込み閾値は、書き込み閾値の１２５％である。さらに、または代替的に、第２の書き込み閾値は、アクティブ間隔を含むがより長い拡張間隔に適用される。例えば、書き込み閾値が１時間の長さを有する間隔に適用される場合、第２の書き込み閾値は１日の延長された間隔に適用されてもよい。この場合、書き込みがより長い期間にわたって制限されたままである限り、第２の書き込み閾値を使用して、時折の過剰書き込みのバーストを許容することができる。

書き込み試行が、サブシステム１７０に、適用可能な期間（たとえば、アクティブ間隔またはアクティブ拡張間隔）にわたってその第２の書き込み閾値を満たさせないであろう場合、ブロック３５５において、サブシステムモニタ１５０は、書き込み試行の進行を許可し、したがって、書き込み試行にサブシステム１７０によって書き込まれたメモリコンテンツは、ストレージ１１０に同期され得る。しかしながら、書き込み試行が、サブシステム１７０が適用可能な期間にわたってその第２の書き込み閾値を満たすことになる場合、方法３００は、判定ブロック３６０に進む。

いくつかの実装は、サブシステム１７０が、ブラックリストに載るリスクまたは書き込み試行がブロックされるリスクなしに、その書き込み閾値を少々超えることを可能にするために、上記のような第２の書き込み閾値を利用する。しかしながら、他の実装は、この第２の閾値を利用する必要がないことが理解されよう。その場合、判定ブロック３５０はスキップされてもよく、方法は、ブロック３４５から判定ブロック３６０に進行してもよい。

より一般的には、ストレージ保護システム１００は、サブシステム１７０をブラックリスト化するか、サブシステム１７０がストレージ１１０に書き込むのをブロックするか、またはその両方を行うかを決定するために、一組のブロッキング基準を利用することができる。一実装では、ブロッキング基準は、サブシステム１７０がその書き込み閾値を満たす場合にのみ満たされ、ブロッキング基準が満たされることに応答して、サブシステムモニタ１５０は、サブシステム１７０をブラックリスト化し、書き込み試行をブロックする。別の実装では、サブシステム１７０がその第２の書き込み閾値を満たす場合にのみ、ブロッキング基準が満たされ、ブロッキング基準が満たされることに応答して、サブシステムモニタ１５０はサブシステム１７０をブラックリスト化し、書き込み試行をブロックする。さらに別の実装では、ブロッキング基準は、サブシステム１７０が時間枠内（たとえば、１週間ごとまたはコンピューティングデバイス１２０が最後に再起動したときから）にその書き込み閾値を所定回数満たすか、または時間枠内にその第２の書き込み閾値を所定回数満たす場合にのみ満たされ、かかるブロッキング基準が満たされているのに応じて、サブシステムモニタはサブシステム１７０をブラックリストに入れ、書き込み試行をブロックする。

判定ブロック３６０において、サブシステムモニタ１５０は、違反閾値が、現在の違反によって（すなわち、サブシステム１７０が書き込み閾値を超える原因となった書き込み試行によって）満たされたか否かを決定する。いくつかの実装では、違反閾値は、サブシステム１７０がブラックリスト１８０に追加される前に、ブラックリスト１８０上にないサブシステム１７０によって許容される違反の数であるか、またはそれを表す。違反閾値は、最後の１日以上、最後の１週間以上、設定された数の間隔以上、またはコンピューティングデバイス１２０の最後の再起動以降など、確立された時間枠に適用されてもよい。その場合、サブシステムモニタ１５０は、サブシステム１７０がその時間枠内で違反閾値を満たしたか否かを判断する。違反閾値が満たされていない（例えば、等しいかまたは超えている）と判定ブロック３６０で決定された場合、サブシステムモニタ１５０は、ブロック３６５で書き込み試行を許可する。そうでなければ、サブシステム１７０が違反閾値を満たした場合、方法３００は、ブロック３７０に進む。

いくつかの実装では、違反閾値は使用されない。違反閾値の欠如は、違反閾値として１の値を使用することと論理的に等価であってもよい。その場合、判定ブロック３６０はスキップされてもよく、方法３００は判定ブロック３５０からブロック３７０まで進行してもよい。

ブロック３７０において、サブシステムモニタ１５０は、サブシステム１７０をブラックリスト１８０に追加し、サブシステム１７０に関連する各タイマを初期化する。上述したように、そのようなタイマは、リリースタイマおよび改善タイマのうちの１つまたは両方を含むことができる。

判定ブロック３７５において、サブシステムモニタ１５０は、サブシステム１７０の違反を処理するために、書き込み試行をブロックすることに加えて、１つ以上の改善アクションを決定する。この決定は、ストレージ保護システム１００においてサブシステム１７０に関連する以前に確立された設定に基づくことができる。例えば、設定は、サブシステム１７０がブラックリストに載ったときに、サブシステム１７０を中断（すなわち、一時停止）すること、サブシステム１７０を終了（すなわち、その様々なプロセスを停止）すること、または他の何らかの改善措置を取ることを示してもよい。いくつかの実装では、各サブシステム１７０は、改善措置のセットと関連付けられてもよく、それは空のセットであってもよいし、サブシステム１７０がブラックリスト１８０に加えられたときにトリガされる１つまたは複数の改善措置を含んでもよい。どの改善措置を実行するかを決定するために、サブシステムモニタ１５０は、ストレージ保護システム１００の設定をチェックして、どの改善措置がサブシステム１７０に関連付けられるかを決定してもよい。いくつかの実装では、サブシステムモニタ１５０は、設定に示された各改善措置を実行する。そのような改善措置が、単に書き込み試行をブロックする以外にサブシステム１７０に関連付けられていない場合、方法３００は、ブロック３９０にスキップして進むことができる。

図３の例では、書き込み試行をブロックする以外に、サブシステム１７０を一時停止することとサブシステム１７０を終了させることの２つの改善措置のみが利用可能である。サブシステムモニタ１５０がサブシステム１７０を終了させることを決定した場合、ブロック３８０において、サブシステムモニタ１５０は、サブシステム１７０を終了させる。より具体的には、サブシステム１７０が複数のプロセスを含む場合、サブシステムモニタ１５０のいくつかの実装は、書き込み試行を行ったプロセスのみを打ち切り得るが、他の実装は、サブシステム１７０内の複数のプロセスまたはすべてのプロセスを打ち切り得る。そのようなプロセスは互いに依存している可能性があるため、サブシステム１７０のすべてのプロセスを打ち切ることが有益である場合がある。その後、方法３００は、ブロック３９０にスキップしてもよい。しかしながら、サブシステムモニタ１５０がサブシステム１７０をサスペンドすることを決定した場合、ブロック３８５において、サブシステムモニタ１５０は、サブシステム１７０をサスペンドする。より具体的には、サブシステム１７０が複数のプロセスを含む場合、いくつかの実装は、書き込み試行を行ったプロセスのみをサスペンドし、他の実装は、サブシステム１７０内の複数のプロセスまたはすべてのプロセスをサスペンドすることができる。そのようなプロセスは互いに依存している可能性があるため、サブシステム１７０のすべてのプロセスをサスペンドすることが有益である場合がある。サブシステム１７０をサスペンドする場合、サブシステム１７０は、改善時間をカウントする改善タイマと関連付けられてもよく、その満了時にサブシステム１７０が再開されることになる。その後、方法３００は、ブロック３９０に進んでもよい。

ブロック３９０において、サブシステムモニタ１５０は、書き込み試行をブロックする。言い換えれば、サブシステムモニタ１５０は、アクティブインターバル中にサブシステム１７０によって書き込まれたメモリコンテンツがストレージ１１０に同期されないようにブロックしてもよい。例えば、サブシステムモニタ１５０は、カーネルがメモリコンテンツを同期しないことを要求してもよく、またはカーネルが要求に応じてのみこの同期を実行する実装では、サブシステムモニタ１５０は、カーネルがメモリコンテンツを同期することを要求しないことを単に選択してもよい。いくつかの実装では、サブシステムモニタ１５０は、取られた任意の改善措置（例えば、停止、ブロックされた書き込み試行）をサブシステム１７０に通知してもよい。その後、方法３００は終了し、サブシステム１７０による次の書き込み試行時に再開することができる。

図４は、本発明の特定の実施態様による、ストレージデバイス１１０の寿命を保護するように、違反を犯したサブシステム１７０のブラックリスト１８０を管理する方法４００のフロー図である。上述したように、サブシステム１７０は、それぞれの書き込み閾値を満たす（たとえば、等しいかまたは超える）ためなどに、ブラックリスト１８０に追加される場合がある。図４の方法４００または同様のものは、例えば、特定の条件が満たされたときにサブシステム１７０をブラックリスト１８０から削除することを含む、そのブラックリスト１８０を管理するために使用されてもよい。いくつかの実装では、図４に示すようなブラックリスト１８０を管理する方法４００は、図３に示すような書き込みを管理する方法３００と並行して実行されてもよい。例えばいくつかの実装では、図４の方法４００または同様の方法は、書き込みを管理する方法３００によって移入されるブラックリスト１８０を管理するために、１秒に１回または他の何らかの周期的スケジュールで実行されてもよく、書き込みを管理する方法３００は書き込み試行が発生すると実行されてもよい。

図４の方法４００は、ブラックリスト１８０上のサブシステム１７０を反復してもよい。図４に示すように、判定ブロック４０５において、ブラックリストマネージャ１６０は、方法４００の現在の実行において考慮されるべきブラックリスト１８０上のサブシステム１７０がこれ以上残っているかどうかを決定する。考慮すべきサブシステム１７０が残っていない場合、方法４００は、ブロック４１０で終了してもよい。例えば、ブラックリスト１８０が空である場合、またはブラックリスト１８０のすべてのサブシステム１７０が既に考慮されたように１つ以上の反復が既に実行された場合、考慮すべきサブシステム１７０が残っていない可能性がある。

しかしながら、１つ以上のサブシステム１７０が検討されるために残っている場合、ブロック４１５において、ブラックリストマネージャ１６０は、この反復で検討するサブシステム１７０を選択することができる。

上述したように、各サブシステム１７０は、リリースタイマ、改善タイマ、またはその両方を含む少なくとも１つのタイマと関連付けられてもよい。判定ブロック４２０において、選択されたサブシステム１７０がリリースタイマを有するかどうかが決定され得る。サブシステム１７０がリリースタイマを有する場合、方法４００は判定ブロック４２５に進み、そうでない場合、サブシステム１７０がリリースタイマを有しない場合、方法４００は判定ブロック４４０にスキップして進む。

サブシステム１７０がリリースタイマを有する場合、判定ブロック４２５で、ブラックリストマネージャ１６０は、リリースタイマが期限切れになったかどうかを決定する。いくつかの実装では、リリースタイマは、サブシステム１７０が違反を犯した度にリセットされており、したがって、リリースタイマは、最後の違反から関連するリリース時間が経過した後にのみ、失効している。

リリースタイマが満了した場合、ブロック４３０において、ブラックリストマネージャ１６０は、ブラックリスト１８０からサブシステム１７０を削除し、方法４００はブロック４０５に戻り、方法４００の現在の実行において考慮すべきサブシステム１７０がさらに残っているかどうかを決定する。

しかしながら、リリースタイマが満了していない場合、ブロック４３５において、ブラックリストマネージャ１６０は、方法４００の現在の実行と方法４００の最後の実行との間で経過した時間だけ、リリースタイマをデクリメントする。例えば、リリースタイマが時間を秒単位で維持し、方法４００が１秒に１回実行される場合、リリースタイマは、経過した時間を表すために１だけデクリメントされ得る。次いで、方法４００は、適用可能であれば、改善タイマを検討するために判定ブロック４４０に進む。

判定ブロック４４０で、ブラックリストマネージャ１６０は、サブシステム１７０が改善タイマと関連付けられているかどうかを決定する。サブシステム１７０が改善タイマに関連付けられていない場合、方法はブロック４０５に戻り、検討のために任意の追加のサブシステム１７０が残っているかどうかを判断することができる。しかし、サブシステム１７０が改善タイマと関連付けられている場合、判定ブロック４４５で、ブラックリストマネージャ１６０は、改善タイマが期限切れになったかどうかを決定する。

改善タイマが期限切れでない場合、ブロック４５５において、ブラックリストマネージャ１６０は、方法４００の現在の実行と方法４００の最後の実行との間に経過した時間だけ、改善タイマをデクリメントしてもよい。その後、方法４００は、ブロック４０５に戻り、任意のサブシステム１７０が検討のために残っているかどうかを判断してもよい。

しかしながら、改善タイマが期限切れになった場合、ブロック４５０において、ブラックリストマネージャ１６０は、改善タイマに関連する時限アクションを実行する。たとえば、時限アクションがサスペンドからの復帰である場合、ブラックリストマネージャ１６０は、サスペンドされていたサブシステム１７０のプロセスを再開することができる。計時されたアクションが、終了した後のサブシステム１７０の再スタートである場合、ブラックリストマネージャ１６０は、終了したサブシステム１７０のプロセスを再スタートさせてもよい。サブシステム１７０の再開または再起動の場合、ブラックリストマネージャ１６０は、サブシステム１７０をブラックリスト１８０から削除してもよいし、サブシステム１７０がリリースタイマに関連している場合、リリースタイマをリセットしてサブシステム１７０がブラックリスト１８０から削除される機会を与えるようにしてもよい。時限アクションがコンピューティングデバイス１２０全体の再起動である場合、ブラックリストマネージャ１６０は、コンピューティングデバイス１２０のその再起動を開始することができる。

いくつかの実装では、コンピューティングデバイス１２０を再起動すると、ブラックリスト１８０が消去される。たとえば、ストレージ保護システム１００は、揮発性であってもよいメモリ１４０で実行されてもよく、したがって、コンピューティングデバイス１２０の再起動は、メモリ１４０およびしたがってブラックリスト１８０をクリアすることができる。あるいは、ブラックリスト１８０がストレージ１１０に格納される場合、ブラックリストマネージャ１６０は、いくつかの実装において、コンピューティングデバイス１２０を再起動する前に、ブラックリスト１８０をクリアしてもよい。

その後、方法４００は、ブロック４０５に戻り、検討のためにそれ以上のサブシステム１７０が残っているかどうかを判断する。

このように、本明細書で説明する実装は、サブシステム１７０ごとにストレージデバイス１１０の書き込みサイクルを制限することによって、ストレージデバイス１１０を保護する。様々なサブシステム１７０の書き込みを個別に管理することによって、ストレージ保護システム１００は、あまりにも多くの書き込みを実行しているサブシステム１７０を特定し、そのようなサブシステムによって実行される書き込みを制限することができる。サブシステム１７０を個別にターゲットにすることは、場合によっては、ストレージデバイス１１０の寿命を経時的に維持しながら、コンピューティングデバイス１２０の残りの部分が通常通りに実行し続けることを可能にし得る。

請求された主題の徹底的な理解を提供するために、多数の具体的な詳細が本明細書に記載されている。しかしながら、当業者は、請求された主題がこれらの具体的な詳細なしに実施され得ることを理解するであろう。他の例では、当業者によって知られているであろう方法、装置、又はシステムは、クレームされた主題を不明瞭にしないように、詳細には記載されていない。

本明細書で議論される特徴は、任意の特定のハードウェアアーキテクチャまたは構成に限定されない。コンピューティングデバイスは、１つ以上の入力を条件とする結果を提供するコンポーネントの任意の好適な配置を含むことができる。好適なコンピューティング装置は、コンピューティングシステムを汎用コンピューティング装置から本主題の１つ以上の態様を実装する特殊コンピューティング装置へとプログラムまたは構成する格納ソフトウェア（すなわち、コンピュータシステムのメモリ上に格納されたコンピュータ可読命令）にアクセスする多目的マイクロプロセッサベースのコンピュータシステムを含んでいる。任意の適切なプログラミング、スクリプト、または他のタイプの言語または言語の組み合わせが、コンピューティング装置をプログラミングまたは構成する際に使用されるソフトウェアにおいて、本明細書に含まれる教示を実装するために使用されてもよい。

本明細書に開示される方法の態様は、そのようなコンピューティングデバイスの動作において実行されてもよい。上記の例で提示されたブロックの順序は、変化させることができ、例えば、ブロックは、再順序付けされ、結合され、および／またはサブブロックに分割されることができる。特定のブロックまたはプロセスは、並行して実行することができる。

本明細書における「に適合された」又は「に構成された」の使用は、追加のタスク又はステップを実行するように適合又は構成された装置を妨げない、開放的かつ包括的な言語として意図されている。さらに、「に基づく」の使用は、プロセス、ステップ、計算、または他の動作が、１つまたは複数の言及された条件または値に「基づく」場合、実際には、言及されたものを超える追加の条件または値に基づくことができるという意味で、開放的で包括的であることを意図している。本明細書に含まれる見出し、リスト、および番号付けは、説明を容易にするためだけのものであり、限定することを意図していない。

本主題は、その特定の態様に関して詳細に説明されてきたが、当業者は、前述の理解を得た時点で、そのような態様に対する変更、変形、及び同等物を容易に作り出すことができることが理解されよう。したがって、本開示は、限定ではなく例示の目的で提示されており、当業者に容易に明らかになるような本主題に対する変更、変形、および／または追加を含めることを排除するものではないことを理解されたい。

Claims (20)

1. ストレージデバイスへの書き込みサイクルを制限する方法であって、
   コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの第１のセットの書き込みの第１のカウントを追跡するステップと、
   前記第１のカウントが前記第１のサブシステムの書き込み閾値を満たすことを判定するステップと、
   前記第１のカウントが前記第１のサブシステムの書き込み閾値を超えることに基づいて、前記第１のサブシステムによってブロッキング基準が満たされることを判定するステップと、
   コンピューティングデバイスの第２のサブシステムによってブロッキング基準が満たされないことを判定するステップと、
   前記ブロッキング基準が前記第１のサブシステムによって満たされることに基づいて、前記第１のセットの書き込みが前記ストレージデバイスに同期されることをブロックするステップと、及び、
   前記ブロッキング基準が第２のサブシステムによって満たされないことに基づいて、第２のサブシステムのメモリコンテンツをストレージデバイスに同期させるステップと
   を含む、方法。
2. 前記第１のサブシステムについて前記ブロッキング基準が満たされることを判定することは、前記第１のサブシステムが過去に前記書き込み閾値を超えたことを判定することを、更に含む、請求項１に記載の方法。
3. 前記第１のサブシステムについて前記ブロッキング基準が満たされることを判定することは、前記第１のカウントが前記書き込み閾値よりも高い第２の書き込み閾値を満たすことを判定することを、更に含む、請求項１に記載の方法。
4. 更に、
   前記第１のカウントが前記書き込み閾値を満たすことに基づいて、前記第１のサブシステムのステータスをブラックリスト化に変更するステップと、及び、
   前記第１のサブシステムがブラックリスト化のステータスを有する間、前記第１のサブシステムによって実行される追加の書き込みが前記ストレージデバイスに同期されるのをブロックするステップと
   を含む、請求項１に記載の方法。
5. 更に、
   前記第１のサブシステムが前記ブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連するリリースタイマを初期化するステップと、及び、
   前記リリースタイマの期限切れに応答して、前記第１のサブシステムのステータスをブラックリスト化から変更するステップと
   を含む、請求項４に記載の方法。
6. 更に、
   前記第１のサブシステムが前記ブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連付けられた改善タイマを初期化するステップと、及び、
   前記改善タイマの期限切れに応答して、改善アクションの少なくとも一部を実行するステップと
   を含む、請求項４に記載の方法。
7. 改善タイマの期限切れに応答して、改善アクションの少なくとも一部を実行するステップは、改善タイマの期限切れに応答して、コンピューティングデバイスを再起動するステップを含む、
   請求項６に記載の方法。
8. 前記改善タイマの期限切れに応答して、前記改善アクションの少なくとも一部を実行するステップは、前記改善タイマの期限切れに応答して、前記第１のサブシステムを終了させるステップを含む、
   請求項６に記載の方法。
9. 更に、
   前記第１のサブシステムがブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムをサスペンドするステップ
   を含み、
   前記改善タイマの期限切れに応答して、前記改善アクションの少なくとも一部を実行するステップは、前記改善タイマの期限切れに応答して、前記第１のサブシステムを再開するステップを含む、
   請求項６に記載の方法。
10. 前記第２のサブシステムについて前記ブロッキング基準が満たされないことを判定するステップは、前記第２のサブシステムがホワイトリスト上にあることを判定するステップを含む、請求項１に記載の方法。
11. 前記第１のサブシステムは、１つまたは複数のプロセスのセットとして定義される、
    請求項１に記載の方法。
12. 前記第１のサブシステムは、１つまたは複数のファイルのセットとして定義される、
    請求項１に記載の方法。
13. ストレージデバイスへの書き込みサイクルを制限するためのコンピュータプログラムプロダクトであって、該コンピュータプログラムプロダクトはプログラム命令をその上に具現化したコンピュータ可読記憶媒体を含み、プロセッサにより実行可能な該プログラム命令は該プロセッサに方法を実行させるものであり、
    該方法は、
    コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの第１のセットの書き込みの第１のカウントを追跡するステップと、
    前記第１のカウントが前記第１のサブシステムの書き込み閾値を満たすことを判定するステップと、
    前記第１のカウントが前記第１のサブシステムの書き込み閾値を超えることに基づいて、前記第１のサブシステムによってブロッキング基準が満たされることを判定するステップと、
    コンピューティングデバイスの第２のサブシステムによってブロッキング基準が満たされないことを判定するステップと、
    前記第１のサブシステムによって前記ブロッキング基準が満たされることに基づいて、前記第１のセットの書き込みが前記ストレージデバイスに同期されることをブロックするステップと、及び、
    前記ブロッキング基準が前記第２のサブシステムによって満たされないことに基づいて、前記第２のサブシステムのメモリコンテンツを前記ストレージデバイスに同期させるステップと
    を含む、コンピュータプログラムプロダクト。
14. 前記方法は、更に、
    前記第１のカウントが前記書き込み閾値を満たすことに基づいて、前記第１のサブシステムのステータスをブラックリストに変更すること、および
    前記第１のサブシステムが前記ブラックリストに登録されたステータスを有する間、前記第１のサブシステムによって実行される追加の書き込みが前記ストレージデバイスに同期されるのをブロックするステップと
    を含む、
    請求項１３に記載のコンピュータプログラムプロダクト。
15. 前記方法は、更に、
    前記第１のサブシステムがブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連するリリースタイマを初期化するステップと、及び、
    前記リリースタイマの期限切れに応答して、前記第１のサブシステムのステータスをブラックリスト化から変更するステップと
    を含む、請求項１４に記載のコンピュータプログラムプロダクト。
16. 前記方法は、更に、
    前記第１のサブシステムがブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連する改善タイマを初期化するステップと、及び、
    前記改善タイマの期限切れに応答して、改善アクションの少なくとも一部を実行するステップと
    を含む、請求項１４に記載のコンピュータプログラムプロダクト。
17. コンピューティングデバイスであって、
    コンピュータ可読命令を実行するように構成されているプロセッサと、及び、
    プロセッサによって実行されたときに、プロセッサに動作を実行させるコンピュータ可読命令を格納するように構成されているメモリと
    を含み、
    前記動作は、
    コンピューティングデバイスの第１のサブシステムによって実行されるメモリへの第１のセットの書き込みの第１のカウントを追跡するステップと、
    前記第１のカウントが前記第１のサブシステムの書き込み閾値を満たすことを判定するステップと、
    前記第１のカウントが前記第１のサブシステムの書き込み閾値を超えることに基づいて、前記第１のサブシステムによってブロッキング基準が満たされることを判定するステップと、
    コンピューティングデバイスの第２のサブシステムによってブロッキング基準が満たされないことを判定するステップと、
    前記第１のサブシステムによって前記ブロッキング基準が満たされることに基づいて、前記第１のセットの書き込みが前記ストレージデバイスに同期されることをブロックするステップと、及び、
    前記第２のサブシステムによって前記ブロッキング基準が満たされないことに基づいて、前記第２のサブシステムのメモリコンテンツを前記ストレージデバイスに同期させるステップと
    を含む、コンピューティングデバイス。
18. 前記動作は、更に、
    前記第１のカウントが前記書き込み閾値を満たすことに基づいて、前記第１のサブシステムのステータスをブラックリスト化に変更するステップと、及び、
    前記第１のサブシステムが前記ブラックリスト化のステータスを有する間、前記第１のサブシステムによって実行される追加の書き込みが前記ストレージデバイスに同期されることをブロックするステップと
    を含む、請求項１７に記載のコンピューティングデバイス。
19. 前記動作は、更に、
    前記第１のサブシステムが前記ブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連するリリースタイマを初期化するステップと、及び、
    前記リリースタイマの期限切れに応答して、前記第１のサブシステムのステータスをブラックリスト化から変更するステップと
    を含む、請求項１８に記載のコンピューティングデバイス。
20. 前記動作は、更に、
    前記第１のサブシステムがブラックリスト化のステータスを有することに基づいて、前記第１のサブシステムに関連する改善タイマを初期化するステップと、及び、
    前記改善タイマの期限切れに応答して、改善アクションの少なくとも一部を実行するステップと
    を含む、請求項１８に記載のコンピューティングデバイス。

Images