特開 2023-141335 メモリシステムおよびリフレッシュ方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023141335

(43)【公開日】2023-10-05

(54)【発明の名称】メモリシステムおよびリフレッシュ方法

(51)【国際特許分類】

   G06F 12/00 20060101AFI20230928BHJP

   G11C 16/34 20060101ALI20230928BHJP

【ＦＩ】

G06F12/00 550B

G06F12/00 597U

G11C16/34 120

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2022047597

(22)【出願日】2022-03-23

(71)【出願人】

【識別番号】318010018

【氏名又は名称】キオクシア株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】加世堂 礼

【テーマコード（参考）】

5B160

5B225

【Ｆターム（参考）】

5B160AA14

5B160CA10

5B225CA28

5B225DE16

5B225FA01

(57)【要約】

【課題】リフレッシュの実行速度を好適に制御する。
【解決手段】物理ブロックを複数含む不揮発性メモリと、前記不揮発性メモリの前記複数のブロックに対して、前記複数のブロックに含まれる第１の複数ブロックのデータを第２の複数ブロックに書き換えるリフレッシュを実行するコントローラと、を備える。前記コントローラは、前記第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから前記各ブロックに対する前記リフレッシュを完了するまでの第１時間において、前記各ブロックに対する前記リフレッシュを開始する時間を動的に制御可能である。
【選択図】図９

【特許請求の範囲】

【請求項1】

物理ブロックを複数含む不揮発性メモリと、
前記不揮発性メモリの前記複数のブロックに対して、前記複数のブロックに含まれる第１の複数ブロックのデータを第２の複数ブロックに書き換えるリフレッシュを実行するコントローラと、
を備え、
前記コントローラは、前記第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから前記各ブロックに対する前記リフレッシュを完了するまでの第１時間において、前記各ブロックに対する前記リフレッシュを開始する時間を動的に制御可能である、
メモリシステム。

【請求項2】

前記コントローラは、前記第１の複数ブロックに含まれる第１ブロック及び第２ブロックについて、前記第１ブロック及び前記第２ブロックに対する前回の書き込みは同じ第１タイミングで実行されており、前記第１タイミングから前記第１ブロックに対する前記リフレッシュを開始するまでの第２時間と、前記第１タイミングから前記第２ブロックに対する前記リフレッシュを開始するまでの第３時間と、が異なるように制御する、
請求項１に記載のメモリシステム。

【請求項3】

前記コントローラは、前記第１時間よりも第４時間前に前記各ブロックの何れかに対する前記リフレッシュを開始し、前記第４時間における後半に前記リフレッシュを開始するブロックの量が、前記第４時間における前半に前記リフレッシュを開始するブロックの量より多くなるように制御する、
請求項１に記載のメモリシステム。

【請求項4】

前記コントローラは、前記第４時間における後半に第１数のブロックに対する前記リフレッシュを開始し、前記第４時間において前記後半よりも前の第５時間に前記第１数のブロック以外の第２数のブロックに対する前記リフレッシュを開始するように制御する、
請求項３に記載のメモリシステム。

【請求項5】

前記コントローラは、ホストから要求されるデータのリード及びライトに対応するホストＩ／Ｏの量に基づいて、前記リフレッシュを開始する時間を制御する、
請求項１に記載のメモリシステム。

【請求項6】

前記コントローラは、前記ホストＩ／Ｏの量を一定期間取得し、現在のホストＩ／Ｏの量が前記一定期間に取得した前記ホストＩ／Ｏの量に対して多い場合、前記リフレッシュを開始する時間を遅延させる
請求項５に記載のメモリシステム。

【請求項7】

物理ブロックを複数含む不揮発性メモリの前記複数のブロックに対して、前記複数のブロックに含まれる第１の複数ブロックのデータを第２の複数ブロックに書き換えるリフレッシュを実行するリフレッシュ処理を実行し、
前記リフレッシュ処理において、前記第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから前記各ブロックに対する前記リフレッシュを完了するまでの第１時間において、前記各ブロックに対する前記リフレッシュを開始する時間を動的に制御可能である、
リフレッシュ方法。

【発明の詳細な説明】

【技術分野】

【0001】

本実施形態は、メモリシステムおよびリフレッシュ方法に関する。

【背景技術】

【0002】

メモリを備えたメモリシステムが知られている。メモリシステムは、メモリに新たな記憶領域を確保するコンパクションを実行する。また、メモリシステムは、メモリに記憶されたデータを書き換えるリフレッシュを実行する。リフレッシュは、任意のタイミングで実行するリフレッシュと周期的に実行する強制リフレッシュとを含む。強制リフレッシュは、周期内にコンパクションを含めた処理を完了することが求められる。そのため、対象となるデータに対して同じタイミングで強制リフレッシュが実行されることがある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１５－０３２２４７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

一つの実施形態は、リフレッシュの実行速度を好適に制御することができるメモリシステムおよびリフレッシュ方法を提供する。

【課題を解決するための手段】

【0005】

一つの実施形態によれば、物理ブロックを複数含む不揮発性メモリと、前記不揮発性メモリの前記複数のブロックに対して、前記複数のブロックに含まれる第１の複数ブロックのデータを第２の複数ブロックに書き換えるリフレッシュを実行するコントローラと、を備える。前記コントローラは、前記第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから前記各ブロックに対する前記リフレッシュを完了するまでの第１時間において、前記各ブロックに対する前記リフレッシュを開始する時間を動的に制御可能である。

【図面の簡単な説明】

【0006】

【図1】実施形態にかかるメモリシステムの概略構成例を示すブロック図。

【図2】実施形態にかかる不揮発性メモリの詳細構成例を示す図。

【図3】実施形態にかかる物理ブロックと論理ブロックとの関係を示す図。

【図4】比較例における強制リフレッシュの処理の例を示す図。

【図5】実施形態にかかる強制リフレッシュ処理の手順を示すフローチャート。

【図6】実施形態にかかる強制リフレッシュリストを作成する例を示す図。

【図7】実施形態における強制リフレッシュの処理の例を示す図。

【図8】実施形態における強制リフレッシュの処理の別の例を説明する図。

【図9】実施形態における強制リフレッシュの処理の更に別の例を説明する図。

【発明を実施するための形態】

【0007】

以下に添付図面を参照して、実施形態にかかるメモリシステムおよびリフレッシュ方法を詳細に説明する。なお、以下の実施形態により本発明が限定されるものではない。

【0008】

図１は、実施形態にかかるメモリシステムの概略構成例を示すブロック図である。実施形態にかかるメモリシステム１００は、不揮発性メモリ１０を有する。メモリシステム１００は、不揮発性メモリ１０にデータを書き込んだり、不揮発性メモリ１０に格納されたデータを読み出したり、不揮発性メモリ１０に格納されたデータを消去したりする。不揮発性メモリ１０は、消去の最小の単位である物理ブロックを複数含む。

【0009】

メモリシステム１００は、例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。メモリシステム１００は、ホスト２００と接続可能である。メモリシステム１００は、接続されたホスト２００の外部記憶装置として機能する。ホスト２００は、例えば、パーソナルコンピュータのＣＰＵ、スチルカメラやビデオカメラなどの撮像装置のＣＰＵである。

【0010】

メモリシステム１００は、不揮発性メモリ１０、揮発性メモリ２０、コントローラ６０を有する。

【0011】

コントローラ６０は、メモリコントローラとも称される。コントローラ６０は、制御部３０、メモリインタフェース４０およびホストインタフェース（ホストＩ／Ｆ）５０を有する。不揮発性メモリ１０は、例えば、ＮＡＮＤ型フラッシュメモリなどの不揮発にデータを記憶可能な半導体メモリである。揮発性メモリ２０は、不揮発性メモリ１０よりも高速アクセスが可能な半導体メモリである。コントローラ６０は、例えば、ＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）として構成される回路である。揮発性メモリ２０は、コントローラ６０の外部に設けられてもよいし、コントローラ６０に内蔵されてもよい。

【0012】

不揮発性メモリ１０は、ホスト２００によって指示されたユーザデータ１１を記憶したり、メモリシステム１００の動作に関する情報を不揮発管理情報１２として記憶したりする。不揮発性メモリ１０は、複数のメモリセルがマトリクス状に配列されたメモリセルアレイを有し、個々のメモリセルは多値記憶が可能である。不揮発性メモリ１０は、複数のメモリチップを含み、各メモリチップは、データ消去の単位である物理ブロックを複数含んで構成される。また、不揮発性メモリ１０では、物理ページごとにデータの書き込みおよびデータの読み出しが行われる。物理ブロックは、複数の物理ページを含んで構成されている。

【0013】

図２は、不揮発性メモリ１０の詳細構成例を示す図である。この実施形態においては、不揮発性メモリ１０は、８つのチャネルＣｈ０～Ｃｈ７を介してコントローラ６０のメモリインタフェース４０に並列接続されている。すなわち、８つの並列動作要素１０ａ～１０ｈを並列動作させることが可能である。チャネル数は８つに限らず、任意の数を採用可能である。各並列動作要素１０ａ～１０ｈは、バンクインターリーブが可能な複数のバンク（この場合、２バンク、Ｂａｎｋ０～Ｂａｎｋ１）によって構成されている。各並列動作要素１０ａ～１０ｈにおいて、各バンクは、複数のメモリチップ（この場合、２メモリチップ、Ｃｈｉｐ０、Ｃｈｉｐ１）によって構成されている。各メモリチップは、例えば、それぞれ複数の物理ブロックを含むプレーン０、プレーン１の２つの領域（Ｄｉｓｔｒｉｃｔ）に分割されている。プレーン０およびプレーン１は、互いに独立した周辺回路（例えば、ロウデコーダ、カラムデコーダ、ページバッファ、データキャッシュ等）を備えており、プレーン倍速モードを使用することで、並列に消去／書き込み／読み出しを行うことが可能である。

【0014】

不揮発性メモリ１０では、複数のチャネルによる並列動作、複数のバンクによる並列動作、複数のプレーンを用いた倍速モードによる並列動作が可能であり、チャネル数を８、バンク数を２、プレーン数を２とした場合、最大３２個の物理ブロックを並列動作させることが可能となる。すなわち、コントローラ６０は、複数のチャネルを介して複数の物理ブロックに接続され、複数の物理ブロックを並列動作させることが可能である。

【0015】

揮発性メモリ２０は、ホスト２００からのデータを不揮発性メモリ１０に書き込みする際に一時的にデータを保存するライトバッファとしての記憶領域と、不揮発管理情報１２などの管理情報を記憶又は更新するための記憶領域と、不揮発性メモリ１０から読み出されたデータを一時的に記憶するリードバッファとしての記憶領域などを含む。また、揮発性メモリ２０は、コントローラ６０の動作のための作業領域を含む。

【0016】

ホスト２００は、ホストインタフェース５０を介してメモリシステム１００に接続される。ホスト２００は、メモリシステム１００に対して読み出し要求または書き込み要求を出力する。読み出し要求および書き込み要求には、論理アドレスとしてのＬＢＡ（Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ）が含まれる。ＬＢＡは、セクタに対して０からの通し番号をつけた論理アドレスである。セクタのサイズは例えば５１２Ｂである。

【0017】

メモリシステム１００において、コントローラ６０は、複数の物理ブロックをまとめて管理する単位として、論理ブロックという仮想的なブロックを構築する。コントローラ６０は、チャネル並列、バンクインターリーブ、プレーン倍速動作が実行可能な物理ブロックを組み合わせて論理ブロックを構築する。すなわち、論理ブロックは、チャネル数×バンク数×プレーン数分の物理ブロックで構成される。図２の場合、チャネル数＝８、プレーン数＝２、バンク数＝２であり、論理ブロックは、最大３２個の物理ブロックで構成され得る。

【0018】

なお、論理ブロックを構築する際に論理アドレスとしてのＭＢＡ（Ｍｅｄｉａ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ）を用いる。これは、メモリシステム１００において指定される論理アドレスであり、ホスト２００が指定する論理アドレスとしてのＬＢＡと区別される。論理ブロックは、複数のチャネル分の物理ブロックのみで構成してもよいし、複数のバンク分の物理ブロックのみで構成してもよいし、複数のプレーン分の物理ブロックのみで構成してもよい。また、チャネル並列、バンクインターリーブが行えるように物理ブロックを組み合わせても良いし、チャネル並列、プレーン倍速動作が行えるように物理ブロックを組み合わせてもよいし、バンクインターリーブ、プレーン倍速動作が行えるように物理ブロックを組み合わせてもよい。

【0019】

図１に示す不揮発管理情報１２は、メモリシステム１００の内部で使われる管理情報が不揮発化された情報である。コントローラ６０は、管理情報を生成又は更新すると不揮発性メモリ１０に格納して不揮発化する。不揮発管理情報１２は、論物変換テーブル（図示せず）や論理ブロック管理情報１３などを含む。論物変換テーブルは、ホスト２００で指定される論理アドレスであるＬＢＡと不揮発性メモリ１０でのデータの記憶位置を表す物理アドレスとの対応を管理するための情報である。論理ブロック管理情報１３は、メモリシステム１００で構築される複数の論理ブロックを管理するための情報である。

【0020】

メモリインタフェース４０は、揮発性メモリ２０と不揮発性メモリ１０とのインタフェース処理を行う回路である。メモリインタフェース４０は、制御部３０の制御に基づいて、揮発性メモリ２０に一時的に記憶されたデータを不揮発性メモリ１０に書き込んだり、不揮発性メモリ１０に記憶されているデータを読み出して揮発性メモリ２０に転送したりする。メモリインタフェース４０は、揮発性メモリ２０とのインタフェース処理を行う回路と、不揮発性メモリ１０とのインタフェース処理を行う回路と、を独立して備えてもよい。

【0021】

制御部３０は、不揮発性メモリ１０に記憶されたシステムプログラム（ファームウエア）と、このファームウェアを実行するプロセッサによってその機能が実現される。なお、制御部３０が実行する処理の一部または全部は、コントローラ６０内の専用ハードウェアによって実行されてもよい。制御部３０は、データアクセス部３２、ブロック管理部３１を備える。データアクセス部３２は、揮発性メモリ２０のライトバッファを介した不揮発性メモリ１０への書き込み処理、不揮発性メモリ１０からの読み出し処理、不揮発性メモリ１０に記憶されたデータの管理（例えば、強制リフレッシュ）などを実行する。

【0022】

強制リフレッシュは、不揮発性メモリ１０のメモリセルにおけるデータリテンションに対する処理である。強制リフレッシュは、ブロックに記録されているすべてのユーザデータ１１を一定周期ごとに新しい論理ブロックに書き直す（リフレッシュする）処理である。強制リフレッシュは、論理ブロック単位で実行される。強制リフレッシュは、実行する単位（例えば、論理ブロックや所定量のデータ）ごとにカウンタ（時間）を設定し、実行したことに応じてカウンタをリセットする。なお、強制リフレッシュの実行順は、物理ブロックにつけられた一意な番号順（アドレス順）となる。この番号は、ドライブが動作し続けている限り変わることはない。

【0023】

すなわち、データアクセス部３２は、不揮発性メモリ１０の複数の物理ブロックに対して、複数のブロックに含まれる第１の複数ブロックのデータを第２の複数ブロックに書き換えるリフレッシュを実行する。

【0024】

ところで、強制リフレッシュは、周期内にコンパクションを含めた処理を完了することが求められる。そのため、対象となるデータに対して同じタイミングで、コンパクションを兼ねた強制リフレッシュが実行されることがある。なお、コンパクションは、論理ブロック内の有効データを集めて別の論理ブロックに書き直すことで、新たなフリーブロックを生成する処理である。フリーブロックは、有効データを含まない論理ブロックである。

【0025】

強制リフレッシュは、強制リフレッシュの実行の単位時間に基づいて任意の分割時間当たりの処理数の最大値であるWorst Caseを想定して動作をする。本実施形態におけるWorst Case時の処理数は、１２とする。ただし、Worst Caseを想定して動作すると、強制リフレッシュの実際のリードライトの実行は、単位時間内の前半に偏ることになる。

【0026】

なお、強制リフレッシュは、動的に実行周期を設定することにより、ドライブの状態に合わせた強制リフレッシュに含まれるコンパクションの実行の速度を設定することができる。ただし、強制リフレッシュに含まれるコンパクションの実行は、タイミングを考慮する必要ある。

【0027】

加えて、ホスト２００との間におけるデータの入出力であるホストＩ／Ｏの進行状況が、強制リフレッシュにより影響を受けることがある。

【0028】

ブロック管理部３１は、メモリシステムの製造段階での初回電源投入時に論理ブロックの構築処理を行い、その構築結果を論理ブロック管理情報１３に登録する。ここで、物理ブロックと論理ブロックとの関係について、図３を用いて説明する。

【0029】

図３は、物理ブロックと論理ブロックとの関係を示す図である。図３に示すように、チャネル０～チャネル３にＢａｎｋ０～Ｂａｎｋ１が存在する場合に、ブロック管理部３１は、これらを１つの論理ブロック１５０として構築する。この場合、ブロック管理部３１は、論理ブロック１５０に対応する８つのバンクを、Ｂａｎｋ０～Ｂａｎｋ７と設定する。このように、ブロック管理部３１は、複数のバンクを有する論理ブロック１５０を構築する。

【0030】

ところで、強制リフレッシュは、強制リフレッシュの実行周期の加速を防ぐために、可能な限り周期通りのタイミングで実行する必要がある。

【0031】

ここで、図４は比較例における強制リフレッシュの処理の例を示す図である。図４は、強制リフレッシュの実行周期が１２０Ｈ（Ｈ：時間）、Worst Caseの強制リフレッシュの実行の単位時間が３０Ｈ、に設定される例を示す。この場合、強制リフレッシュの開始が、ホスト２００からの書き込みであるHost Writeの実行から９０Ｈ後に設定されている。また、図４に示す例では、１０の物理ブロック（以下、ブロックという）を対象にHost Writeが行われたものとする。すなわち、図４に示す例では、１２０Ｈの周期で強制リフレッシュが行われるのではなく、Worst Case対策として９０Ｈで強制リフレッシュが開始されることになる。しかしながら、図４に示すように、強制リフレッシュの開始後、１０Ｈで処理完了するような場合、強制リフレッシュの実行周期に対して２０Ｈの余裕があるので、強制リフレッシュの実行を後ろ倒しにすることができる。

【0032】

そこで、実施形態では、データアクセス部３２は、強制リフレッシュの周期の加速を緩和するために、強制リフレッシュの処理時間に余裕がある場合、強制リフレッシュの実行を後ろ倒しにする処理を実行する。

【0033】

言い換えれば、データアクセス部３２は、第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから各ブロックに対するリフレッシュを完了するまでの第１時間において、各ブロックに対するリフレッシュを開始する時間を動的に制御可能である。

【0034】

以下において、強制リフレッシュの実行を後ろ倒しにする強制リフレッシュ処理の手順を説明する。

【0035】

図５は、実施形態にかかる強制リフレッシュ処理の手順を示すフローチャートである。

【0036】

まず、データアクセス部３２は、強制リフレッシュ処理の実行タイミングになったかを判断する（Ｓ１）。データアクセス部３２は、強制リフレッシュ処理の実行タイミングになったと判断した場合（Ｓ１のＹｅｓ）、単位時間にHost Writeしたブロックを対象ブロックに決定する（Ｓ２）。

【0037】

次いで、データアクセス部３２は、強制リフレッシュの対象となるブロックに対する強制リフレッシュの実行タイミングをスケジューリングする（Ｓ３）。

【0038】

次いで、データアクセス部３２は、スケジュールにしたがって強制リフレッシュを実行する（Ｓ４）。

【0039】

以下において、図５のＳ２における対象ブロックの決定処理について説明する。

【0040】

ここで、図６はHost Writeの対象となるユーザデータ１１の保存先として供給されたアクティブブロックの順で強制リフレッシュのリストを作成する例を示す図である。図６に示すように、データアクセス部３２は、アクティブブロックおよび未使用ブロックの集合であるブロック群からユーザデータ１１の保存先となるアクティブブロックをランダムに選択する。データアクセス部３２は、選択されたアクティブブロックを、選択された順に並び替えて強制リフレッシュリストを作成する。

【0041】

このように、Host Writeの対象のユーザデータ１１の保存先としてランダムに選択されたアクティブブロックの順でリストを作成することで、以下のメリットがある。第１に、管理するブロックの数が必要最小限の数となる。第２に、リストの先頭のブロックから強制リフレッシュを実行することで、強制リフレッシュ実行順もランダムとなる。例えば、一意な順で強制リフレッシュを実行する場合、強制リフレッシュの実行のたびに、特定のブロックのみが早い周期で強制リフレッシュを実行することになる。しかし、アクティブブロックをランダムに選択することで、この現象を回避することができる。第３に、ユーザデータ１１の書き込み順で強制リフレッシュが実行される。

【0042】

なお、リストに登録したブロックの疲弊度が異なる場合、疲弊度に基づいて、リスト内で順序を入れ替えてもよい。例えば、疲弊度が高いブロックは早く強制リフレッシュが実行されるように順序を入れ替えてもよい。

【0043】

以下において、図５のＳ３およびＳ４の処理について説明する。

【0044】

図７は実施形態における強制リフレッシュの処理の例を示す図である。図７に示す例は、強制リフレッシュの実行周期が１２０Ｈに設定され、Worst Caseの強制リフレッシュの実行の単位時間が３０Ｈに設定される例を示す。

【0045】

具体的には、データアクセス部３２は、強制リフレッシュのスケジューリングを実行するにあたり、使用中のブロックのリストであるアクティブブロックリストを用いる。アクティブブロックは、使用中のブロックである。データアクセス部３２は、アクティブブロックリストを用いて、ユーザデータ１１の保存先として供給されたアクティブブロックの順で、強制リフレッシュの実行順を示す強制リフレッシュリストを作成する。図７においては、Host Writeされたブロックが、番号順に強制リフレッシュリストに登録されている。

【0046】

また、データアクセス部３２は、Worst Caseの強制リフレッシュの実行の単位時間に基づいて、任意の分割時間当たりの強制リフレッシュを実行するブロック数を導出する。例えば、データアクセス部３２は、Worst Caseの強制リフレッシュの実行の単位時間を３０Ｈ、任意の分割時間を１０Ｈとして、分割単位時間当たりのブロック数を導出する。なお、図７に示す例における任意の分割時間当たりの処理数の最大値は、Worst Case時の処理数（本実施形態では１２とする）と同数であり、１２である。

【0047】

この場合、Host Writeされたブロックを単位時間（３０Ｈ）毎にリフレッシュすることになる。すなわち、データアクセス部３２は、単位時間（３０Ｈ）ずつHost Writeの実行順に、強制リフレッシュを実行する。図７に示す例においては、Host Writeされたブロックの数が３５であり、規定時間経過（９０Ｈ）で強制リフレッシュが開始される。この場合、単位時間（３０Ｈ）における任意の分割時間（１０Ｈ）に１２個のブロックを処理すれば単位時間（３０Ｈ）で３６個のブロックを処理できるので、Worst Caseに対応可能である。

【0048】

図７に示す例によれば、最初の単位時間（３０Ｈ）で１５個のブロックを強制リフレッシュ処理している。しかし、強制リフレッシュの処理時間に余裕があれば、強制リフレッシュの実行を後ろ倒しにすることができる。

【0049】

なお、図７における横軸において、開始位置０が３箇所（時間軸が３つ）あるのは、単位時間（３０Ｈ）ずつのHost Writeの実行順における、強制リフレッシュの実行周期（１２０Ｈ）を示すものである。後述する図８および図９においても同様である。

【0050】

図８は、実施形態における強制リフレッシュの処理の別の例を説明する図である。図８は、強制リフレッシュの実行をより後ろ倒しにする処理の例を示す図である。図８に示す例は、Worst Caseの処理時間を単位時間（３０Ｈ）とし、強制リフレッシュの全ての対象ブロックを任意の分割時間（１０Ｈ）に区分して、各単位時間内で後ろ詰めする例である。図８に示すように、１～３のブロックを対象とした強制リフレッシュが１００Ｈ～１１０Ｈにおいて実行され、４～１５のブロックを対象とした強制リフレッシュが１１０Ｈ～１２０Ｈにおいて実行される。図８に示す単純に周期を後ろ詰めする例によれば、Worst Caseの実行時間でスケジューリングするため改善しないブロックもあるが、改善されるドライブの方が多い。

【0051】

言い換えれば、データアクセス部３２は、第１の複数ブロックに含まれる各ブロックに対する前回の書き込みから各ブロックに対するリフレッシュを完了するまでの第１時間よりも第４時間前に各ブロックの何れかに対するリフレッシュを開始し、第４時間における後半にリフレッシュを開始するブロックの量が、第４時間における前半にリフレッシュを開始するブロックの量より多くなるように制御する。

【0052】

例えば、データアクセス部３２は、第４時間における後半に第１数のブロックに対するリフレッシュを開始し、第４時間において後半よりも前の第５時間に第１数のブロック以外の第２数のブロックに対するリフレッシュを開始するように制御する。

【0053】

上述したように、Worst Caseの処理時間を単位時間とし、その単位時間で強制リフレッシュを実行するブロックをスケジューリングする。これにより、強制リフレッシュを不必要に早めに実行しないようにすることができるので、強制リフレッシュの実行周期の加速を軽減することができる。

【0054】

従来においては、このようなホストＩ／Ｏへの影響を緩和したいという要望がある。そこで、本実施形態では、ホストＩ／Ｏへの影響を緩和するために、以下の処理を実行する。

【0055】

図９は、実施形態における強制リフレッシュの処理の更に別の例を説明する図である。図９は、強制リフレッシュの実行を分散する処理の例を示す図である。図９に示す例では、３５ブロックを対象にHost Writeが行われたものとする。

【0056】

図８で示したように、強制リフレッシュの実行を、単純に後ろ詰めでスケジューリングするとホストＩ／Ｏへの影響が大きくなる場合がある。

【0057】

そこで、データアクセス部３２は、強制リフレッシュの処理時間における現在のホストＩ／Ｏの量を保存する。具体的には、任意の時間分のホストＩ／Ｏの量を所定時間ごとに計測して計測結果を記憶しておく。一例では、１０時間分のホストＩ／Ｏの量を、１時間ごとに計測して１０個の計測結果を記憶する。

【0058】

その後、データアクセス部３２は、計測結果と現在のホストＩ／Ｏの量を比較し、強制リフレッシュの速度又は開始タイミング（開始時間）を決める。すなわち、データアクセス部３２は、ホスト２００から要求されるデータのリード及びライトに対応するホストＩ／Ｏの量に基づいて、リフレッシュを開始する時間を制御する。例えば、データアクセス部３２は、ホストＩ／Ｏの量を一定期間取得し、現在のホストＩ／Ｏの量が一定期間に取得したホストＩ／Ｏの量に対して少ない場合、強制リフレッシュの実行の開始タイミングを遅らせる。また、現在のホストＩ／Ｏの量が一定期間に取得したホストＩ／Ｏの量に対して少ない場合、強制リフレッシュの実行の開始タイミングを分散して強制リフレッシュの周期を緩和する。例えば、データアクセス部３２は、計測結果と比較して、現在のHost Write量が多い場合、強制リフレッシュを実行するタイミングを先に延ばす。

【0059】

具体的には、図９に示すように、データアクセス部３２は、計測する期間を１００Ｈとして、強制リフレッシュの速度調整を任意の分割時間（１０Ｈ）ごとに実行する。データアクセス部３２は、９０Ｈ経過した段階で、そこから３０Ｈの間に１５ブロックを対象に強制リフレッシュを実行することを決定する。ここで、データアクセス部３２は、直近の１００Ｈで３５ブロック（１～３５ブロック）に対してHost Writeし、直前の任意の分割時間（１０Ｈ）で１０ブロック（２６～３５ブロック）に対してHost Writeしているため、現在の状態はHost Write量が相対的に多いと判断する。そして、データアクセス部３２は、Host Write量が多いことによりHost Writeによるデータ移動が期待できるので、強制リフレッシュの実行対象のブロック数を減らす。

【0060】

すなわち、データアクセス部３２は、Host Writeが多いWorkload（処理量）の場合、図９に示すように、直近に実行する強制リフレッシュのブロック数を減らして、より後ろの時間帯に繰り越す。この場合、Host Writeによるデータのリフレッシュが実行されることで、直近の強制リフレッシュの実行対象のブロック数の削減が期待できるため、無駄な疲弊を抑止することができるとともに、ホストＩ／Ｏへの影響を軽減することが可能となる。

【0061】

具体的には、図９に示すように、１～３のブロックを対象とした強制リフレッシュが９０Ｈ～１００Ｈにおいて実行され、４～９のブロックを対象とした強制リフレッシュが１００Ｈ～１１０Ｈにおいて実行され、１０～１５のブロックを対象とした強制リフレッシュが１１０Ｈ～１２０Ｈにおいて実行される。図９に示す例では、９０Ｈ～１００Ｈで強制リフレッシュを実行するブロックの量を、１００Ｈ以降の分割時間に強制リフレッシュを実行するブロックの量よりも削減する。図９に示す例では、データアクセス部３２は、単位時間のうち最初の分割時間では、強制リフレッシュの対象となるHost Writeのうち最初の１０Ｈにおいて実行されたHost Writeのブロック数（４ブロック）から１ブロック削減する。またデータアクセス部３２は、単位時間におけるそれ以降の分割時間では、残りの４～９のブロックと１０～１５のブロックとを均等に処理する。以上により、データアクセス部３２は、９０Ｈ～１２０Ｈにおける強制リフレッシュを、分割時間当たりの処理数の最大値の半分以下の速度で実行していく。すなわち、データアクセス部３２は、第１の複数ブロックに含まれる第１ブロック及び第２ブロックについて、第１ブロック及び第２ブロックに対する前回の書き込みは同じ第１タイミングで実行されている場合、第１タイミングから第１ブロックに対するリフレッシュを開始するまでの時間と、第１タイミングから第２ブロックに対するリフレッシュを開始するまでの時間と、が異なるように制御する。

【0062】

なお、データアクセス部３２は、Host Writeが少ないWorkload（処理量）の場合、直近に実行する強制リフレッシュのブロック数を減らさず、単位時間内で強制リフレッシュを実行するブロック数を後ろに繰り越さない。これにより、コンパクションの速度を可能な限り低下させるとともにホストＩ／Ｏへの影響を軽減することが可能となる。

【0063】

このように本実施形態によれば、強制リフレッシュの開始タイミングと、強制リフレッシュに含まれるコンパクションの速度とを、動的に変更できる機構を持つことにより、スケジュールに余裕がある場合は開始タイミングを後ろにずらし周期の加速を緩和させ、また強制リフレッシュ速度を制御することでホストＩ／Ｏへの影響も軽減することができる。

【0064】

また、本実施形態によれば、Host Writeが多いWorkload（処理量）の場合、Host Writeによるデータのリフレッシュが期待できるため、直近に実行する強制リフレッシュのブロック数を減らす様に、より後ろの時間帯に繰り越す。これにより、強制リフレッシュの実行対象のブロック数の削減が期待できるため、無駄な疲弊を抑止することができるとともに、ホストＩ／Ｏへの影響を軽減することが可能となる。

【0065】

また、本実施形態によれば、Host Readが少ないWorkload（処理量）の場合、Host Writeによるデータのリフレッシュが期待できないため、強制リフレッシュの開始タイミングは後ろにずらさず、強制リフレッシュに含まれるコンパクションの速度を可能な限り低下させる。これにより、ホストＩ／Ｏへの影響を軽減することが可能となる。

【0066】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0067】

１０ 不揮発性メモリ
３２ データアクセス部
１００ メモリシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】