KR20220030188A - 통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 - Google Patents
통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 Download PDFInfo
- Publication number
- KR20220030188A KR20220030188A KR1020210116204A KR20210116204A KR20220030188A KR 20220030188 A KR20220030188 A KR 20220030188A KR 1020210116204 A KR1020210116204 A KR 1020210116204A KR 20210116204 A KR20210116204 A KR 20210116204A KR 20220030188 A KR20220030188 A KR 20220030188A
- Authority
- KR
- South Korea
- Prior art keywords
- block
- storage medium
- statement
- storage
- blocks
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
- G06F11/1008—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's in individual solid state devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3034—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a storage system, e.g. DASD based or network based
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/064—Management of blocks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Human Computer Interaction (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
- Debugging And Monitoring (AREA)
Abstract
스토리지 장치가 개시된다. 제 1 스토리지 매체는 데이터를 저장할 수 있다. 제 1 스토리지 매체는 제 1 스토리지 유형일 수 있고 적어도 2개의 블록들로 구성될 수 있다. 제 2 스토리지 매체는 또한 데이터를 저장할 수 있다. 제 2 스토리지 매체는 제 1 스토리지 유형과 다른 제 2 스토리지 유형일 수 있으며, 또한 적어도 2개의 블록으로 구성될 수 있다. 컨트롤러는 제 1 스토리지 매체 및 제 2 스토리지 매체에 대한 데이터 읽기 및 쓰기를 관리할 수 있다. 메타데이터 스토리지는 스토리지 장치의 에러들에 대한 장치-기반 로그 데이터를 저장할 수 있다. 장치-기반 로그 데이터는 제 1 스토리지 매체 및 제 2 스토리지 매체에 대한 통합 로그 데이터를 포함할 수 있다. 식별 회로는 통합 로그 데이터에 응답하여 제 1 스토리지 매체 및 제 2 스토리지 매체 내의 적어도 2개의 블록에서 의심되는 블록을 식별할 수 있다. 제 1 스토리지 매체 및 제 2 스토리지 매체에 대한 파라미터들은 각 스토리지 매체에 대한 쓰기 동작들의 개수 및 읽기 동작들의 개수에 비례하여 통합된 로그 데이터의 통합된 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
Description
본 개시는 일반적으로 스토리지 장치에 관한 것으로, 특히 SSD(Solid State Drive)에서 개선된 블록들의 고장 예측 방안에 관한 것이다.
필드에서의 SSD(Solid State Drive) 고장(failure)들은 서버 중단(shutdown)으로 이어질 수 있으며, 따라서 데이터 센터 규모 애플리케이션들의 성능과 가용성(availability)을 손상시킬 수 있다. 이러한 예기치 않은 고장들을 방지하기 위해, SSD들을 이용하는 시스템들은 일반적으로 간단한 임계값 기반 모델들을 사용하여 장애가 발생하기 전에 드라이브들을 교체하여 이러한 고장들을 방지한다. 이러한 보호 메커니즘들은 높은 수준의 잘못된 경고들로 이어 지거나 모든 SSD 고장들을 예측/방지할 수 없다. 또한 물리적 에러가 발생한 경우, SSD는 에러에서 복구할 수 없고, 이에 따라 장치 에러를 방지할 수 없다.
세분화된 블록 장애 예측을 제공할 필요성이 존재한다.
본 개시의 목적은 통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안을 제공하는데 있다.
본 개시의 실시 예에 따른 스토리지 장치는 적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체, 적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체, 제 1 스토리지 매체 및 제 2 스토리지 매체로부터의 데이터 읽기 및 쓰기를 관리하는 컨트롤러, 스토리지 장치의 에러에 대한 장치-기반 로그 데이터를 저장하는 메타데이터 스토리지, 에러들에 대한 장치-기반 로그 데이터는 제 1 스토리지 매체 및 제 2 스토리지 매체에 대한 통합 로그 데이터를 포함함, 및 통합 로그 데이터에 응답하여 적어도 2 개의 제 1 블록들 및 적어도 2 개의 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함하고, 제 1 스토리지 매체에 대한 제 1 파라미터는 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제2 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
본 개시의 실시 예에 따른 방법은 스토리지 장치의 에러들을 추적하는 단계, 스토리지 장치는 제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하고, 제 1 스토리지 유형의 제 1 스토리지 매체는 적어도 두 개의 제 1 블록들로 구성되고, 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체는 적어도 두 개의 제 2 블록들로 구성됨, 스토리지 장치의 제 1 스토리지 매체 및 제 2 스토리지 매체의 에러들에 대한 통합 로그 데이터를 저장하는 단계, 및 통합 로그 데이터에 응답하여 제 1 블록들과 제 2 블록들에서 의심 블록을 식별하는 단계를 포함하고, 제 1 스토리지 매체에 대한 제 1 파라미터는 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
본 개시의 실시 예에 따른 비일시적 명령어들을 저장하는 비일시적 스토리지 매체를 포함하는 장치에 있어서, 명령어들이 머신에 의해 실행될 때: 스토리지 장치의 에러들을 추적하는 단계, 스토리지 장치는 제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하고, 제 1 스토리지 유형의 제 1 스토리지 매체는 적어도 두 개의 제 1 블록들로 구성되고, 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체는 적어도 두 개의 제 2 블록들로 구성됨, 스토리지 장치의 제 1 스토리지 매체 및 제 2 스토리지 매체의 에러들에 대한 통합 로그 데이터를 저장하는 단계, 및 통합 로그 데이터에 응답하여 제 1 블록들과 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하고, 제 1 스토리지 매체에 대한 제 1 파라미터는 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
본 개시의 실시 예에 따르면, 통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안이 제공된다.
도 1은 본 개시의 일 실시 예에 따른 세분화된 블록 고장 예측을 수행할 수 있는 SSD(Solid State Drive)를 포함하는 시스템을 나타낸다.
도 2는 본 개시의 일 실시 예에 따른 도 1의 머신(machine)의 세부 사항들을 나타낸다.
도 3은 본 개시의 일 실시 예에 따른 도 1의 SSD의 세부 사항들을 나타낸다.
도 4는 본 개시의 일 실시 예에 따른 도 1의 SSD에 의해 사용될 수 있는 예시적인 블록-기반 데이터를 나타낸다.
도 5는 본 개시의 일 실시 예에 따른 도 1의 SSD에서 사용될 수 있는 장치-기반 로그 데이터를 나타낸다.
도 6은 본 개시의 일 실시 예에 따른 도 3의 특정 블록이 고장(fail)날 것으로 예상되는지 여부를 결정하도록 동작하는 식별(identification) 펌웨어 및 검증 펌웨어를 나타낸다.
도 7a 및 도 7b는 본 개시의 일 실시 예에 따른 블록이 고장 날 것으로 예상되는지 여부를 결정하는 예시적인 절차를 나타내는 흐름도이다.
도 8은 두 가지 다른 유형들의 NAND(Not-AND) 플래시 스토리지를 사용하는 도 1의 SSD의 세부 사항들을 나타낸다.
도 9는 본 개시의 일 실시 예에 따른 도 8의 SSD에 의해 사용될 수 있는 예시적인 블록-기반 데이터를 도시한다.
도 10은 본 개시의 일 실시 예에 따른 도 8의 SSD에 의해 사용될 수 있는 장치-기반 로그 데이터를 나타낸다.
도 11은 본 개시의 다른 실시 예에 따른 스토리지 유형 파라미터를 결정하기 위해 다른 정보와 함께 도 5의 장치-기반 로그 데이터를 사용하는 것을 나타낸다.
도 12는 본 개시의 일 실시 예에 따른 다른 스토리지 유형들에 대한 부분들로 분할된, 도 8의 SSD에 의해 사용될 수 있는 에러 이력(history) 테이블을 나타낸다.
도 13a 및 도 13b는 본 개시의 실시 예들에 따른 도 8의 SSD에서 특정 스토리지 유형의 블록이 고장 날 것으로 예상되는지 여부를 검증하기 위해 사용될 수 있는 상이한 모델들을 나타낸다.
도 14a 및 도 14b는 본 개시의 실시 예들에 따른 도 8의 SSD에서 블록이 고장 날 것으로 예상되는지 여부를 결정하기 위한 예시적인 절차의 흐름도를 나타낸다.
도 15는 본 개시의 일 실시 예에 따른 도 8의 SSD에서 장치-기반 로그 데이터를 저장하기 위한 예시적인 절차의 흐름도를 나타낸다.
도 16은 본 개시의 일 실시 예에 따른 도 8의 SSD에서 예측된 블록이 고장 날 것으로 예상되는지 여부를 검증하기 위해 모델들을 사용하기 위한 예시적인 절차의 흐름도를 나타낸다.
도 2는 본 개시의 일 실시 예에 따른 도 1의 머신(machine)의 세부 사항들을 나타낸다.
도 3은 본 개시의 일 실시 예에 따른 도 1의 SSD의 세부 사항들을 나타낸다.
도 4는 본 개시의 일 실시 예에 따른 도 1의 SSD에 의해 사용될 수 있는 예시적인 블록-기반 데이터를 나타낸다.
도 5는 본 개시의 일 실시 예에 따른 도 1의 SSD에서 사용될 수 있는 장치-기반 로그 데이터를 나타낸다.
도 6은 본 개시의 일 실시 예에 따른 도 3의 특정 블록이 고장(fail)날 것으로 예상되는지 여부를 결정하도록 동작하는 식별(identification) 펌웨어 및 검증 펌웨어를 나타낸다.
도 7a 및 도 7b는 본 개시의 일 실시 예에 따른 블록이 고장 날 것으로 예상되는지 여부를 결정하는 예시적인 절차를 나타내는 흐름도이다.
도 8은 두 가지 다른 유형들의 NAND(Not-AND) 플래시 스토리지를 사용하는 도 1의 SSD의 세부 사항들을 나타낸다.
도 9는 본 개시의 일 실시 예에 따른 도 8의 SSD에 의해 사용될 수 있는 예시적인 블록-기반 데이터를 도시한다.
도 10은 본 개시의 일 실시 예에 따른 도 8의 SSD에 의해 사용될 수 있는 장치-기반 로그 데이터를 나타낸다.
도 11은 본 개시의 다른 실시 예에 따른 스토리지 유형 파라미터를 결정하기 위해 다른 정보와 함께 도 5의 장치-기반 로그 데이터를 사용하는 것을 나타낸다.
도 12는 본 개시의 일 실시 예에 따른 다른 스토리지 유형들에 대한 부분들로 분할된, 도 8의 SSD에 의해 사용될 수 있는 에러 이력(history) 테이블을 나타낸다.
도 13a 및 도 13b는 본 개시의 실시 예들에 따른 도 8의 SSD에서 특정 스토리지 유형의 블록이 고장 날 것으로 예상되는지 여부를 검증하기 위해 사용될 수 있는 상이한 모델들을 나타낸다.
도 14a 및 도 14b는 본 개시의 실시 예들에 따른 도 8의 SSD에서 블록이 고장 날 것으로 예상되는지 여부를 결정하기 위한 예시적인 절차의 흐름도를 나타낸다.
도 15는 본 개시의 일 실시 예에 따른 도 8의 SSD에서 장치-기반 로그 데이터를 저장하기 위한 예시적인 절차의 흐름도를 나타낸다.
도 16은 본 개시의 일 실시 예에 따른 도 8의 SSD에서 예측된 블록이 고장 날 것으로 예상되는지 여부를 검증하기 위해 모델들을 사용하기 위한 예시적인 절차의 흐름도를 나타낸다.
본 개시의 실시 예들을 상세히 참조할 것이며, 그 예들은 첨부된 도면들에 도시된다. 이하의 상세한 설명에서, 본 개시의 완전한 이해를 가능하게 하기 위해 다수의 특정 세부 사항들이 제시된다. 그러나, 통상의 기술자는 이러한 특정 세부 사항들 없이 본 개시를 실시할 수 있음을 이해해야 한다. 다른 예들에서, 잘 알려진 방법들, 절차들, 구성 요소들, 회로들 및 네트워크들은 실시 예들의 측면을 불필요하게 모호하게 하지 않도록 상세하게 설명되지 않았다.
비록 제 1, 제 2 등의 용어가 본 명세서에서 다양한 요소들을 설명하기 위해 사용될 수 있지만, 이들 요소들은 이들 용어들에 의해 제한되어서는 안됨을 것을 이해할 것이다. 이 용어들은 한 요소를 다른 요소와 구별하는 데만 사용된다. 예를 들어, 본 개시의 범위를 벗어나지 않는 한, 제 1 모듈은 제 2 모듈로 명명될 수 있고, 유사하게 제 2 모듈은 제 1 모듈로 명명될 수 있다.
본 개시를 설명하는데 사용되는 용어는 특정 실시 예들을 설명하기 위한 것이며 본 개시를 제한하려는 의도는 아니다. 본 개시의 설명 및 첨부된 청구 범위에서 사용된 바와 같이, 단수형은 문맥상 명백하게 달리 나타내지 않는 한 복수형도 포함하도록 의도된다. 본 명세서에서 사용된 용어 "및/또는"은 하나 이상의 연관된 열거된 항목들의 임의 및 모든 가능한 조합들을 지칭하고 포함하는 것으로 또한 이해될 것이다. 본 명세서에서 "포함하는"이라는 용어가 사용될 때 "포함하는"이라는 용어는 언급된 특징들, 정수들, 단계들, 동작들, 요소들 및/또는 구성 요소들의 존재를 지정하지만, 하나 이상의 다른 특징들, 정수들, 단계들, 동작들, 요소들, 구성 요소들 및/또는 그 그룹들의 추가 또는 존재를 배제하지 않음을 추가로 이해될 것이다. 도면들의 구성 요소들과 특징들은 반드시 축척에 따라 그려지지는 않는다.
본 개시의 다양한 실시 예들에서, 개시된 시스템들은 일반적으로 에러(또는 오류)(error)들의 조기 탐지 및 격리(또는 고립)를 위한 펌웨어 기반 SSD(Solid State Drive) 고장(또는, 장애, 에러, 실패)(failure) 보호 메커니즘에 관한 것이다. 이 고장 메커니즘은 드라이브의 고장을 방지하거나 적어도 드라이브를 조기에 교체하는 것을 방지할 수 있다.
SSD는 각각 다수의 블록들을 포함하는 여러 플래시(flash) 칩들을 포함할 수 있다. 블록은 여러 페이지들을 포함할 수 있다. 페이지의 크기는 일반적으로 몇 킬로바이트(kilobytes)이며 일반적으로 SSD에 데이터를 읽고 쓰는 데 가장 작은 단위이다. SSD 컨트롤러(펌웨어에서 구현될 수 있음)는 읽기 및 쓰기 요청들을 제공(service)하고, 웨어 레벨링(wear-levelling) 알고리즘들을 실행하고, 에러 복구 절차들을 실행하고, 이들의 조합들 및/또는 이와 유사한 것들을 실행하는 데 사용되는 로직을 포함할 수 있다.
일부 측면에서, SSD 페이지는 SSD 컨트롤러가 제한된 수의 비트 에러들 (일반적으로 1-2 비트 에러들)을 복구하고 수정하는 데 사용할 수 있는 ECC(Error Correction Code) 메타 데이터를 포함할 수 있다. 하드웨어 장애로 인한 비트 에러들의 개수가 특정 수를 초과하면, SSD 컨트롤러가 에러를 수정할 수 없으므로, SSD 컨트롤러는 손상된 데이터를 호스트에 제공할 수 있다. 이러한 장애들이 여러 번 발생하면 장치는 교체를 위해 선택될 수 있으며, 이는 장치 제조업체에 상대적으로 높은 비용을 초래할 수 있으며, 그에 따른 서버 종료(shutdown)로 인해 애플리케이션들의 성능과 가용성이 더욱 저하될 수 있다.
한편, 플래시 페이지에 데이터를 쓸 때(예를 들어, 프로그램 동작 중), 에러가 발생하면 페이지는 "고장"으로 표시(mark)되고 더 이상 사용되지 않을 수 있다. 블록에서 특정 개수의 페이지들이 고장 나면, 블록 전체가 폐기(retire)될 수 있다. SSD는 일반적으로 이러한 철회된(withdrawn) 블록들을 대체하기 위해 일부 예비 블록들(spare blocks)을 보유(reserve)한다. SSD는 사용 가능한 예비 블록들의 개수가 부족하면(예를 들어, 예비 블록들의 약 90 % 이상 사용됨) 장치를 교체해야 할 수 있다.
드라이브에서 대부분의 블록들이 정상적으로 기능하고(정상 블록들), 그 중 일부가 결함이 있는(불량 블록들) 상황들이 있을 수 있다. 읽기 동작들은 불량 블록들에 타겟되고 자주 고장 나는 경우(손상된 데이터 읽기 또는 하드웨어 장애들로 인한 읽기 고장), 향후 고장을 방지하고 데이터 손실을 방지하기 위해 전체 드라이브는 교체를 위해 타겟(target)될 수 있다. 그러나 세분화된 블록 에러들/결함들은 조기에 예측되고 이후에 방지/복구될 수 있는 경우, 불량 블록들은 폐기/철회될 수 있으며, 이는 SSD가 해당 블록들에 데이터를 저장하지 못하도록 하여 추가 고장들 및 데이터 손상/손실을 방지할 수 있다.
SSD들(수천 개의 블록들을 포함함)에서 세분화된 (블록-레벨) 에러들/결함들을 예측하는 것은 (i) SSD의 블록들에 대응하는 비교적 많은 양의 이력(또는 히스토리)(예를 들어, 시계열) 데이터를 저장하는 것, 및 (ii) 고장을 예측하고 방지하기 위해 비교적 큰 데이터 세트들을 처리/분석하는 것을 포함할 수 있다 필요한 이력 데이터의 양과 관련하여, 이러한 메타 데이터 정보는 SSD의 DRAM(Dynamic Random Access Memory) 공간 또는 플래시 메모리 자체에 저장되고, 저장되는 데이터의 양은 장애 이력 정보가 증가함에 따라 증가한다. 이 정보를 저장하는 것은 비교적 높은 스토리지 비용이 발생하고 드라이브 용량의 대부분을 희생할 수도 있다. 제한된 양의 DRAM을 구현하고 기가바이트(gigabyte) 당 가격에 민감한 스토리지 장치를 사용하면, 데이터 저장 요구 사항들이 사소하지 않으며, 이러한 장애 시계열 데이터를 저장하기 위해 장치의 스토리지 용량의 상당 부분을 희생하는 것이 간단하거나 합리적으로 효율적이지 않는다.
예측들을 수행하는 데 필요한 처리(또는 프로세싱)와 관련하여, SSD들은 일반적으로 제한된 프로세싱 파워(processing power)를 가지며, 이는 주로 플래시 변환 계층, 웨어 레벨링 및 스케줄링과 같은 내부 동작들에 사용된다. 블록-레벨의 고장들/에러들을 예측하기 위해 SSD 내부에서 많은 양의 데이터를 처리하는 것은 어려울 수 있다.
블록-레벨 고장 예측에 관한 위의 과제들을 해결하기 위해, 본 개시의 실시 예들은 각 블록 및/또는 각 블록 내의 페이지들에서 물리적 에러들의 시간적(temporal) 및 공간적(spatial) 지역성(locality)을 활용한다. 시간적 지역성은 동일한 물리적 페이지 및/또는 블록에서 에러들이 자주 발생하는 것을 의미한다. 공간적 지역성은 인접한 물리적 부분들(예를 들어, 페이지 또는 블록)에서 에러들이 발생하는 것을 의미한다. 에러들의 발생들의 지역성을 활용함으로써, (장치의 에러 이력 대신) 과거 여러 에러들과 관련된 비교적 제한된 양의 데이터만 필요할 수 있으며, 이는 블록 고장을 예측하는 데 사용될 수 있다. 일반적으로 잘못된 데이터를 생성한 페이지/블록이 향후 에러들을 생성할 가능성이 더 높을 것으로 예상될 수 있다. 또한 블록의 페이지가 고장 난 경우, 고장 난 페이지와 인접한 페이지들 모두 동일한 물리적 구성 요소에 있을 수 있으므로 동일한 블록에서 인접 페이지들에서 에러들이 발생할 가능성이 있다.
블록-레벨 고장들 예측
상술한 바와 같이, 블록-레벨 고장들을 예측하는 것은 상대적으로 복잡한 용량 및 처리 요구 사항들을 충족시키는 것을 포함할 수 있다. 한 가지 접근 방식은 정확한 예측을 위해 수천 개의 블록들에 해당하는 세분화된 히스토리 로그 데이터를 사용할 수 있지만, 이 데이터 세트 크기는 시간이 지남에 따라 증가하고 사용자 데이터의 스토리지를 축소할 수 있다. 대신, 본 개시의 실시 예들은 의심되는 블록을 찾기 위해 2 단계 식별 및 검증 메커니즘을 사용하고, 그 다음 블록의 미래 고장을 검증하기 위해 학습 기반 모델을 사용한다.
첫째, 의심되는 드라이브들을 식별하기 위해 물리적 에러들의 지역성을 활용하도록, 최근 에러 정보는 저장이 필요할 수 있다. 예를 들어, 에러 이력의 마지막 k 개 엔트리(entry)들만(즉, k개의 가장 최근의 사건들) 드라이브 작동 동안 전체 에러들의 이력 대신 유지될 수 있다. 마지막 k 개 엔트리들보다 오래된 에러들은 폐기(discard)될 수 있다. 이러한 정보는 가장 최근 에러들에 대한 정보를 저장하더라도, 에러들의 지역성으로 인해 의심되는 블록을 식별하는 데 도움이 될 수 있다. 예를 들어, 과거 100 개의 에러들 중 10 개의 에러들은 식별된 블록 내의 특정 페이지에 의해 생성된 경우, 그 사실은 동일한 페이지 또는 동일한 블록에서 인접한 페이지들에서 향후 에러들이 가능함을 시사한다. 따라서 과거 k 개의 에러들에 대한 정보가 주어지면, 장치의 전체 에러 이력보다 잠재적으로 훨씬 적은 데이터를 사용하여 의심되는 블록은 식별될 수 있다.
두 번째 단계에서, 의심되는 블록이 가까운 장래에 에러들을 일으킬 가능성이 있지만 이러한 블록들을 결함 블록들로 분류하고 폐기하는 것은 높은 비 효율성을 초래할 수 있다. 이러한 임계값 기반 식별 메커니즘(threshold-based identification mechanism)은 고장 정보를 정확하게 캡처하지 못할 수 있으며 잘못된 경고들을 생성하여, 정상적인 블록들을 폐기하고 드라이브의 용량을 낭비할 수 있다. 이러한 부정확한 임계값 기반 예측들을 방지하기 위해, 의심되는 블록을 식별한 후, 예측 모델(이미 훈련됨)은 블록 고장을 보다 정확하게 예측하도록 사용될 수 있다.
블록-레벨 파라미터들 획득
이전에 훈련된 예측 모델을 실행하는 것은 고장을 검증하기 위해 의심되는 블록과 관련된 시계열 정보가 필요하다. 이러한 세분화된 정보를 계속 추적하는 것은 스토리지 장치 용량을 훨씬 초과하는 대용량 요구 사항들이 발생할 수 있다. 대신, 본 개시의 실시 예들은 각 파라미터의 정의 및 해석과 관련하여, 이용 가능한 장치 기반 로그 데이터(직접 또는 일부 수정)로부터 블록-기반 로그 데이터의 일부를 추출하고 얻는다. 특히, 의심되는 블록에 대한 파라미터들의 집합을 구축하고(예를 들어, 수학식 1과 같이 설정) 이를 예측 모듈에 공급하기 위해, 로그 데이터를 두 가지 카테고리들로 분할할 수 있다.
(i) 정확한 블록-기반 로그 데이터:
(ii) 근사 블록-기반 로그 데이터:
그 다음, 집합(또는 세트) S를 도출 또는 유도(derive)하기 위해, 두 집합들(예를 들어, S_Block_Precis, S_Block_Approx)은 배타적(disjoint)이므로, 집합 S는 수학식 5와 같다. 에러/결함 정보(예를 들어, 읽기 에러들, 쓰기 에러들, 소거 에러들의 개수)와 직접 관련된 파라미터들의 경우 각 블록에 대한 정확한 정보가 저장될 수 있다. 필요한 블록-기반 데이터의 양은 상대적으로 미미할 수 있으며(예를 들어, 1TB SSD의 경우 몇 메가바이트(megabytes)만 필요할 수 있음) 이미 몇 기가바이트의 DRAM 공간을 포함하는 SSD에 의해 관리될 수 있다. 더욱이, 이러한 데이터는 시계열 정보를 참조하지 않으며, 블록 당 각 파라미터에 대해 하나의 카운터 일 뿐이다.
시계열 로그 데이터를 추출하기 위해, 이러한 정보는 과거 k 개의 에러들에 대해 유지되는 글로벌 드라이브 레벨 에러 정보로부터 유도될 수 있다. 의심되는 블록은 과거 k 개의 에러 사건들을 기반으로 선택되므로, 최근 에러 정보는 이미 글로벌 드라이브 레벨 에러 데이터에 존재한다. 드라이브와 관련된 최근 k 개 에러들에 대한 데이터에는 블록에 대한 누적된 에러 정보를 포함할 수 있으며, 이는 블록에 대한 에러 카운터들과 새 에러 데이터를 합산하여 유도(또는 파생)될 수 있다. 각 블록에 이용되는 카운터들은 누적 에러 정보만 포함한다. 글로벌 에러 정보는 의심되는 블록에 의해 생성된 에러들을 포함할 수 있는 가장 최근의 k 개의 에러들에 대한 완전한 데이터를 포함한다.
블록에 대한 근사 파라미터들(approximate parameters)(예를 들어, S_Block_Approx)는 드라이브 레벨 에러 정보로부터 추출될 수 있다. 의심되는 블록에 대한 일부 로그 정보는 에러 정보가 아닌 드라이브/블록의 상태를 참조하므로, 드라이브 레벨 파라미터들로부터 대략적으로 유도될 수 있다. 즉, 이러한 파라미터들은 모든 블록들에서 평균화될 수 있으므로, 단일 블록을 대표할 수 있다. 예를 들어, 드라이브에 대한 읽기들 및 쓰기들의 총 회수(또는 개수)를 기반으로 하며, 드라이브 수명을 나타내고, "읽기들의 회수" 및 "쓰기들의 회수"와 같은 일부 파라미터들은 의심되는 블록에 대한 대응하는 파라미터들을 근사화하기 위해 모든 블록에서 평균화될 수 있다.
이력(또는 히스토리) 기반 드라이브 정보를 카운터 기반 블록-레벨 로그 데이터와 결합함으로써, 의심되는 블록에 대한 파라미터들의 세트가 생성되고 예측 모듈에 공급될 수 있다. 그 다음, 의심되는 블록에 대한 고장 경고가 발생하면, 해당 블록과 관련된 추가 에러들 및 그에 따른 드라이브 교체를 방지하기 위해, 블록이 조기에 폐기될 수 있다. 따라서 점점 커질 수 있는 각 블록에 대한 시계열 데이터를 유지하는 대신 각 블록에 대한 경량(light-weight) 카운터들만 유지될 필요가 있다. 더욱이, 시계열 드라이브 정보의 경우 가장 최근의 k 개의 에러 사건들만 유지될 수 있고, 이는 몇 킬로바이트(kilobyte)의 데이터만을 차지한다. 이러한 최적화를 통해, 세분화된 블록-레벨의 고장 예측을 수행하는 데 필요한 데이터 세트 크기 및 계산/처리 요구 사항들은 해결된다. 제안된 개선 사항들에 필요한 데이터의 양은 단순히(na
ve) 블록-레벨 시계열 로그 데이터보다 적으며, 이러한 소량의 데이터에 대한 후속 처리는 상대적으로 빠르며, 예를 들어 실시간 실행을 허용할 수 있다.
필수 메타데이터 및 데이터 구조들
상술한 바와 같이, 각 블록에 대한 경량(light-weight) 에러 정보/카운터들은 SSD를 위한 DRAM 또는 다른 스토리지에 유지될 필요가 있다. SSD는 n 개의 블록들을 포함한다고 가정하면, n 개의 엔트리들만 필요하다. 한편, 드라이브 레벨 정보의 경우, 본 개시의 실시 예들은 과거 k 개의 에러 사건(또는 사고)(incident)들 정보를 유지할 수 있다. k 개의 에러 사건들 각각에 대해, 에러의 물리적 위치(페이지, 블록), 에러가 발생한 시간(타임 스탬프), 그 당시 블록의 에러 카운터들, SSD의 로그 데이터에 대한 정보가 저장될 수 있다.
상술한 바와 같이, 본 개시의 실시 예에 필요한 오버 헤드는 상대적으로 낮다. 1TB의 스토리지 용량, 블록 당 256 페이지들, 페이지 크기 4KB의 SSD를 가정한다.
각 블록에 대해 3 개의 에러 속성들(각각 4 바이트 정수일 수 있는 읽기 에러들, 쓰기 에러들 및 소거 에러들의 개수에 대한 카운터)이 있는 경우, 블록-레벨 에러 데이터에 대해 필요한 총 메모리 공간은 수학식 8과 같을 수 있다.
드라이브 레벨 정보의 경우, k = 100 (즉, 가장 최근의 100 개의 에러 사건들에 대한 정보가 저장됨)이고, 각 에러 사건은 1KB의 저장 공간이 필요하다고 가정한다. 따라서 드라이브 레벨 메타 데이터에 필요한 총 용량은 100KB 이다. 따라서 총 메모리 오버 헤드는 12.1MB가 되며, 이는 몇 기가바이트의 DRAM 공간을 포함하는 SSD의 경우 무시할 수 있는 수준이다.
SSD들에 대한 에러 로그 데이터는 일반적으로 펌웨어 및 장치 모델에 따라 다르다. 설명을 위해 저장될 수 있는 로그 데이터의 일부 파라미터들은 위험 경고(Critical Warning), 사용 가능한 공간(Available Space), 읽기 데이터 단위(Data Units Read), 쓰기 데이터 단위(Data Units Written), 전원 주기(Power Cycles), 전원 켜진 시간(Power On Hours), 불안정한 종료(Unsafe Shutdowns), 미디어 에러(Media Errors), 경고 온도 시간(Warning Temperature Time) 및 임계 복합 온도 시간(Critical Composite Temperature Time)을 포함한다. 본 개시의 실시 예들은 또한 다른 파라미터들을 저장할 수 있다.
실행 흐름
블록 I 에서 에러가 발생 사건의 경우, 블록-레벨 메타 데이터에 대한 에러 카운터들은 읽히고 업데이트될 수 있다. 그 다음 새로운 에러 사건 정보를 반영하도록 드라이브 레벨 메타 데이터는 업데이트될 수 있다. 드라이브 레벨 메타 데이터에 저장된 정보는 에러의 위치(페이지 ID/블록 ID), 타임 스탬프 등과 같이 위에서 설명한 파라미터들을 포함할 수 있다.
에러 발생
일단 에러가 발생하면, 그 타겟 블록으로부터 정확한 파라미터들이 얻어지고, 블록의 NAND(Not-AND) 플래시 유형에 따라 추출된 근사 파라미터들과 결합될 수 있다. 이 정보는 결함 이력 테이블(fault-history table)에 엔트리로 저장될 수 있다.
의심되는 블록을 식별
의심되는 블록을 식별하기 위해, 드라이브 레벨 메타 데이터 테이블은 블록이 반복된 에러들을 생성했는지 여부를 확인하도록 주기적으로 스캔 될 수 있다(이 테이블에서 블록 ID 필드를 확인함으로써). 이 스캔은 일정한(또는 정기적인)(regular) 간격으로(예를 들어, 매분마다) 또는 일부 에러들이 기록된 후(예를 들어, 모든 에러 후, 매 5 번째 에러마다 등) 수행될 수 있다. 동일한 블록에서 여러 과거 에러들이 발생한 경우, 해당 블록이 의심되는 블록 풀에 추가될 수 있다. 그러면 SSD가 일시적으로 데이터를 저장하는 데 그 블록을 사용하지 않을 수 있다(그 블록은 유효한 데이터를 포함할 수 있기 때문에, 그 블록은 여전히 읽힐 수 있음). 보다 구체적으로, 가장 최근의 k 개 에러들 중 특정 블록에 대응하는 사건들의 개수가 임계값 이상을 차지하는 경우, 해당 블록은 "의심됨"으로 표시된다.
임계값을 설정하는 두 가지 방법:
(1) 정적 임계 값 α를 정의한다. 특정 블록에 대응하는 에러 사건들의 수가 가장 최근의 k 개 에러들의 α %를 초과하면, 해당 블록을 의심됨으로 표시한다. 임계 파라미터 α는 보호/신뢰성 레벨 요구 사항들에 따라 조정될 수 있다. 예를 들어 α = 10으로 설정하는 것은, 가장 최근의 k 개의 에러 사건 중 10 % 이상이 특정 블록 ID와 관련된 경우, 해당 블록이 의심으로 표시됨을 나타낸다. 또는 α는 백분율이 아닌 고정된 숫자일 수 있다. 즉, α = 10으로 설정하는 것은, 가장 최근의 k 개의 에러 사건들 중 10 개 이상이 특정 블록 ID와 관련된 경우, 해당 블록이 의심으로 표시됨을 나타낸다.
(2) 평균 기반 임계값들을 정의한다. 이러한 임계값은 드라이브에서 모든 블록들에 대한 (장치 로그에서) 총 에러들의 개수를 평균하여 얻을 수 있다. 의심되는 블록 식별 결정은 이 임계값을 기반으로 (직접적으로 또는 암시적으로) 내려질 수 있다: 특정 블록이 가장 최근의 k 개 에러 사건들 중 에러의 비율보다 더 많이 발생하는 경우, 해당 블록은 의심으로 표시될 수 있다. 예를 들어 총 256,000 개의 블록들을 포함하는 장치에서 총 100 개의 에러들이 발생했다고 가정한다. 에러들의 개수와 블록들의 개수의 비율은 100/256,000 = 1/2,560이다. 블록이 이 수 이상의 에러들이 발생하면, 해당 블록이 의심으로 표시될 수 있다.
에러들의 개수가 블록들의 개수에 대략 비례할 때까지, 단일 에러라도 블록이 의심으로 표시될 수 있음을 유의한다. 모든 에러로 인해 블록이 의심으로 표시되는 것을 방지하기 위해, 평균 기반 임계값은 원하는 요인으로 확장(또는 축소)될 수 있다. 이에 따라, 예를 들어, 평균 기반 임계값은 숫자(예를 들어, 10,000)를 곱하여 효과적으로 1보다 큰 임계값을 생성할 수 있다. 이 스케일링(scaling) 값은 평균 기반 임계값이 너무 커지는 것을 방지하기 위해, 시간이 지남에 따라 또는 에러들의 개수에 따라 달라질 수 있다.
예측
의심 블록이 식별되면, 의심 블록에 대응하는 파라미터들의 세트가 생성되고(세트 S), 고장 예측 모듈에 공급될 수 있다. 상술한 바와 같이 S의 일부는 블록-레벨 에러 정보를 기반으로 할 수 있으며, S의 일부는 과거 k 개의 에러들에 대해 저장된 드라이브 레벨 메타 데이터에서 추출될 수 있는 드라이브 레벨 로그 정보에서 유도될 수 있다(블록-레벨 데이터를 추정하기 위해 모든 블록들의 평균을 반영할 수 있음). 그 다음, 어떤 알고리즘은 데이터를 처리하고 블록이 실제로 고장 날 것으로 예측되는지 여부를 결정하는데 사용 수 있다. 사용될 수 있는 알고리즘의 예는 로지스틱 회귀(Logistic Regression) 또는 랜덤 포레스트(Random Forest) 알고리즘을 포함한다. 예측된 결과가 블록이 향후 고장 날 가능성이 있음을 나타내면, 먼저 유효한 데이터를 다른 블록들에 복사한 다음 사용 가능한 블록 리스트에서 의심 블록을 제거하여, 블록은 폐기될 수 있다. 예측 모듈에 필요한 프로세싱 파워를 최소화하기 위해, 예측 모듈은 모든 블록들에 대해 실행되지 않거나 지속적으로 실행되지 않을 수 있다. 대신, 예측 모듈은 의심 블록에 대해 트리거(trigger)될 수 있으며 해당 블록이 의심 블록으로 식별될 때 트리거될 수 있다.
상술한 바와 같이, 이벤트를 예측하기 위해 일부 시계열 데이터를 사용하는 임의의 원하는 예측 모듈이 선택될 수 있다. 예측 모듈의 예는 주로 학습된 머신 러닝-기반의 고장 예측 모델(예를 들어, 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 등)이고, 예측을 위한 정보(예를 들어, 최적화된 가중치)는 드라이브 펌웨어에 이미 내장되어 있다. 이에 따라, 과거 에러 정보를 수신하면, 모델은 경량 계산을 실행하여 특정 블록의 고장 확률을 예측할 수 있다.
QLC 드라이브 블록-레벨 장애 예측
상기 설명은 SSD가 하나의 NAND 기술만을 사용하는 것으로 가정한다. 그러나 QLC 드라이브에서, SLC NAND 플래시는 신뢰성(endurance) 및 성능 목적으로도 사용될 수 있다. 따라서 블록-레벨 파라미터들을 추출하는 위의 접근 방식은 다음과 같은 이유들로 적용되지 않을 수 있다. (1) 서로 다른 NAND 플래시 기술들은 서로 다른 신뢰성 및 에러 특성을 가질 수 있다. 예를 들어, QLC 에러율은 SLC보다 높을 수 있다. (2) 다른 NAND 플래시 기술들은 에러 정정 메커니즘이 다를 수 있다. (3) SSD 내의 다른 NAND 플래시 기술들은 다른 목적들로 사용될 수 있다. 예를 들어, SLC NAND는 QLC에 대한 쓰기 양을 줄이고 성능을 향상시키기 위해 QLC 드라이브의 캐시 계층으로 사용될 수 있다. 따라서 이 두 기술들이 제출되지 않은 워크로드들은 다를 수 있으며, 다른 형태들의 NAND 플래시에 대한 액세스들(예를 들어, 읽기들 및 쓰기들의 회수)은 균일하지 않을 수 있다. (4) SSD 내의 다른 NAND 플래시 기술들에 대한 액세스 패턴들은 다를 수 있으며(랜덤(random) 대 순차(sequential)) 다른 마모도(wear-out)를 초래할 수 있다. 따라서 그것들은 다른 노화 패턴들(aging pattern)과 용도를 갖는다.
위의 이유들은 단일 유형의 NAND 플래시만을 사용하는 SSD에서 블록-레벨 장애 예측에 대해 설명된 접근 방식을 혼란시킬 수 있다. (i) 에러 이력: 이유 (1) 및 (2)로 인해, 하나의 이력 리스트만 최근 에러들에 대해 유지되는 경우, 하나의 NAND 플래시 유형(예를 들어, QLC)이 시간이 지남에 따라 더 많은 에러를 발생시킬 수 있으므로, 항상 임계값에 도달하여 다른 NAND 플래시 유형(예를 들어, SLC)에 대한 고갈(starvation) 유발할 수 있다. (이 맥락에서 "고갈"은, QLC와 같은 다른 플래시 미디어 유형이 모든 리소스들, 처리들, 또는 기타 이점들을 취하기 때문에, SLC와 같은 하나의 NAND 플래시 유형이 리소스들, 처리 또는 기타 이점들이 거부될 수 있음을 의미한다.) 다시 말해서, 일정한 리스트 길이와 임계값이 주어지면, 하나의 NAND 플래시 유형이 결함 사건들에 두드러지고(또는 압도적으로 우세하고)(dominate) 다른 NAND 플래시 유형을 무시할 수 있다. 따라서 하나의 NAND 플래시 유형이 에러들에 두드러지지 않도록 하는 메커니즘은 결함 있는 블록들을 식별하는 데 서로 다른 NAND 플래시 유형들의 에러들에 미치는 영향을 격리(또는 고립)할 수 있도록 사용될 수 있다. (ii) 정확한 블록 파라미터들: 서로 다른 NAND 플래시 유형들은 서로 다른 에러 파라미터들을 가지며, NAND 플래시 유형에 따라 적절한 정확한 블록 파라미터들을 유지할 가치가 있을 수 있다. (iii) 근사 파라미터들(드라이브 수준 파라미터들로부터 유도됨): 이유 (3) 및 (4)로 인해 SLC 플래시와 QLC 플래시는 서로 다른 노화 요인들뿐만 아니라 읽기들/쓰기들의 횟수가 다를 수 있다. 따라서 근사 블록-레벨 파라미터들을 유도할 때, 드라이브에서 총 블록들의 개수에서 해당 파라미터들을 평균화하면 정확한 분석이 제공되지 않을 수 있다. 더욱이, 근사 블록-레벨 파라미터들에 대한 검토는 노화 및 워크로드에 비례할 수 있다. (iv) 머신 러닝(또는 기계 학습) 예측 모델: 모델은 NAND 플래시 유형을 고려할 수 있다. 따라서, 다른 모델들은 NAND 플래시 유형별로 학습되거나, 학습 및 예측 시 NAND 플래시 유형은 모델에 제공될 수 있다.
별도의 드라이브 레벨 파라미터들
SSD가 여러 유형들의 NAND 플래시를 포함하는 상황에 대한 한 가지 접근 방식은 각 NAND 플래시 유형에 대해 별도의 드라이브 레벨 파라미터들(예를 들어, FPGA(Field Programmable Gate Array), ASIC(Application-Specific Integrated Circuit), CPU(Central Processing Unit) 등으로 구현될 수 있는 빌트-인(built-in) 프로세서를 사용하여 일부 기능 또는 기능들을 수행하는 SSD 또는 기타 스토리지 장치에 의해 생성될 수 있는 로그 데이터)유지하는 것일 수 있다. 예를 들어, QLC 및 SLC NAND 플래시를 모두 포함하는 SSD는 QLC 및 SLC 구성 요소들 대해 각각 하나씩 두 세트의 SMART 로그들이 유지될 수 있다.
결함 있는 블록 식별 및 검증을 지원하기 위해, 정확한 파라미터들은 저장될 수 있다. 이러한 정확한 파라미터들은 에러들/결함들과 관련된 중요한 파라미터들을 포함할 수 있다. 따라서 NAND 플래시 유형을 기반으로, 적절한 에러 파라미터들이 유지될 수 있다.
근사 파라미터는 두 가지 카테고리들로 분할될 수 있다: (i) 드라이브 레벨, 및 (ii) NAND 레벨
드라이브 레벨 파라미터들은 드라이브와 관련된 파라미터들을 포함할 수 있으며, NAND 플래시 유형에 따라 변하지 않을 수 있다. 예를 들어, "커패시터 헬스(health)", "DRAM 에러들" 및 "드라이브 온도"와 같은 일부 파라미터들은 특정 NAND 플래시 유형과 관련되지 않고 드라이브 자체와 관련될 수 있다. 이러한 파라미터들은 직접 사용될 수 있다.
NAND 기반 파라미터들은 각각의 NAND 플래시 유형에 대해 SSD에서 유지되는 NAND 레벨 로그 데이터 세트(예를 들어, SMART 로그)를 포함할 수 있다. 따라서, 예를 들어, QLC 및 SLC NAND 플래시를 모두 포함하는 SSD는 QLC NAND 플래시의 로그 정보(예를 들어, 읽기들, 쓰기들의 회수 등)를 추적하는 QLC 로그, 및 SLC NAND 플래시의 로그 정보(예를 들어, 읽기들, 쓰기들의 회수 등)를 추적하기 위한 SLC 로그를 포함할 수 있다.
블록-레벨 근사 파라미터들을 추출하기 위해, 이들 파라미터들은 모든 블록들에 걸쳐 평균화될 수 있고 단일 블록을 대표할 수 있다. 예를 들어, 드라이브에 대한 읽기들 및 쓰기들의 총 회수를 기반으로 하고, 드라이브 수명을 나타내는, "읽기들의 회수" 및 "쓰기들의 회수"와 같은 일부 파라미터들은 의심되는 블록에 대한 대응하는 파라미터들을 근사화하기 위해 모든 블록들에 걸쳐 평균화될 수 있다.
통합 드라이브 레벨 파라미터들
SSD가 여러 유형들의 NAND를 포함하는 상황에 대한 두 번째 접근 방식은 드라이브의 모든 NAND 플래시 유형에 대한 통합 드라이브 레벨 파라미터들(예를 들어, SMART 로그)를 유지하는 것일 수 있다. 예를 들어, 이 모델에 대한 SMART 로그에서 읽기들의 회수는 SLC 및 QLC 모두에 대한 읽기들의 총 회수를 참조할 수 있다.
결함 있는 블록 식별 및 검증을 지원하기 위해, 정확한 파라미터들은 저장될 수 있다. 이러한 정확한 파라미터들은 에러들/결함들과 관련된 중요한 파라미터들을 포함할 수 있다. 따라서 NAND 플래시 유형을 기반으로, 적절한 에러 파라미터들은 유지될 수 있다.
근사 파라미터는 두 가지 카테고리들로 분할될 수 있다: (i) 드라이브 레벨, 및 (ii) NAND 레벨
드라이브 레벨 파라미터들은 드라이브와 관련된 파라미터들을 포함할 수 있으며, NAND 플래시 유형에 따라 변하지 않을 수 있다. 예를 들어, "커패시터 헬스(health)", "DRAM 에러들" 및 "드라이브 온도"와 같은 일부 파라미터들은 특정 NAND 플래시 유형과 관련되지 않고 드라이브 자체와 관련될 수 있다. 이러한 파라미터들은 직접 사용될 수 있다.
NAND 기반 파라미터들은 특정 NAND 플래시 유형과 관련되고 주로 그것들의 사용 및 노화와 관련된 파라미터들을 포함할 수 있다. 예를 들어 읽기들/쓰기들 및 소거들의 회수는 QLC 및 SLC NAND 플래시에 대해 다를 수 있다. 이러한 파라미터들을 추출하기 위해, 각 NAND 플래시 유형의 용량과 블록들의 개수 및 각 NAND 플래시 유형에 대한 읽기들 및 쓰기들의 회수를 고려하여 비례량들은 도출될 수 있다.
따라서, 이들 파라미터들은 각각의 NAND 유형에 대한 읽기들 및 쓰기들의 회수에 따라 지시될 수 있다. 예를 들어, QLC_RD/WR 및 SLC_RD/WR이 각각 QLC 및 SLC 구성 요소들에 대한 읽기들 및 쓰기들의 회수를 참조한다고 가정한다. 각 파라미터는 이러한 파라미터들에 상응(commensurate)할 수 있다. 드라이브 레벨 파라미터 "X"를 나타내는 주어진 값 DRIVE_X 및 α 및 β 값 (파라미터에 의존할 수 있음)에 대해, QLC 및 SLC에 대한 상대 값들은 아래 식들을 사용하여 계산될 수 있다.
위의 방정식 뒤에 있는 직관(intuition)은 이러한 구성 요소들에 대한 읽기들 및 쓰기들의 회수가 드라이브의 수명 및 사용을 나타내는 것이다. 따라서 각 QLC/SLC 블록에 대한 파라미터들은 비례적으로 그리고 대략적으로 계산될 수 있다. 상수 α 및 β는 해당 파라미터와 읽기 및/또는 쓰기 동작들의 관계를 나타낼 수 있다. 예를 들어, 블록에 대한 소거들의 회수를 계산하기 위해, 소거 동작들은 쓰기 동작들과 직접 관련되기 때문에 α를 1로 설정하고 β를 0으로 설정할 수 있다. 한편, "컨트롤러 비지(busy) 시간" 파라미터를 계산하기 위해, 이 파라미터는 읽기 및 쓰기 동작들 모두와 관련이 있기 때문에, α는 0.5로 설정될 수 있고 β는 0.5로 설정될 수 있다. 일반적으로 α와 β는 0에서 1(포함)(즉, 0이상이고, 1이하) 범위의 값들로 설정될 수 있으며, α + β = 1 이다.
읽기들 및 쓰기들의 회수는 SSD에 의해 추적 될 수 있는 QLC/SLC_RD/WR 카운터들로부터 직접 획득될 수 있음을 유의한다.
고갈 문제
QLC NAND 플래시는 에러들이 발생할 가능성이 더 높기 때문에, QLC 및 SLC 의심 블록들을 식별하는 데 동일한 임계값이 사용되는 경우(정적 또는 동적 임계값이 사용되는지 여부에 관계없이), SLC NAND 플래시 블록들이 선택되지 않을 수 있는 상황이 있을 수 있다. 이러한 상황을 피하기 위해, SLC 및 QLC NAND 플래시 구성 요소들의 용량에 따라, 테이블 공간은 두 부분으로 분할될 수 있다. 예를 들어, 엔트리들의 총 개수가 "k"이고 QLC 용량이 SLC 용량의 20 배인 경우, k*20/21 엔트리들은 QLC에 할당되고, k/21 엔트리들은 SLC에 할당될 수 있다. 그 다음, 위에서 논의되었지만 테이블의 각 부분에 개별적으로 적용되는 임계값 기반 메커니즘은 SLC 및 QLC NAND 플래시에 대한 의심되는 블록을 식별하도록 사용될 수 있다.
예측
의심되는 블록이 식별되면, 그 블록과 관련된 엔트리들 세트는 추출되고, 고장 예측 모듈에 공급될 수 있다.
예측 결과가 미래의 고장을 나타내는 경우, 먼저 유효한 내용들을 다른 블록들에 복사한 다음 가용 블록 리스트에서 제거함으로써, 그 블록은 폐기될 수 있다. 예측 모듈은 의심되는 블록이 곧 고장 날 것으로 예상되는지 여부를 결정하기 위해 이 입력을 처리할 수 있다. 또한, 예측 모듈에 필요한 프로세싱 파워(processing power)를 해결하기 위해, 예측 모듈은 의심되는 블록에 대해서만 실행될 수 있으며, 이는 예측 모듈이 모든 블록에 대해 지속적으로 실행되는 것을 방지할 수 있다.
참고로, QLC 및 SLC 에러 특성이 다르기 때문에, 하나의 모델이 두 가지 유형들의 NAND 플래시를 모두 다루도록 훈련될 수 있지만, 모델은 NAND 플래시 유형(SLC 또는 QLC)도 파라미터로써 제공될 수 있다. 이후, 예측 모듈은 NAND 플래시 유형을 기반으로 적절한 예측 모델을 만들 수 있다. 또는 SLC 용과 QLC 용으로 하나씩 두 가지 다른 모델들은 학습될 수 있다.
이벤트를 예측하기 위해, 일부 시계열 데이터를 사용할 수 있는 일반 예측 모듈은 사용될 수 있다. 예측 모듈의 예는 주로 학습된 머신 러닝-기반 고장 예측 모델(예를 들어, 랜덤 포레스트(Random Forest), 로지스트 회귀(Logistic Regression), 이상점 검출(Outliner Detection) 등)일 수 있으며, 예측을 위한 정보(예를 들어, 최적화된 가중치)는 이미 드라이브 펌웨어에 내장될 수 있다. 따라서 과거 에러들 정보를 수신하면, 모델은 경량 계산을 실행하여 특정 블록에 대한 고장의 확률을 예측할 수 있다.
또는, 현재 의심되는 블록의 NAND 플래시 유형에 기초하여 적절한 모델이 선택된 상태에서, 다른 모델들은 다른 NAND 플래시 유형들에 대해 학습 또는 훈련(train)될 수 있다.
마지막으로, 위의 분석은 두 가지 NAND 플래시 유형(특히 QLC 및 SLC)을 갖는 SSD에 초점을 맞추고 있지만, 본 개시의 실시 예들은 특정 NAND 플래시 유형을 참조하지 않고, 임의의 수의 NAND 플래시 유형을 사용하는 SSD들로 확장되고, 다른 불휘발성 스토리지 기술들(예를 들어, NOR flash)로 확장될 수 있다.
도 1은 본 개시의 일 실시 예에 따른 세분화된 블록 장애 예측을 수행할 수 있는 SSD(Solid State Drive)를 포함하는 시스템을 나타낸다. 도 1에서, 머신(machine)은 프로세서(105), 메모리(110) 및 솔리드 스테이트 드라이브(SSD; Solid State Drive)(115)를 포함할 수 있다. 프로세서(105)는 임의의 다양한 프로세서일 수 있다. (후술되는 다른 구성 요소들과 함께 프로세서(105)는 설명의 편의를 위해 머신 외부에 도시되어 있다: 본 개시의 실시 예들은 머신 내에 이러한 구성 요소들을 포함할 수 있다.) 도 1은 단일 프로세서(105)를 도시하고, 머신(120)은 각각이 단일 코어 또는 다중 코어 프로세서들일 수 있는, 임의의 수의 프로세서들을 포함할 수 있으며, 이들 각각은 (다른 가능성들 중에서) RISC(Reduced Instruction Set Computer) 아키텍처 또는 CISC(Complex Instruction Set Computer)를 구현할 수 있으며, 원하는 조합으로 혼합될 수 있다.
프로세서(105)는 메모리(110)에 연결될 수 있다. 메모리(110)는 플래시 메모리, DRAM(Dynamic Random Access Memory), SRAM(Static Random Access Memory), PRAM(Persistent Random Access Memory), FRAM(Ferroelectric Random Access Memory), 또는 NVRAM(Non-Volatile Random Access Memory), MRAM(Magnetoresistive Random Access)와 같은 다양한 메모리일 수 있다. 메모리(110)는 또한 상이한 메모리 유형들의 임의의 원하는 조합일 수 있고, 메모리 컨트롤러(125)에 의해 관리될 수 있다. 메모리(110)는 ‘단기’로 지칭될 수 있는 데이터(즉, 연장된 기간 동안 저장될 것으로 예상되지 않는 데이터)를 저장하는데 사용될 수 있다. 단기 데이터의 예는 임시 파일들, 애플리케이션들에 의해 로컬로 사용되는 데이터(다른 스토리지 위치들에서 복사되었을 수 있음) 등을 포함할 수 있다.
프로세서(105) 및 메모리(110)는 또한 다양한 애플리케이션들이 실행될 수 있는 운영 체제(OS; operating system)를 지원할 수 있다. 이들 애플리케이션들은 메모리(110) 또는 SSD(115)로부터 데이터를 읽거나 데이터를 쓰기 위한 요청들을 발행할 수 있다. 예를 들어, SSD(115)는 시뮬레이션을 초기화하기 위해 사용되는 초기 파라미터들(또는 초기 파라미터들에 대한 값들의 범위, 값의 범위가 나타내는 행동들의 유형들과 함께)을 저장하는 데 사용될 수 있다. SSD(115)는 장치 드라이버(130)를 사용하여 액세스될 수 있다. 도 1은 SSD(115)를 도시하고, 본 개시의 실시 예들은 세분화된 블록 고장 예측으로부터 이익을 얻을 수 있는 다른 스토리지 장치 포맷(format)들을 포함할 수 있다: 아래의 ‘SSD’에 대한 임의의 참조는 본 개시의 그러한 다른 실시 예들을 포함하는 것으로 이해되어야 한다.
도 2는 도 1의 머신의 세부 사항들을 도시한다. 도 2에서, 전형적으로, 머신(120)은 머신의 구성 요소들의 동작을 조정하는데 사용될 수 있는, 메모리 컨트롤러(125) 및 클록(205)을 포함할 수 있는, 하나 이상의 프로세서들(105)을 포함한다. 프로세서(105)는 예들로서 RAM(random access memory), ROM(read-only memory), 또는 다른 상태 보존 미디어를 포함할 수 있는 메모리(110)에 또한 연결될 수 있다. 프로세서(105)는 또한 스토리지 장치(115), 및 예를 들어 이더넷 커넥터 또는 무선 커넥터일 수 있는 네트워크 커넥터(210)에 연결될 수 있다. 프로세서(105)는 다른 구성 요소들 중에서 사용자 인터페이스(220), 및 입력/출력 엔진들(225)을 사용하여 관리될 수 있는 입력/출력 인터페이스 포트들이 부착될 수 있는 버스들(215)에 또한 연결될 수 있다.
도 3은 도 1의 SSD의 세부 사항들을 나타낸다. 도 3에서, SSD(115)는 SSD(115)와 호스트 컴퓨터(도 1의 머신(120)과 같은) 사이의 인터페이스를 제공할 수 있는 호스트 인터페이스 로직(305)을 포함할 수 있다. SSD(115)는 또한 SSD 컨트롤러(310), 다양한 채널들(315-1, 315-2, 315-3 및 315-4)을 포함할 수 있으며, 이를 따라 다양한 플래시 메모리 칩들(320-1, 320-2, 320-3, 320-4, 320-5, 320-6, 320-7, 320-8)이 배열될 수 있다. 비록 도 3은 4 개의 채널들 및 8 개의 플래시 메모리 칩들을 도시하지만, 통상의 기술자는 임의의 수의 플래시 메모리 칩들을 포함하는 임의의 수의 채널들이 있을 수 있음을 인식할 것이다.
각 플래시 메모리 칩 내에서, 공간은 블록들로 구성될 수 있으며, 이는 페이지들로 더 세분될 수 있다. 예를 들어, 플래시 메모리 칩(320-7)은 제 1 내지 제 n 블록들(블록들(325, 330)로 식별됨)을 포함하는 것으로 도시되며, 이들 각각은 제 1 내지 제 m 페이지들을 포함할 수 있다. 다수의 블록들에 동일한 번호(예를 들어, 제 1 페이지)가 할당된 다수의 페이지들이 있을 수 있지만, 페이지 식별자(ID)와 블록 ID의 조합은 플래시 메모리 칩(320-7) 내의 특정 페이지를 고유하게 식별할 수 있다. (또는 페이지 ID, 블록 ID 및 플래시 메모리 칩 ID의 조합은 SSD(115) 내의 페이지를 고유하게 식별할 수 있다.)
블록들 및 페이지들 사이를 구별하는 이유는 SSD가 읽기, 쓰기, 및 소거 동작들을 처리하는 방법에 기인한다. 페이지는 일반적으로 SSD에서 읽거나 쓸 수 있는 가장 작은 데이터 단위이다. 페이지 크기는 원하는 대로 다를 수 있다. 예를 들어, 페이지는 4KB의 데이터일 수 있다. 전체 페이지보다 적게 쓰여질 경우, 초과 공간은 "사용되지 않음"이다.
그러나 페이지들은 쓰여지고(또는 기록되고), 읽힐(또는 판독될) 수 있는 동안, SSD는 일반적으로 데이터를 덮어 쓰기(overwrite)를 허용하지 않는다. 즉, 기존 데이터가 ‘제자리에서(in-place)’ 새로운 데이터로 교체되지 않을 수 있다. 대신 데이터가 업데이트될 때, 새 데이터는 SSD의 새로운 페이지에 쓰여지고, 원본 페이지가 무효화된다(수거를 위한 준비로 표시됨). 따라서 SSD 페이지들은 일반적으로 세가지 상태들 중 하나를 갖는다: 프리(free)(쓰기 준비), 유효(valid)(유효한 데이터 포함) 및 유효하지 않음(invalid)(유효한 데이터를 더 이상 포함하지 않지만 소거할 때까지 사용할 수 없음)(이러한 상태들의 정확한 이름들은 다를 수 있음.)
그러나 개별적으로 페이지들에 쓰여지거나 페이지들이 읽힐 수 있지만, 블록은 소거될 수 있는 데이터의 기본 단위이다. 즉, 페이지들은 개별적으로 소거되지 않는다: 블록 내 모든 256 페이지들은 일반적으로 동시에 소거된다. 예를 들어, 블록이 256 페이지들을 포함할 때, 블록의 전체 256 페이지들은 동시에 소거된다. 이러한 배열은 SSD에 대한 몇몇 관리 문제들을 초래할 수 있다: 여전히 일부 유효한 데이터를 포함하고 있는 블록이 소거를 위해 선택되면, 해당 유효한 데이터는 블록이 소거되기 전에 SSD의 프리 페이지에 복사될 필요가 있다(본 개시의 일부 실시 예들에서, 소거의 단위는 블록과 다를 수 있음: 예를 들어, 다수의 블록들의 세트인 슈퍼블록일 수 있음)
SSD 컨트롤러(310)는 플래시 변환 계층(335), 메타데이터 스토리지(340), 식별 펌웨어(identification firmware)(345) 및 검증 펌웨어(verification firmware)(350)를 포함할 수 있다. 플래시 변환 계층(335)은 데이터가 플래시 칩들 (320-1~320-8)에 저장되는 논리적 블록 주소들(도 1의 프로세서(105)에 의해 사용됨) 및 물리적 블록 주소들의 변환을 처리할 수 있다. 메타데이터 스토리지(340)는 세분화된(fine-grained) 블록 고장 예측을 수행할 때 SSD(115)에 의해 사용되는 메타데이터 정보를 저장할 수 있다. 식별 펌웨어(345)는 메타데이터 스토리지(340)에 저장된 메타데이터 정보를 사용하여, 고장 날 것으로 의심되는 블록을 식별하는 데 사용될 수 있다: 그 다음, 검증 펌웨어(350)는 메타데이터 스토리지(340)에 저장된 메타데이터 정보를 다시 사용하여, 의심 블록이 실제로 고장 날 가능성이 있는지 여부를 결정할 수 있다. 식별 펌웨어(345) 및 검증 펌웨어(350)는 ROM(read-only memory) 또는 그것의 일부 변형(예를 들어, PROM(Programmable ROM), EPROM(Erasable PROM), EEPROM(Electrically Erasable PROM), 플래시 메모리 등을 포함)에 저장될 수 있으며, SSD(115)의 일부일 수 있는 프로세서(도 3에 도시되지 않음)를 사용하여 실행될 수 있다: 예를 들어, SSD 컨트롤러(310)에 고유한 처리 능력을 사용함. 식별 펌웨어(345) 및 검증 펌웨어(350)는 또한 설명된 기능을 구현하도록 설계된 회로들 또는 회로를 사용하여 실행될 수 있다: 이러한 회로 또는 회로들은 FPGA(Field Programmable Gate Array), ASIC(Application-Specific Integrated Circuit), CPU(central processing unit) 또는 유사한 구조들을 사용하여 구현될 수 있다.
도 4는 도 1의 SSD(115)에 의해 사용되는 블록-기반 데이터의 예를 도시한다. 도 4에서, 블록-기반 데이터(405)는 각 블록에 대한 데이터를 포함할 수 있고, 이는 도 3의 메타데이터 스토리지(340)에 저장될 수 있다. 예를 들어, 임의의 수의 블록들에 대한 데이터가 포함될 수 있음에도 불구하고(도 1의 SSD(115)의 각 블록에 대한 데이터까지), 도 4는 제1 내지 제n 블록들에 대한 데이터를 도시한다. 각 블록에 대한 데이터는 카운터들(410-1, 410-2, 및 410-3)을 포함할 수 있고, 이는 대응하는 블록들에 대해 발생한 읽기 에러들 개수, 쓰기 에러들의 개수 및 소거 에러들의 개수를 저장할 수 있다. 카운터들(410-1, 410-2, 및 410-3)은 도 1의 SSD(115)가 제조된 이후 누적될 수 있음을 유의한다: 블록-기반 데이터(405)는 정확한 블록-기반 데이터라고도 또한 불릴 수 있다. 블록-기반 데이터(405)는 도 5를 참조하여 아래에서 논의되는, 다른 데이터와 비교해서 정확할 수 있다.
카운터들(410-1, 410-2, 및 410-3)의 각각은 카운터당 4바이트들을 요구할 수 있다. 각 카운터들(410-1, 410-2, 및 410-3)이 3개의 카운터들(읽기 에러들, 쓰기 에러들 및 소거 에러들의 개수에 대해 각각 하나씩)을 포함하기 때문에 카운터들(410-1, 410-2, 및 410-3) 각각을 저장하는 데 총 12바이트들이 사용될 수 있다. 12바이트들에 도 1의 SSD의 블록들의 개수를 곱함으로써, 블록-기반 데이터(405)에 의해 부과되는 오버헤드는 계산될 수 있다.
예를 들어, 총 1TB의 스토리지를 제공하는 SSD를 고려하고, 여기서 각 블록은 256페이지들을 포함하고 각 페이지는 4KB의 데이터를 포함한다. 4KB 페이지들에 1TB의 데이터를 저장하기 위해서 268,435,456페이지들이 필요하다. 블록 당 256페이지들을 포함하는 것은, SSD가 총 1,048,576개의 블록들을 포함하는 것을 의미한다. 블록 당 3개의 카운터들에 대해 12바이트들에서, 블록-기반 데이터(405)는 총 대략 12MB의 스토리지를 요구하며, 이는 SSD에 의해 제공되는 전체 스토리지의 1/1000 퍼센트(백분율)에 지나지 않는다.
카운터들(410-1, 410-2, 및 410-3)은 각 ‘블록’에서 발생된 에러들의 개수를 나타낸다. 이러한 에러들은 블록의 페이지들 중 하나 또는 몇 개 내에 밀집될 수 있고, 또는 에러들은 블록의 페이지들 중에 흩어질 수 있다. 이와 같이, 하나의 에러가 있는 페이지는, 근처의 다른 페이지들과 같이(다른 블록들에 있는 페이지들과 비교했을 때), 다른 에러들도 가질 가능성이 높기 때문에, 블록-기반 데이터(405)는 에러들 중 몇 공간적 지역성을 결정하기 위해서 제공한다.
도 5는 도 1의 SSD(115)에 의해 사용될 수 있는 장치-기반 로그 데이터를 도시한다. 도 5에서, 장치-기반 로그 데이터(505)(또는 드라이브-기반 로그 데이터)가 도시된다. 장치-기반 로그 데이터(505)는 도 1의 SSD(115)에서 발생한 특정 에러들에 대한 데이터를 포함할 수 있고, 도 3의 메타데이터 스토리지(340)에 저장될 수 있다. 그러나 도 1의 SSD(115)에서 발생한 모든 에러들에 대한 데이터를 저장하기 보다는, 장치-기반 로그 데이터(505)는 도 1의 SSD(115)에서 발생한 가장 최근의 k개의 에러들에 대한 데이터를 저장할 수 있다(오래된 에러들은 이전에 폐기될 수 있음). k는 임의의 원하는 값일 수 있다: 더 큰 값들은 특정 블록이 고장 날 것으로 예측되는지 여부를 결정하는 데 사용될 수 있는 더 많은 정보를 제공하지만, 더 많은 데이터를 저장해야 하는 비용을 부담한다(따라서 오버 헤드가 증가함).
다양한 데이터는 현재 추적중인 각 에러에 대해 저장될 수 있다. 예를 들어, 에러들(510-1, 510-2, 및 510-3)에서 도시된 바와 같이, 페이지 및 블록에 대한 ID들은 에러가 발생한 시간, 블록에 대한 에러 카운터들(즉, 에러가 발생하는 시점에, 에러가 발생한 블록에 대한 도 4의 정확한 블록-기반 데이터(405)의 값들), 에러가 발생한 때의 타임스탬프, 및 SMART 로그 데이터(515-1)(에러 510-1에 대해 표시됨)에서 보여진 것과 같은 다른 로그 데이터와 함께 저장될 수 있다. 장치-기반 로그 데이터(505)에 대한 도 5에서 도시된 데이터는 본 개시의 일 실시 예를 나타낸다: 다른 실시 예들은 더 많거나, 더 적거나, 또는 도 5에서 도시된 데이터와 다른 데이터를, 제한 없이, 포함할 수 있다.
도 4의 정확한 블록-기반 데이터(405)와는 대조적으로, 장치-기반 로그 데이터(505)는 근사 블록-기반 데이터를 유도하기 위해 사용될 수 있다. 장치-기반 로그 데이터(505)는 도 1의 SSD(115)의 가장 최근의 k 개의 에러들에 대한 정보만을 저장하기 때문에, 장치-기반 로그 데이터(505)(그리고 따라서 이로부터 유도된 근사 블록-기반 데이터)는 에러들 중의 일부 시간적 지역성을 결정하는 것을 제공하며, 다른 블록들 보다 더 최근 에러들을 경험한 블록들을 식별하는 것을 허용한다. 이러한 가장 최근의 k 개의 에러들은 에러 이력 테이블(결함-이력 테이블이라고도 함)에 저장될 수 있다.
가장 최근의 k 개의 에러들에 대한 데이터만이 저장되기 때문에, 장치-기반 로그 데이터(505)를 저장하는데 요구되는 오버헤드는 하나의 에러에 대해 저장된 데이터의 크기를 알고 해당 데이터가 저장된 에러들의 개수를 곱하여 계산될 수 있다. 예를 들어, 데이터는 가장 최근의 100개의 에러들에 대해 저장되고, 각 에러에 대한 스토리지가 1KB 인 경우, 장치-기반 로그 데이터를 저장하는 데 필요한 총 스토리지는 100KB이다. 다시, 도 1의 SSD(115)의 크기와 관련하여, 이 스토리지 오버헤드는 도 1의 SSD(115)의 전체 크기의 퍼센트 중 작은 부분이다(1TB SSD의 약 10만 분의 1).
K의 값은 미리 설정될 수 있다. 그 다음, k의 값은 도 1의 SSD(115)의 수명 동안 일정하게 유지될 수 있다. 또는 k는 설정(또는 변경) 가능할 수 있으며, 사용자 선호도에 따라 시간이 지남에 따라 변경할 수 있다. 예를 들어, 도 1의 SSD(115)가 노후 되어감에 따라 더 많은 에러 정보가 바람직할 수 있다.
도 6은 특정 블록이 고장 날 것으로 예상되는지 여부를 결정하도록 동작하는 도 3의 식별 펌웨어(345) 및 검증 펌웨어(350)를 나타낸다. 도 6에서, 식별 펌웨어(345)는 장치-기반 로그 데이터(505)(도 5의 SMART 로그 데이터(515-1) 뿐만 아니라 기타 에러들에 대한 다른 SMART 로그 데이터를 포함할 수 있으며, 이는 도 6에 상세히 도시되지 않음)를 수신할 수 있다. 그 다음, 식별 펌웨어(345)는 각각의 저장된 에러가 발생한 블록들을 식별할 수 있다. 가장 최근의 k 개 에러들 중, 특정 블록의 에러들의 개수가 어떤 임계값을 초과하면, 문제의 블록은 곧 고장 날 것으로 의심될 수 있다. 따라서, 식별 펌웨어(345)는 장치-기반 로그 데이터(505)로부터 근사 블록-기반 데이터(605)를 생성할 수 있다.
특정 블록이 곧 고장 날 것으로 의심되는지 여부를 결정하기 위해, 임의의 원하는 임계값이 사용될 수 있다. 예를 들어, 미리 결정된, 사용자-지정 임계값이 설정될 수 있고, 특정 블록에서 가장 최근의 k개 에러들에서 임계값보다 많은 수의 에러들이 발생하면, 해당 블록은 곧 고장 날 것으로 의심된다. 이 임계값은 숫자(예를 들어, 가장 최근의 k 개 에러들 중 10개 에러들)이거나 백분율(예를 들어, 가장 최근의 k 개 에러들 중 에러들의 10 %)일 수 있다. 이 임계값은 실제로 발생한 에러들의 개수를 기반으로 조정될 수도 있다. 예를 들어. 임계값이 총 에러들의 개수의 백분율로 설정되어 있으면, 첫 번째 에러가 발생한 블록은 자동으로 의심될 수 있는데, 에러들의 100%가 해당 블록과 연관되기 때문이다. 이러한 결과를 회피하기 위해, 식별 펌웨어(345)는 도 1의 SSD(115)에서 발생한 에러들의 개수가 어느 정도의 다른 값을 초과할 때까지 동작하지 않을 수 있다: 이것은 식별 펌웨어(345)가 너무 일찍 고장 날 것으로 의심되는 블록들을 식별하는 것을 방지한다.
사용될 수 있는 다른 임계값은 전체 SSD에 걸쳐 블록 당 에러들 수의 평균을 계산하는 것이다. 즉, (SSD가 제조된 이후) 발생한 총 에러들의 개수는 계산될 수 있고, SSD의 총 블록들의 개수로 나뉠 수 있다. 이 평균과 관련하여 너무 많은 에러들이 발생한 임의의 블록은 곧 고장 날 것으로 의심될 수 있다. 이 평균의 백분율도 또한 사용될 수 있다. 다시, 이 평균(또는 평균의 사용)은 조정될 수 있다. 예를 들어, SSD에 의해 발생한 에러들의 개수가 SSD의 블록들의 개수에 가까워질 때까지, 단일 에러가 발생한 임의의 블록은 에러들의 평균 수보다 많을 것이고, 식별 펌웨어(345)에 의해 자동으로 의심스러운 것으로 간주된다. 따라서, 식별 펌웨어(345)는 에러들의 개수가 미리 결정된 값을 초과할 때까지 블록들이 곧 고장 날것으로 의심되는지 여부를 고려하는 것을 시작하지 않을 수 있다. 또는, 식별 펌웨어(345)는 (k에 관하여) 특정 블록에서 발생하는 에러들의 상대적인 백분율을 계산하고 그 값을 SSD 전체의 블록 당 평균 에러들의 개수와 비교할 수 있다: 블록이 평균보다 더 높은 백분율의 가장 최근의 k 개 에러들을 경험한다면, 식별 펌웨어(345)는 그 블록을 곧 고장 날 블록으로 의심할 수 있다.
본 개시의 다른 실시 예들에서, 식별 펌웨어(345)는 블록이 최근에 에러들의 더 많은 몫을 경험했기 때문이 아니라, 총(또는 전체) 에러 카운트를 기반으로 블록이 고장 날 것으로 의심할 수 있다. 예를 들어, k가 100으로 선택되었다고 가정한다(즉, 장치-기반 로그 데이터는 오직 가장 최근의 100개의 에러들만 저장됨). 특정 블록에서 50번째 에러가 매번 발생할 경우, 해당 블록이 가장 최근의 k 개의 에러들에서 더 높은 백분율의 에러들을 가진 것을 기반으로 의심스러운 것으로 필연적으로 고려되지 않을 수도 있다. 그러나 장치의 이력에서, 이 블록이 매 50개의 에러들 중 1개가 있다는 것은 이 블록이 다른 블록보다 훨씬 많은 에러들을 경험했다는 것을 의미할 수 있다. 따라서, 식별 펌웨어(345)는 곧 고장 날 것으로 의심되는 블록들을 찾기 위해 도 4의 정확한 블록-기반 데이터(405)를 조사할 수 있다. 블록이 근사 블록-기반 데이터(605)에 기초한 임계값을 초과하지 않더라도, 일부 임계값을 초과하는 총 에러 카운트를 갖는 블록은 의심으로 식별될 수 있다.
본 개시의 일부 실시 예들에서, 장치-기반 로그 데이터(505)에 관계 없이, 식별 펌웨어(345)는 도 4의 정확한 블록-기반 데이터(405)를 조사할 수 있다: 본 개시의 그러한 실시 예들에서 식별 펌웨어(345)는 도 1의 SSD(115)의 모든 블록의 총 에러 카운트를 조사할 수 있다. 본 개시의 다른 실시 예들에서, 식별 펌웨어(345)는 가장 최근의 k 개의 에러들 중 하나(또는 그 이상)를 경험한 블록들에 대해서만 도 4의 정확한 블록-기반 데이터(405)를 조사할 수 있다: 본 개시의 이러한 실시 예들에서 식별 펌웨어(345)는 장치-기반 로그 데이터(505)와 함께 도 4의 정확한 블록-기반 데이터(405)를 고려할 수 있다.
사용된 특정 접근 방식에 관계없이, 식별 펌웨어(345)는 특정 블록이 의심스러운 것으로 간주되는지를 결정하기 위해 두 개의 값들을 단순히 비교함으로써 동작할 수 있다. 이 프로세스는 의심 블록들의 식별을 간단하게 할 수 있다.
식별 펌웨어(345)는 임의의 원하는 스케줄에 따라 동작할 수 있다. 식별 펌웨어(345)는 일정한(또는 정기적인) 시간 간격으로 동작할 수 있다: 예를 들어, 1분마다, 10분마다, 또는 매일(더 작고 더 큰 간격들도 가능함). 또는, 식별 펌웨어(345)는 특정 개수의 에러들이 발생한 후에 작동할 수 있다: 예를 들어, 모든 에러 후, 또는 매 5번째 에러 이후(다른 에러들의 개수도 가능함).
식별 펌웨어(345)는 블록이 의심스러운지 여부를 결정하는 데 장치 기반-로그 데이터(505)를 사용하는 것으로 설명되었지만, 본 개시의 실시 예들은 장치-기반 로그 데이터(505) 대신에 또는 추가하여 도 4의 정확한 블록-기반 데이터(405)를 사용할 수 있다. 예를 들어, 식별 펌웨어(345)는 미리 결정된 임계값을 초과하는 도 4의 카운터들(410-1)의 합을 기반으로 블록을 의심으로 간단히 식별할 수 있다.
식별 펌웨어(345)가 곧 고장 날 것으로 의심되는 블록을 식별하면, 검증 펌웨어(350)가 호출될 수 있다. 검증 펌웨어(350)는 식별 펌웨어(345)에 의해 의심 블록으로 식별된 블록이 실제로 곧 고장 날 것으로 예측되는지 여부를 결정하기 위해, 도 4의 정확한 블록-기반 데이터(405)(구체적으로, 곧 고장 날 것으로 의심되는 블록에 적용되는 블록 카운터들(410-1)) 및 근사 블록-기반 데이터(605)를 사용할 수 있다. 검증 펌웨어(350)는 이러한 결정을 내리기 위해 임의의 원하는 접근법을 사용할 수 있다. 예를 들어, 검증 펌웨어(350)는, 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 등과 같은, 머신 러닝-기반 고장 예측 모델을 구현할 수 있고, 이 모델은 훈련을 받을 수 있고, 예측을 위한 정보(예를 들어, 최적화된 가중치들)가 검증 펌웨어(350)에 이미 내장되어 있다. 그 다음, 검증 펌웨어(350)는 식별 펌웨어(345)에 의해 곧 고장 날 것으로 의심되는 블록이 실제로 곧 고장 날 것으로 예측되는지 여부를 나타내는 결과(610)를 생성할 수 있다.
비록 도 6은 식별 펌웨어(345)를 장치-기반 로그 데이터(505)로부터 근사 블록-기반 데이터(605)를 생성하는 것으로 도시하지만, 본 개시의 실시 예들은 근사 블록-기반 데이터(605)를 생성하는 다른 구성 요소들을 가질 수 있다. 예를 들어, 검증 펌웨어(350)는 장치-기반 로그 데이터(505)를 선택하고 근사 블록-기반 데이터(605) 자체를 생성할 수 있다.
식별 펌웨어(345) 및 검증 펌웨어(350)는 상이한 기능들을 갖는다는 점에 유의한다. 식별 펌웨어(345)는 단지 곧 고장 날 것으로 의심되는 블록을 식별할 뿐이다. 식별 펌웨어(345)는 분리(또는 고립)되어 사용될 수 있다(즉, 곧 고장 날 것으로 의심되는 모든 블록은 단순히 곧 고장 날 것으로 가정될 수 있음). 그러나 이러한 접근 방식은 오랫동안 제대로 동작할 수 있는 많은 블록들이 동작에서 폐기되는 것을 야기한다. 식별 펌웨어(345)는 범죄를 저지른 용의자를 체포하는 경찰과 유사하다고 생각할 수 있다: 용의자가 체포되었다는 사실이 용의자가 유죄임을 자동으로 의미하지 않는다.
반면에, 검증 펌웨어(350)는 유죄 또는 무고한 판결을 반환하는 형사 재판과 유사한 것으로 생각될 수 있다. 검증 펌웨어(350)는 특정 블록이 실제로 사용에서 폐기되어야 하는지에 대한 최종 판단을 한다. 블록이 실제로 폐기될 준비가 되었는지 확인하기 위해 추가 단계를 수행하면 블록들이 조기에 폐기되는 것을 방지할 수 있다.
블록을 의심으로 식별하고 블록이 폐기 준비가 되었는지 검증하기 위해 어떤 계산들이 실제로 필요한지 주목할 필요가 있다. 블록을 의심으로 식별하는 것은 임계값과 관련하여 해당 블록에서 발생한 에러들의 개수의 간단한 비교를 통해 완료될 수 있다. 이 계산은 전형적으로 매우 빠르고 수행하기 간단하고, 블록이 곧 고장 날것으로 예측되고, 이에 따라 폐기 준비가 되었는지 확인하기 위해 블록을 분석하기 전에 복잡한 동작들을 요구하지 않는다.
검증 펌웨어(350)는 식별 펌웨어(345)보다 더 많은 연산(또는 계산)을 포함할 수 있다. 그러나 검증 펌웨어(350)는 블록이 의심으로 식별된 후에만 실행될 수 있다. 이 조건은 검증 펌웨어(350)가 많은 블록들에 대해 반복적으로 실행되는 것(이는 상술된 바와 같이 도 1의 SSD(115)의 이용 가능한 연산(computational) 리소스들을 초과함)을 방지할 수 있다. 블록이 폐기되어야 하는지 결정하기 위해 집중적인 연산들로 모든 블록을 지속적으로 확인하는 것보다, 개별 의심 블록들에 대해 필요에 따라 검증 펌웨어(350)를 호출하는 것이 훨씬 바람직하다. 따라서, 식별 펌웨어(345) 및 검증 펌웨어(350) 모두의 사용은 세분화된 블록 고장 예측을 구현하기 위한 연산 요구들을 부과하지 않고 세분화된 블록 고장 예측을 제공하는 목적들을 달성한다.
도 7a 및 도 7b는 본 개시의 일 실시 예에 따른 블록이 고장 날 것으로 예상되는지 여부를 결정하는 예시적인 절차를 나태나는 흐름도이다. 도 7a에서, 블록(705)에서, 도 1의 SSD(115)는 도 3의 블록들(325, 330)에서 발생한 에러들을 추적할 수 있다. 블록(710)에서, 도 1의 SSD(115)는 도 3의 메타데이터 스토리지(340)에 도 5의 장치-기반 로그 데이터(505)를 저장할 수 있다. 블록(715)에서, 도 1의 SSD(115)는 가장 오래된 에러에 대해 도 5의 장치-기반 로그 데이터(505)를 폐기할 수 있다. 블록(715)은 점선(720)으로 도시된 바와 같이, 폐기될 가장 오래된 에러에 대한 도 5의 장치-기반 로그 데이터(505)가 없는 경우 생략될 수 있다. 블록(725)에서, 도 1의 SSD(115)는 도 3의 메타데이터 스토리지(340)에 도 4의 정확한 블록-기반 데이터(405)를 저장할 수 있다.
블록(730)에서(도 7a), 도 1의 SSD(115)는 도 6의 근사 블록-기반 데이터(605)를 도출할 수 있다. 도 6을 참조하여 상술된 바와 같이, 도 6의 근사 블록-기반 데이터(605)는 도 3의 식별 펌웨어(345), 도 3의 검증 펌웨어(350), 또는 도 1의 SSD(115)의 일부 다른 구성 요소에 의해(예를 들어, 도 3의 SSD 컨트롤러(310)에 의해) 도출될 수 있다.
블록(735)에서, 도 3의 식별 펌웨어(345)는 곧 고장 날 것으로 의심되는 블록을 식별할 수 있다. 도 6을 참조하여 상술된 바와 같이, 식별 펌웨어(345)는 도 6의 근사 블록-기반 데이터(605), 도 5의 장치-기반 로그 데이터(505), 또는 다른 데이터를 사용하여 블록을 식별할 수 있다. 블록(740)에서, 도 3의 검증 펌웨어(350)는 의심되는 블록이 실제로 고장 날 것으로 예측되는지 여부를 검증할 수 있다. 도 6을 참조하여 상술된 바와 같이, 도 5의 검증 펌웨어(350)는 도 6의 근사 블록-기반 데이터(605), 도 4의 정확한 블록-기반 데이터(405), 도 5의 장치-기반 로그 데이터(505)를 사용하여 이러한 결정을 할 수 있고, 랜덤 포레스트(Random Fore) 알고리즘, 로지스틱 회귀(Logistic Regression) 알고리즘, 이상점 검출(Outlier Detection) 알고리즘, 예외 검출(Anomaly Detection) 알고리즘, 또는 기타 원하는 알고리즘을 사용할 수 있는, 머신 러닝-기반 고장 예측 모델과 같은 임의의 원하는 알고리즘을 사용하여 그렇게 할 수 있다.
블록(745)에서, 도 3의 검증 펌웨어(350)는 의심 블록이 실제로 곧 고장 날 것으로 예측되는지 여부를 결정할 수 있다. 그렇다면, 블록(750)에서 도 3의 검증 펌웨어(350는 의심되는 블록을 폐기할 수 있다. 의심 블록을 폐기하는 것은 블록에 현재 저장된 임의의 유효한 데이터를 다른 블록들(그리고 그러한 데이터들이 저장되는 위치를 식별하는 테이블들을 업데이트함)에 복사하는 것과 블록을 표시(또는 마킹)하여, 도 1의 SSD(115)가 어떤 새로운 데이터도 해당 블록에 쓰지 않도록 하는 것을 포함할 수 있다. 예를 들어, 도 5의 검증 펌웨어(350)는 각 블록을 유효하지 않은 데이터를 포함하는 것으로 표시할 수 있지만, 어떤 가비지 콜렉션 로직(garbage collection logic)이 가비지 콜렉션을 위한 블록을 선택하는 것을 어떻게든 차단할 수 있다.
이 시점에서, 도 3의 검증 펌웨어(350)가 의심 블록을 폐기했는지 여부에 관계없이, 컨트롤은 여러 포인트(또는 지점)들 중 어느 것으로 돌아갈 수 있다. 컨트롤은 점선(755)으로 도시된 바와 같이, 도 3의 SSD(115)에서 발생한 새로운 에러를 추적하기 위해 블록(705)으로 돌아올 수 있다. 또는, 점선(760)으로 도시된 바와 같이, 컨트롤은 곧 고장 날 것으로 의심되는 새로운 블록들에 대해 도 3의 SSD(115)를 스캔하기 위해 블록(730)으로 돌아갈 수 있다. 전자의 접근 방식은 미리 정해진 개수의 에러들이 발생한 후 의심 블록들을 스캔하는 시스템들에서 사용될 수 있다; 후자의 접근 방식은 미리 결정된 시간 간격이 경과한 후 의심 블록들을 스캔하는 시스템들에서 사용될 수 있다. 컨트롤은 또한 완전히 종료될 수도 있다.
상술된 바와 같이, 하나의 암시적 가정이 있다: 도 1의 SSD(115) 내의 임의의 특정 블록에서 에러가 발생할 가능성은 임의의 다른 블록에서 발생한 에러의 변화와 동일하다. 하지만 그 가정이 사실이 아니라면 어떨까요? 도 1의 SSD(115)에 다른 플래시 칩들이 다른 목적으로 사용된다면 어떨까요? 또는 도 1의 SSD(115)는 하나 이상의 유형의 플래시 스토리지를 포함하면 어떨까요? 이러한 상황들에서, 고장 날 것으로 예상되는 다른 유형의 플래시 스토리지에 사용 중인 블록들로 남기면서, 도 1의 SSD(115)의 일 부분 또는 한 유형의 플래시 스토리지는 보고된 에러들에서 압도적으로 우세할 수 있다.
이러한 문제들을 해결하기 위해, 상기 논의가 수정될 수 있다. 도 8은 두 가지 유형들의 NAND 플래시 스토리지를 사용하는 도 1의 SSD(115)의 세부 사항들을 나타낸다. 도 8에서, 플래시 칩들 중 일부가 QLC(Quad-Level Cell) 플래시 칩들(예를 들어, 플래시 칩들(805-1, 805-2, 805-3, 805-4, 805-5 및 805-6))이고, 다른 플래시 칩들은 SLC(Single-Level Cell) 플래시 칩(예를 들어, 플래시 칩들(810-1 및 810-2))인 것을 제외하고, SSD(115)는 도 3의 SSD(115)와 유사하다.
도 8의 SSD(115)이 서로 다른 두 가지 유형의 NAND 플래시 칩들을 포함하는 이유는 그것들의 다른 동작 특성들 때문이다. QLC 플래시 칩들은 SLC 플래시 칩들보다 셀 당 더 많은 정보를 보유할 수 있고(4 비트 대 1 비트), 이는 비슷한 크기의 SLC 플래시 칩보다 단일 QLC 플래시 칩에 더 많은 정보가 저장되는 것(또는, 단일 QLC 플래시 칩과 동일한 양의 데이터를 저장하려면 더 많은 SLC 플래시 칩이 필요할 수 있는 것)을 의미한다. 그러나 SLC 플래시 칩들과 비교할 때, QLC 플래시 칩들은 신뢰성(endurance)이 더 낮다: QLC 플래시 칩이 고장이 발생하기 전에 견딜 수 있는 쓰기-소거 주기(또는 사이클)(cycle)들의 개수는 SLC 플래시 칩들보다 QLC 플래시 칩들에서 더 낮을 수 있다. 예를 들어, SLC 플래시 칩은 장애들이 발생하기 전에, 100,000 회의 쓰기-소거 주기들을 견딜 수 있는 반면, QLC 플래시 칩은 장애들이 발생하기 전에 100 회의 쓰기-소거 주기만 견딜 수 있다. SLC 플래시 칩들은 더 높은 레이턴시(즉, 더 빠른 응답 시간)으로 작동할 수도 있다. 따라서 SSD(115)는 SLC 플래시 칩들(810-1, 810-2)을 캐시 계층으로 사용하여 QLC 플래시 칩들(805-1~805-6)에서 곧 읽을 것으로 예상되는 데이터를 프리-페치(pre-fetch)하고, QLC 플래시 칩들(805-1~805-6)에 기록될 데이터를 버퍼링 할 수 있다. 요컨대, QLC 플래시 칩들(805-1~805-6) 및 SLC 플래시 칩들(810-1, 810-2)는 서로 다른 액세스(또는 접근)(access) 패턴 및 워크로드를 경험할 수 있으며, 이로 인해 두 유형들의 플래시 스토리지 간에 서로 다른 에러율이 발생할 수 있다.
QLC 플래시 칩들(805-1~805-6)과 SLC 플래시 칩들(810-1, 810-2) 간에는 플래시 칩들이 사용되는 방식과는 무관할 수 있는 다른 차이점들이 있을 수 있다. 예를 들어, 서로 다른 플래시 칩들은 서로 다른 에러 특성들과 서로 다른 에러 정정 메커니즘을 가질 수 있다. 플래시 칩의 블록에 에러가 발생하더라도 사용중인 에러 정정 메커니즘에 따라 에러는 복구될 수 있다. 이러한 에러가 SSD(115)에 의해 추적되는지 여부(위와 아래에 설명됨)는 구현에 따라 달라질 수 있다. 한편으로는, 에러가 치명적(fatal)이지 않았으므로(에러 정정 메커니즘이 에러에서 복구될 수 있었기 때문에). 에러는 추적될 수 없다. 다른 한편으로는 에러가 발생했기 때문에(에러 복구 가능 여부에 관계없이), 블록 에러 카운터들은 적절하게 증가되고 에러 이력 테이블에 에러가 추가될 수 있다.
도 8은 6 개의 QLC 플래시 칩들(805-1~805-6) 및 2 개의 SLC 플래시 칩들(810-1, 810-2)을 포함하는 SSD(115)를 도시하는 반면에, 본 개시의 실시 예는 각 스토리지 유형의 임의의 개수의 플래시 칩들(0 개 이상)을 지원할 수 있다. 더욱이, 각 플래시 칩은 임의의 개수(0 개 이상의) 블록들을 지원할 수 있다: 서로 다른 스토리지 유형들의 플래시 칩들은 서로 다른 개수의 블록들을 포함할 수 있다(실제로 동일한 스토리지 유형의 서로 다른 플래시 칩들은 서로 다른 개수의 블록들도 포함될 수 있음).
도 8은 2 개의 상이한 유형들의 NAND 플래시를 포함하는 SSD(115)를 도시하지만, 본 개시의 실시 예들은 다른 구현들로 확장될 수 있다: 예를 들어, 두 가지 이상의 서로 다른 유형들의 플래시 스토리지(예를 들어, SLC 플래시 칩들, MLC 플래시 칩들, TLC 플래시 칩들, QLC 플래시 칩들, 및 PLC(Penta-Level Cell) 플래시 칩들 같은)를 사용하는 스토리지 장치들, 다른 스토리지 기술들(예를 들어, NOR 플래시와 같은)을 사용하는 스토리지 장치, 단일 유형의 플래시 스토리지 장치의 두 가지 다른 버전들(성능 특성들이 다를 수 있음)을 사용하는 스토리지 장치, 단일 유형의 스토리지이지만 용도들이 다르거나(예를 들어, 다른 워크플로우(workflow)) 또는 이들의 조합들. 아래 설명에서 "스토리지 유형"을 언급할 때마다이 용어는 특정 유형의 플래시 칩(또는 다른 유형의 스토리지), 하나의 유형의 특정 버전의 플래시 칩 또는 스토리지 장치의 다른 플래시 칩들과 다른 특정 방식으로 사용되는 플래시 칩을 의미한다. 따라서, 도 8에 도시된 실시 예에서, QLC는 제 1 스토리지 유형으로 간주될 수 있고, SLC는 제 2 스토리지 유형으로 간주될 수 있다.
마지막으로, 위와 아래의 논의는 도 8의 SSD(115)에 초점을 맞추고 있지만, 본 개시의 실시 예는 SSD들 이외의 다른 스토리지 장치들을 포함할 수 있다. 도 8의 SSD(115)와 같은 SSD에 대한 임의의 참조는 다른 스토리지 장치를 포함하는 것으로 이해될 수 있다.
도 9는 본 개시의 일 실시 예에 따른 도 8의 SSD(115)에 의해 사용될 수 있는 예시적인 블록 기반 데이터를 나타낸다. 도 9에서 도 8의 SSD(115)는 서로 다른 스토리지 유형들이 있기 때문에, 상이한 스토리지 유형들의 블록들에 대해 상이한 정보가 추적될 수 있다. 따라서, 도 8의 SSD(115)는 도 8의 QLC 플래시 칩들(805-1~805-6)의 블록들에 대한 블록-레벨 파라미터 카운터들(905-1), 도 8의 SLC 플래시 칩들(810-1, 810-2)의 블록에 대한 블록-레벨 파라미터 카운터들(905-2)을 저장할 수 있다.
도 4의 블록-레벨 파라미터 카운터들(405)과 유사한, 블록-레벨 파라미터 카운터들(905-1, 905-2)은 카운터들(910-1, 910-2, 910-3, 910-4, 910-5, 910-6)을 포함할 수 있으며, 이는 대응하는 블록들에서 발생한 읽기 에러들의 개수(Read Error Count), 쓰기 에러들의 개수(Write Error Count), 및 소거 에러들의 개수(Erase Error Count)가 포함될 수 있다. 그러나 카운터들(910-1 ~ 910-3)은 QLC 플래시 미디어에 특유한(specific) 에러 카운터들(QLC-Specific Error Counts)포함할 수 있고, 카운터들(910-4 ~ 910-6)은 SLC 플래시 미디어에 특유한 에러 카운터들(SLC-Specific Error Counts)을 포함할 수 있다. 이러한 QLC 및 SLC 특유한 에러 카운터들은 도 8의 SSD(115)에 대한 장치-레벨 파라미터들(단일 유형의 미디어만 포함)로 간주되었던 정보를 포함할 수 있고, 또는 QLC 플래시 칩들 및 SLC 플래시 칩들의 개별 블록들에 특유하지만 다른 스토리지 유형의 블록들에 대해 반드시 추적되지는 않는 정보를 포함할 수 있다. (물론, 단일 스토리지 유형의 모든 블록들에 걸쳐 있는 카운터들의 경우, 이러한 정보는 개별 블록 카운터들(910-1 ~ 910-6)가 아닌 아래의 도 10을 참조하여 설명된 바와 같이 장치-레벨 파라미터들에 저장될 수 있다.)
도 8의 SSD(115)는 각 스토리지 유형의 상이한 개수의 블록들을 포함할 수 있으며, 블록 레벨 파라미터 카운터들(905-1, 905-2)에 저장되는 블록 카운터들의 개수는 상이할 수 있다. 따라서, 예를 들어, 도 8의 QLC 플래시 칩들(805-1~805-6)에 750,000 개의 블록들이 있을 수 있고, SLC 플래시 칩들(810-1, 810-2)에 250,000 블록들이 있을 수 있다. 따라서, QLC 블록-레벨 파라미터들(905-1)의 카운터들 개수는 SLC 블록-레벨 파라미터들(905-2)의 카운터들의 개수와 다를 수 있다.
도 10은 본 개시의 일 실시 예에 따른 도 8의 SSD(115)에 의해 사용될 수 있는 장치-기반 로그 데이터를 나타낸다. 도 10에서, 장치-레벨 파라미터들이 도시된다. 도 1의 SSD(115)는 단일 세트의 장치-레벨 파라미터들(일부는 도 5의 SMART 로그 데이터(515-1)에 도시됨)를 포함할 수 있지만, 장치-레벨 파라미터 (1005)는 QLC 미디어 및 SLC 미디어에 대한 별도의 로그들을 포함할 수 있다. 즉, QLC 로그(1010-1)는 QLC 미디어와 관련된 정보를 저장할 수 있고, SLC 로그(1010-2)는 SLC 미디어와 관련된 정보를 저장할 수 있다. QLC 로그(1010-1) 및 SLC 로그(1010-2)가 유사한 파라미터들을 갖는 것처럼 보이지만, 이러한 파라미터들에 대한 값들은 다를 수 있다. 예를 들어, QLC 로그(1010-1)에 저장된 읽기들의 개수(Number of Reads)는 도 8의 QLC 플래시 칩들(805-1~805-6)의 블록들로부터 읽기 동작들의 개수를 나타낼 수 있고, 반면에 SLC 로그(1010-2)에 저장된 읽기들의 개수(Number of Reads)는 도 8의 SLC 플래시 칩들(810-1, 810-2)의 블록들로부터 읽기 동작들의 개수를 나타낼 수 있다. 값들은 다를 수 있으므로 파라미터 이름이 동일하더라도, 파라미터들은 각 스토리지 유형에 대해 별도의 로그들에 저장될 수 있다.
장치-레벨 파라미터(1005)는 또한 공통 파라미터들(1015)을 포함할 수 있다. 공통 파라미터(1015)는 모든 스토리지 유형들에 대해 값이 동일한 파라미터들을 나타낼 수 있다. 예를 들어, 도 8의 SSD(115)에 대한 파워 주기(cycle)들의 개수는 도 8의 QLC 플래시 칩들(805-1~805-6) 또는 도 8의 SLC 플래시 칩들(810-1, 810-2) 상관없이 모든 블록들에 대해 동일하다. 따라서 이러한 파라미터들은 QLC 로그(1010-1) 및 SLC 로그(1010-2)에 별도로 저장되지 않고 공통 영역에 저장될 수 있다. 그러나 이러한 공통 파라미터들은 QLC 로그(1010-1) 및 SLC 로그(1010-2) 각각에 한 번씩 저장된다면, 유일한 결과는 이러한 파라미터들에 의해 사용하는 스토리지 양을 두 배로 늘리는 것이다. (그리고, 파라미터가 두 번 저장되기 때문에 값들이 변경됨에 따라 각 파라미터에 대해 한 번 대신에 두 번의 업데이트들이 수행될 수 있다).
도 10에 도시된 본 개시의 실시 예와는 다르게, 도 5에 도시된 바와 같이, 본 개시의 일부 실시 예들에서 통합 장치 로그가 사용될 수 있다. 그러나 도 8의 SSD(115)는 여러 스토리지 유형들을 포함할 수 있으므로, 문제는 각 스토리지 유형이 단일 파라미터의 전체 값에 얼마나 기여할 수 있는지 이다.
예를 들어, 위의 도 8의 SSD(115)에 대한 설명을 고려한다. SLC 플래시 칩들(810-1, 810-2)의 경우. 도 8의 QLC 플래시 칩들(805-1~805-6)에 대한 캐시로 사용되는 경우, 호스트의 요청에 따라 읽힐 수 있는 데이터는 도 8의 QLC 플래시 칩들(805-1~805-6)의 블록들로부터 읽히고, 도 8의 SLC 플래시 칩들(810-1, 810-2)에 저장된다. 요컨대, 데이터는 도 8의 QLC 플래시 칩들(805-1~805-6)로부터 도 8의 SLC 플래시 칩들(810-1, 810-2)로 프리-페치된다.
그러나 프리-페치는 어떤 데이터가 요청되었는지를 예측하려는 시도이다. 도 8의 SSD(115)는 프리-페치 동작들에서 완벽한 경우, 그 다음 도 8의 QLC 플래시 칩들(805-1~805-6)로부터 데이터에 대한 모든 읽기 동작은 도 8의 SLC 플래시 칩들(810-1, 810-2)로부터 대응하는 읽기 동작을 가질 수 있다. 이 경우, 모든 읽기 동작들의 절반은 도 8의 QLC 플래시 칩들(805-1~805-6)에서 이고, 모든 읽기 동작들의 나머지 절반은 도 8의 SLC 플래시 칩들(810-1, 810-2)에서 이다. 한편, 도 8의 SSD(115)가 프리-페치 동작들에서 완전히 실패한 경우, 모든 읽기 동작들은 도 8의 QLC 플래시 칩들(805-1~805-6)로부터 이다(즉, 도 8의 SSD(115)는 도 8의 QLC 플래시 칩들(805-1~805-6)로부터 도 8의 SLC 플래시 칩들(810-1, 810-2)로 데이터를 결코 성공적으로 프리-페치하지 않는다): 도 8의 SLC 플래시 칩들(810-1, 810-2)로부터 하나도 없다. 따라서, 도 8의 QLC 플래시 칩들(805-1~805-6) 대 도 8의 SLC 플래시 칩들(810-1, 810-2)에 대한 실제 사용 패턴들(워크 플로우)는 각 스토리지 유형이 읽기 동작들의 개수와 같은 전체 파라미터들에 얼마나 기여할 수 있는지에 영향을 미칠 수 있다.
다른 동작들도 마찬가지일 수 있다: 예를 들어, 도 8의 SLC 플래시 칩들(810-1, 810-2)이 도 8의 QLC 플래시 칩들(805-1~805-6)을 위한 쓰기 버퍼로 사용되는 경우, 그러면 일부 쓰기 동작들은 도 8의 SLC 플래시 칩들(810-1, 810-2)에 기인(attributable)할 수 있고, 일부 쓰기 동작들은 도 8의 QLC 플래시 칩들(805-1~805-6)에 기인할 수 있다.
본 개시의 일 실시예는 각각의 스토리지 유형 및 전체 스토리지 장치에 대한 쓰기 동작들 및 읽기 동작들의 개수와 관련하여 사용될 수 있는, 조정 가능한 변수들 α 및 β에 기초하여 특정 파라미터에 대한 스토리지 유형의 상대적 기여도를 계산할 수 있다. 예를 들어, 주어진 파라미터 X에 대해, 전체 파라미터에 대한 각 스토리지 유형의 기여도는 수학식 11 및 수학식 12를 사용하여 계산될 수 있다.
다시 말해서, 스토리지 장치 전체와 QLC 및 SLC 매체에 대해 개별적으로 수행되는 읽기 동작들 및 쓰기 동작들의 개수에 대한 카운터가 주어지면, 통합 파라미터(예를 들어, 소거 동작들의 개수 또는 컨트롤러 비지 시간(bust time))에 대한 각 스토리지 유형의 상대적 기여도는 α 및 β에 대해 적절하게 조정된 값들을 사용하여 계산될 수 있다. 통합 파라미터들은 각 스토리지 유형별 쓰기 및 읽기 동작들의 개수를 별도로 추적하지 않을 수 있으므로, 도 8의 SSD(115)는 이 정보도 추적할 수 있으나, 그러한 정보에 대한 스토리지의 양은 몇 바이트에 불과하다(예를 들어, 각 카운터들에 대해 4바이트). 이러한 추가 정보(스토리지 유형별 카운터들 및 각 파라미터에 대한 α 및 β에 대한 값들)는 예를 들어 도 8의 메타데이터 스토리지(340)에 저장될 수 있다.
α 및 β에 대한 값들은 고려되는 파라미터에 의존할 수 있다. 예를 들어, 소거 동작들의 개수는 쓰기 동작들의 개수에 엄격하게 의존하므로(읽기 동작들은 얼마나 많이 쓰기 동작들이 수행되는지 영향을 미치지 않음), 소거 동작들의 개수에 대해 파라미터 α는 1로 설정될 수 있고 β는 0으로 설정될 수 있다. 반면에 컨트롤러는 각 읽기 및 쓰기 동작에 대해 동일하게 비지(busy)(또는 사용 중)이므로 컨트롤러 비지 시간 파라미터에 대한 α는 0.5로 설정되고 β는 0.5로 설정될 수 있다. 본 개시의 몇몇 실시예에서, α와 β는 각각이 0에서 1 사이의 양의 값이고, α와 β의 합이 1이어야 한다는 제약들에 제한 받을 수 있다; 본 개시의 다른 실시 예들에서 이러한 제약들은 완화될 수 있다.
α 및 β에 대한 값들의 선택은 각 파라미터에 대해 미리 고정될 수 있거나, 선택은 최종 사용자에 의해 조정될 수 있다. 예를 들어, 일부 소비자들은 도 8의 SLC 플래시 칩들(810-1, 810-2)을 도 8의 QLC 플래시 칩들(805-1~805-6)에 대한 읽기 캐시로 작동하도록(또는 기능하도록) 구성할 수 있다; 다른 소비자들은 도 8의 SLC 플래시 칩들(810-1, 810-2)을 도 8의 QLC 플래시 칩들(805-1~805-6)에 대한 쓰기 버퍼로서 작동하도록 구성할 수 있다; 또 다른 소비자들은 도 8의 SLC 플래시 칩들(810-1, 810-2)을 도 8의 QLC 플래시 칩들(805-1~805-6)에 대한 읽기 캐시 및 쓰기 버퍼 둘 다로 작동하도록 구성할 수 있다; 또 다른 소비자들은 도 8의 SLC 플래시 칩들(810-1, 810-2)을 도 8의 QLC 플래시 칩들(805-1~805-6)과 같이 일반 스토리지로 작동하도록 구성할 수 있다. 이러한 각 사용 사례들에 대해, 소비자들은 사용 사례에 적합한 α 및 β에 대한 값들을 구성할 수 있다(소비자는 그들이 선호하는 α 및 β에 대한 값들을 선택할 수 있거나, 도 8의 SSD(115)는 상이한 사용 사례들에 대해 미리 선택된 값들을 나타내는 α 및 β에 대한 값들의 표(또는 테이블(table))들을 포함할 수 있고, 소비자는 소비자가 도 8의 SSD(115)를 사용하는 방법과 가장 일치하는 사용 사례를 선택할 수 있다).
마지막으로, 위의 수학식들은 각 스토리지 유형의 상대적 기여도를 설명한다. 도 5를 참조하여 설명된 근사 블록-기반 로그 데이터의 계산(또는 연산)과 유사하게, 결과 값들은 해당 스토리지 유형에 대한 블록들의 개수로 나누어, 스토리지 유형에 대해 계산된 파라미터에 대한 스토리지 유형 내의 각 블록의 상대적 기여도를 결정할 수 있다.
위의 논의는 2개의 스토리지 유형들에 초점을 맞추고 있지만, 본 개시의 실시 예들은 2개 이상의 스토리지 유형들로 확장될 수 있다. 변수들 α와 β는 스토리지 유형이 두 개 이상인 경우에도 동일할 수 있다.
도 11은 본 개시의 다른 실시예에 따른, 스토리지 유형 파라미터를 결정하기 위한 다른 정보와 함께 도 5의 장치-기반 로그 데이터(502)를 사용하는 것을 나타낸다. 도 11에서, 스토리지 유형 파라미터화(1105)는 장치-기반 로그 데이터(505), 스토리지 유형(1110), 및 변수들(1115)(예를 들어, α, β)을 사용할 수 있다. 이 정보가 주어지면, 파라미터의 전체 값들에 대한 특정 스토리지 유형의 근사 상대적 기여도를 가리키는 스토리지 유형 파라미터(1120)는 계산될 수 있다.
도 12는 본 개시의 일 실시예에 따라 서로 다른 스토리지 유형들에 대한 부분들로 분할된, 도 8의 SSD(115)에 의해 사용될 수 있는 에러 이력 테이블을 나타낸다. 도 12에서, 에러 이력 테이블(1205)이 도시된다. 에러 이력 테이블(1205)은 도 5를 참조하여 상술된 k개의 가장 최근의 에러들과 같은 개별 에러들에 대한 정보를 저장할 수 있다. 그러나 상술된 바와 같이, 도 8의 SSD(115)는 다수의 스토리지 유형들을 포함하며, 고장 날 것으로 예측될 수 있는 블록들의 식별에서 다른 스토리지 유형(들)을 주시하면서, 하나의 스토리지 유형에서 발생하는 에러들이 가장 최근의 에러들에서 압도적으로 우세할 수 있다.
예를 들어, 도 8의 QLC 플래시 칩들(805-1~805-6) 및 도 8의 SLC 플래시 칩들(810-1, 810-2)을 갖는 도 8의 SSD(115)를 다시 고려한다. SLC 플래시 칩들보다 3배 많은 QLC 플래시 칩들이 있기 때문에, 에러들의 3/4이 도 8의 QLC 플래시 칩들(805-1~805-6)에서 발생할 것으로 예상될 수 있다. 도 8의 QLC 플래시 칩들(805-1~805-6)이 도 8의 SLC 플래시 칩들(810-1, 810-2)보다 1000배 더 큰 비율로 에러들을 경험(또는 발생)할 수 있는 점을 고려하면, 도 8의 SLC 플래시 칩들(810-1, 810-2)의 1개의 에러마다 도 8의 QLC 플래시 칩들(805-1~805-6)에서 대략 3000개의 에러들이 발생할 것으로 예상하는 것이 합리적일 것이다. 에러 이력 테이블(1205)이 예를 들어 100개의 에러들만을 위한 공간을 포함하는 경우, 도 8의 SLC 플래시 칩들(810-1, 810-2)의 블록들이 고장 날 가능성이 있는 것으로 식별될 가능성은 거의 없다.
해결책은 에러 이력 테이블(1205)을 여러 부분들로 나누는 것이며, 각 부분은 특정 스토리지 유형에 대한 에러들을 저장한다. 각 스토리지 유형에 대해 예약된(또는 마련된) 에러 이력 테이블(1205)의 에러들의 개수는 임의의 원하는 방식으로 선택될 수 있다. 예를 들어, 스토리지 장치의 전체 크기에 대한 각 스토리지 유형의 크기가(예를 들어, 각 스토리지 유형의 크기 대 스토리지 장치의 전체 크기의 비율) 사용될 수 있다. 따라서, 예를 들어 도 8의 QLC 플래시 칩들(805-1~805-6)은 도 8의 SSD(115) 크기의 75%를 나타내고, 도 8의 SLC 플래시 칩들(810-1, 810-2)은 도 8의 SSD(115) 크기의 25%를 나타내는 경우, 에러 이력 테이블(1205)의 75%가 도 8의 QLC 플래시 칩들(805-1~805-6)의 에러들을 위해 예약(reserve)(또는 사용)될 수 있고(부분(1210)에 의해 도시된 바와 같이), 에러 이력 테이블(1205)의 25%는 도 8의 SLC 플래시 칩들(810-1, 810-2)의 에러들을 위해 예약될 수 있다(부분(1215)에 의해 도시된 바와 같이).
이와 관련하여, "크기(size)"는 원하는 대로 칩들의 개수, 전체 용량, 블록들의 개수, 또는 다른 스토리지 유형들의 임의의 다른 측정을 나타낼 수 있다. 예를 들어, 도 8의 SSD(115)는 6개의 QLC 플래시 칩들과 2개의 SLC 플래시 칩들을 포함하고, 도 8의 SSD(115)에는 총 8개의 플래시 칩들이 있고, 그중 75%는 QLC 플래시 칩들이고 25%는 SLC 플래시 칩들이다. 따라서, 에러 이력 테이블(1205)의 75%는 도 8의 QLC 플래시 칩들(805-1~805-6)의 에러들을 위해 예약(또는 사용)될 수 있고, 에러 이력 테이블(1205)의 25%는 도 8의 SLC 플래시 칩들(810-1, 810-2)의 에러들을 위해 예약(또는 사용)될 수 있다.
또는, 예를 들어 도 8의 QLC 플래시 칩들(805-1~805-6)은 900GB의 총 보고된 스토리지를 제공하고, 도 8의 SLC 플래시 칩들(810-1, 810-2)의 100GB의 총 보고된 스토리지를 제공하는 경우, 도 8의 QLC 플래시 칩들(805-1~805-6)은 도 1의 SSD(115) 용량의 90%를 제공하고 도 8의 SLC 플래시 칩들(810-1, 810-2)은 도 1의 SSD(115) 용량의 10%를 제공한다. 따라서, 에러 이력 테이블(1205)의 90%는 도 8의 QLC 플래시 칩들(805-1~805-6)의 에러들을 위해 예약될 수 있고, 에러 이력 테이블(1205)의 10%는 도 8의 SLC 플래시 칩들(810-1, 810-2)의 에러들을 위해 예약될 수 있다.
또는, 예를 들어 도 8의 QLC 플래시 칩들(805-1~805-6)은 총 800,000개의 블록들을 포함하고, 도 8의 SLC 플래시 칩들(810-1, 810-2)은 총 200,000개의 블록들을 포함하는 경우, 도 8의 QLC 플래시 칩들(805-1~805-6)은 도 1의 SSD(115)에서 블록들의 80%를 포함하고, 도 8의 SLC 플래시 칩들(810-1, 810-2)은 도 1의 SSD(115)에서 블록들의 20%를 포함한다. 따라서, 에러 이력 테이블(1205)의 80%는 도 8의 QLC 플래시 칩들(805-1~805-6)의 에러들을 위해 예약될 수 있고, 에러 이력 테이블(1205)의 20%는 도 8의 SLC 플래시 칩들(810-1, 810-2)의 에러들을 위해 예약될 수 있다.
도 13a 및 도 13b는 본 개시의 실시 예들에 따라 도 8의 SSD(115)에서 특정 스토리지 유형의 블록이 고장 날 것으로 예측되는지 여부를 검증하기 위해 사용될 수 있는 상이한 모델들을 나타낸다. 도 13a에서 모델들(1305, 1310)은 도시된다. 모델(1305)은 식별된 SLC 블록이 고장 날 것으로 예측되는지 여부를 검증하는 데 사용될 수 있는 반면, 모델(1310)은 식별된 QLC 블록이 고장 날 것으로 예측되는지 여부를 검증하는 데 사용될 수 있다. SLC와 QLC 매체는 상이한 쓰기/소거 주기(cycle), 상이한 읽기 레이턴시/속도, 상이한 에러 정정/복구, 상이한 워크로드들 및/또는 상이한 에러 비율과 같은 상이한 에러 특성들을 갖기 때문에, 한 스토리지 유형의 블록은 특정 에러 후에 고장 날 것으로 예측될 수 있지만, 다른 스토리지 유형의 블록은 고장 날 것으로 예측되지 않을 수 있다. 서로 다른 스토리지 유형들에 대해 별도의 모델들(예를 들어, 상술된 바와 같이, 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 등)을 사용함으로써, 각 모델은 해당 모델이 적용되는 스토리지 유형에 맞게 특별히 훈련 및/또는 설계될 수 있다.
한편, 도 13b에서 모델(1315)이 도시된다. 도 13b에서, 서로 다른 스토리지 유형들에 대해 서로 다른 모델들을 사용하는 대신 단일 모델이 사용될 수 있다. 이 모델은 특정 블록이 고장 날 것으로 예상되는지 여부를 결정하기 위해 모델(1315)에 의해 사용될 수 있는 입력(input)으로서 스토리지 유형(1110)을 수신할 수 있다. 이러한 방식으로 단일 모델은 하나 이상의 스토리지 유형에서 블록이 고장 날 것으로 예측되는지 여부를 예측하기위해 사용될 수 있다: 모델(1315)은 입력으로 수신된 스토리지 유형(1110)에 따라, 도 13a의 모델들(1305, 1310) 중 하나로 효과적으로 동작할 수 있다.
도 14a 및 도 14b는 본 개시의 실시예들에 따른 도 8의 SSD(115)에서 블록이 고장 날 것으로 예상되는지 여부를 결정하기 위한 예시적인 절차의 흐름도를 나타낸다. 도 14a 및 도 14b는 도 7a 및 도 7와 유사하고, 설명된 동작들이 유사한 경우 유사한 참조 번호들이 사용된다.
도 14a의 블록(705)에서, 도 8의 SSD(115)는 도 8의 블록(325, 330)에서 발생한 에러들을 추적할 수 있다. 블록(705)은 스토리지 유형 모두(또는 둘 이상이 있는 경우 모두)의 에러들을 추적할 수 있다. 블록(1405)에서, 도 8의 SSD(115)는 도 5의 장치-기반 로그 데이터(505) 또는 도 10의 장치-기반 로그 데이터(1005)를 메타데이터 스토리지(340)에 저장할 수 있다. 블록(1410)에서, 도 8의 SSD(115)는 동일한 스토리지 유형의 가장 오래된 에러에 대한 도 5의 장치-기반 로그 데이터(505) 또는 도 10의 장치-기반 로그 데이터(1005)를 폐기할 수 있다. 하나 이상의 저장 유형이 있을 수 있기 때문에, 도 12의 에러 이력 테이블(1205)에서 가장 오래된 에러는 다른 스토리지 유형일 수 있으므로, 유지될 수 있음을 주의한다: 도 12의 에러 이력 테이블(1205)로부터 그 스토리지 유형에 대한 가장 오래된 에러는 폐기될 수 있다. 블록(1410)은 점선(720)으로 도시된 바와 같이, 폐기될 가장 오래된 에러에 대한 도 5의 장치-기반 로그 데이터(505) 또는 도 10의 장치-기반 로그 데이터(1005)가 없는 경우 생략될 수 있다. 블록(1415)에서, 도 8의 SSD(115)는 도 4의 정확한 블록-기반 데이터(405)를 도 8의 메타데이터 스토리지(340)에 저장할 수 있다. 더욱이, 블록(1415)에서 도 8의 SSD(115)는 스토리지 유형에 의존하는 다른 정확한 블록-기반 데이터를 도 8의 메타데이터 스토리지(340)에 저장할 수 있다: 예를 들어, 도 9의 블록-레벨 파라미터 카운터들(905-1, 905-2).
블록(1420)(도 14b)에서, 도 8의 SSD(115)는 도 6의 근사 블록-기반 데이터(605)를 유도할 수 있다. 도6, 도 10, 도 11을 참조하여 위에서 논의된 바와 같이, 도 6의 근사 블록-기반 데이터(605)는 도 8의 식별 펌웨어(345) 또는 도 8의 SSD(115)의 일부 다른 구성요소(예를 들어, 도 8의 SSD 컨트롤러(310))에 의해 유도될 수 있다. 더욱이, 도 11의 스토리지 유형 파라미터화(1105)는 둘 이상의 스토리지 유형들에 대해 값들이 통합된 파라미터에 대한 도 6의 근사 블록-기반 데이터(605)를 결정하는데 사용될 수 있다. 도 8의 SSD(115)는 다수의 스토리지 유형들을 포함할 수 있으므로, 근사 블록-기반 데이터는 도 8의 SSD(115)의 모든 블록들 대신에, 개별 스토리지 유형들의 크기에 비례할 수 있다.
블록(735)에서, 도 8의 식별 펌웨어(345)는 곧 고장 날 것으로 의심되는 블록을 식별할 수 있다. 도 6를 참조하여 위에서 논의된 바와 같이. 식별 펌웨어(345)는 도 6의 근사 블록-기반 데이터(605), 도 5의 장치-기반 로그 데이터(505) 또는 기타 데이터를 사용하여 블록을 식별할 수 있다. 블록(740)에서, 도 8의 검증 펌웨어(350)는 의심되는 블록이 실제로 고장 날 것으로 예측되는지 여부를 검증할 수 있다. 도 6를 참조하여 위에서 논의된 바와 같이, 도 5의 검증 펌웨어(350)는 도 6의 근사 블록-기반 데이터(605), 도 4의 정확한 블록-기반 데이터(405), 도 5의 장치-기반 로그 데이터(505) 또는 기타 데이터를 사용하여 이러한 결정을 내릴 수 있고, 랜덤 포레스트(Random Forest) 알고리즘, 로지스틱 회귀(Logistic Regression) 알고리즘, 이상점 검출(Outlier Detection) 알고리즘, 예외 검출(Anomaly Detection) 알고리즘 또는 기타 원하는 알고리즘을 사용할 수 있는, 머신 러닝-기반 고장 예측 모델과 같은 원하는 알고리즘을 사용하여 수행할 수 있다.
블록(745)에서, 도 8의 검증 펌웨어(350)는 의심되는 블록이 실제로 곧 고장 날 것으로 예측되는지 여부를 결정할 수 있다. 그렇다면, 블록(750)에서 도 8의 검증 펌웨어(350)는 의심되는 블록을 폐기할 수 있다. 의심되는 블록을 폐기(retire)하는 것은 블록에 현재 저장된 임의의 유효한 데이터를 다른 블록들로 복사하는 것(및 이러한 데이터가 저장된 위치를 식별하는 임의의 테이블을 업데이트하는 것) 및 도 8의 SSD(115)가 해당 블록에 새로운 데이터를 쓰지 않도록 블록을 표시하는 것을 포함할 수 있다. 예를 들어, 도 5의 검증 펌웨어(350)는 각 블록을 유효하지 않은(또는 무효) 데이터를 포함하는 것으로 표시할 수 있지만, 임의의 가비지 콜렉션 로직이 가비지 콜렉션을 위한 블록을 선택하는 것을 어떻게든 차단할 수 있다.
이 시점에서, 도 8의 검증 펌웨어(350)가 의심되는 블록을 폐기했는지 여부에 관계없이, 컨트롤(또는 제어)은 여러 지점들 중 어느 하나로 돌아갈 수 있다. 컨트롤은 점선(755)으로 도시된 바와 같이, 도 8의 SSD(115)에서 발생한 새로운 에러를 추적하기 위해 블록(705)으로 돌아갈 수 있다. 또는, 컨트롤은 점선(760)으로 도시된 바와 같이, 곧 고장 날 것으로 의심되는 새로운 블록에 대해 도 8의 SSD(115)를 스캔하기 위해 블록(1420)으로 돌아갈 수 있다. 전자의 접근 방식은 미리 정해진 개수의 에러들이 발생한 후 의심 블록들을 스캔하는 시스템들에서 사용될 수 있다; 후자의 접근 방식은 미리 결정된 시간 간격이 경과한 후 의심 블록들을 스캔하는 시스템들에서 사용될 수 있다. 컨트롤은 또한 완전히 종료될 수도 있다.
도 15는 본 개시의 실시 예들에 따라 도 8의 SSD(115)에 장치-기반 로그 데이터(1005)를 저장하기 위한 예시적인 절차의 흐름도를 나타낸다. 도 15의 블록(1505)에서, 도 8의 SSD(115)는 각 스토리지 유형에 대한 스토리지 유형 로그들(1010-1, 1010-2)과 같은 별도의 블록-기반 로그 데이터를 저장할 수 있다. 또는, 블록(1510)에서, 도 8의 SSD(115)는 모든 스토리지 유형들에 대한 통합 장치-기반 로그 데이터(도 5의 장치-기반 로그 데이터(505)와 같은)를 저장할 수 있고, 블록(1515)에서 도 11의 스토리지 유형 파라미터화(1105)는 통합 장치-기반 로그 데이터를 기반으로 각 스토리지 유형에 대한 파라미터들을 결정할 수 있다.
도 16은 본 개시의 실시 예들에 따른 도 8의 SSD에서 예측된 블록이 고장 날 것으로 예상되는지 여부를 검증하기 위해 모델들을 사용하기 위한 예시적인 절차의 흐름도를 나타낸다. 블록(1605)에서, 도 8의 검증 펌웨어(350)는 곧 고장 날 것으로 의심되는 블록의 스토리지 유형에 기초하여 도 13a의 적절한 모델(1305 또는 1310)을 선택할 수 있다. 또는, 블록(1610)에서, 도 8의 검증 펌웨어(350)는 여러 스토리지 유형들을 지원할 수 있는 도 13b의 모델(1315)을 사용할 수 있다: 도 3의 검증 펌웨어(350)는 블록이 그 스토리지 유형에 적절하게 고장 날 것으로 예측되는지 여부를 결정하는 데 도움이 되도록, 도 13b의 모델(1315)에게 도 11의 스토리지 유형(1110)을 제공할 수 있다.
도 7a, 도 7b, 도 14a 내지 도 16을 참조하여, 본 개시의 몇몇 실시 예들이 도시된다. 그러나 통상의 기술자는 블록들의 순서를 변경하거나, 블록들을 생략하거나, 또는 도면들에 도시되지 않은 링크들을 포함함으로써, 본 개시의 다른 실시 예들이 가능함을 인식할 것이다. 흐름도들의 이러한 모든 변형들은 명시적으로 묘사되든 아니든, 본 개시의 실시 예들로 고려된다.
본 개시의 실시 예들은 이전 기술에 비해 기술적 이점들을 제공한다. 첫째, 본 개시의 실시 예들은 종래 시스템들에 의해 제공되지 않는, 세분화된 블록 고장 예측을 허용한다. 둘째, 본 개시의 실시 예들은 의심 블록의 식별과 의심 블록이 실제로 고장 날 것으로 예측되는지 검증하는 것을 구분함으로써 고장 날 것으로 예측되는 블록들의 높은 식별 오진(false positive) 가능성을 회피한다. 셋째, 본 개시의 실시 예들은 종래 시스템들에서 이러한 예측들과 관련된 상당한 계산 리소스들을 요구하는 것 없이 의심 블록이 고장 날 것으로 예측되는지 검증할 수 있다. 넷째, 본 개시의 실시 예들은 다른 블록들도 고장 날 것으로 예측되는지 여부를 결정할 필요 없이, 특정 블록이 고장 날 것으로 예측되는지 여부를 검증할 수 있도록 하여, 사용되는 계산 리소스들을 최소화할 수 있다. 다섯째, 스토리지 장치가 하나 이상의 스토리지 유형을 포함하는 경우에도, 본 개시의 실시예들은 특정 블록이 블록의 스토리지 유형을 고려하여 고장 날 것으로 예측되는지 여부를 검증할 수 있다.
다음 논의는 본 개시의 특정 측면들이 구현될 수 있는 적합한 머신 또는 머신들의 간략하고, 일반적인 설명을 제공하기 위한 것이다. 머신 또는 머신들은, 적어도 부분적으로, 키보드들, 마우스들 등과 같은, 종래의 입력 장치들의 입력에 의해 제어될 뿐만 아니라, 다른 머신으로부터 수신되는 지시들, 가상현실(VR) 환경과의 인터랙션, 생체 인식 피드백, 또는 기타 입력 신호에 의해 제어될 수 있다. 본 명세서에서 사용된 바와 같이, "머신"이라는 용어는 단일 머신, 가상 머신 또는 통신적으로 결합된 머신들, 가상 머신들 또는 함께 작동하는 장치들의 시스템을 광범위하게 포함하는 것으로 의도된다. 예시적인 머신들은 개인용 컴퓨터들, 워크스테이션(workstation)들, 서버들, 휴대용 컴퓨터들, 핸드헬드(handheld) 장치들, 전화기들, 태블릿들 등과 같은 컴퓨팅 장치들뿐만 아니라 개인 또는 대중 교통(예를 들어, 자동차들, 기차들, 택시들 등)과 같은 운송 장치들을 포함한다.
머신 또는 머신들은 프로그래머블(programmable) 또는 논-프로그래머블(non-programmable) 논리 장치들 또는 어레이들, ASICs(Application Specific Integrated Circuits), 내장형 컴퓨터들, 스마트 카드들 등과 같은 내장형 컨트롤러들을 포함할 수 있다. 머신 또는 머신들은 네트워크 인터페이스, 모뎀, 또는 기타 통신 결합을 통한 것과 같이, 하나 이상의 원격 머신들에 대한 하나 이상의 연결들을 활용할 수 있다. 머신들은 인트라넷, 인터넷, 근거리 통신망들, 광역 통신망들 등과 같은 물리적 및/또는 논리적 네트워크를 통해 상호 연결될 수 있다. 통상의 기술자는 네트워크 통신이 무선 주파수(RF), 위성, 마이크로파, 전기전자공학연구소(IEEE) 802.11, 블루투스®, 광학, 적외선, 케이블, 레이저 등을 포함한, 다양한 유선 및/또는 무선 단거리 또는 장거리 캐리어들 및 프로토콜들을 활용할 수 있다는 점을 높이 평가할 것이다.
본 개시의 실시 예들은 기능들, 절차들, 데이터 구조들, 응용 프로그램들 등을 포함한 관련 데이터를 참조하거나 그와 관련하여 설명될 수 있고, 이는 머신에 의해 액세스 될 때 머신이 태스크(task)들을 수행하거나 추상 데이터 타입들 또는 로우-레벨(low-level) 하드웨어 컨텍스트(context)들을 정의하게 한다. 관련 데이터는, 예를 들어, 휘발성 및/또는 불휘발성 메모리(예를 들어, RAM, ROM 등), 또는 하드-드라이브들, 플로피-디스크들, 광학 스토리지, 테이프들, 플래시 메모리, 메모리 스틱들, 디지털 비디오 디스크들, 생물학적 스토리지 등을 포함한 다른 스토리지 장치 및 관련 스토리지 매체에 저장될 수 있다. 관련된 데이터는, 패킷들, 직렬 데이터, 병렬 데이터, 전파된 신호들 등의 형태로, 물리적 및/또는 논리적 네트워크를 포함하는, 전송 환경들을 통해 전달될 수 있고 압축 또는 암호화된 형태로 사용될 수 있다. 관련 데이터는 분산 환경에서 사용될 수 있으며, 머신 액세스를 위해 국부적으로 및/또는 원격으로 저장될 수 있다.
본 개시의 실시 예들은 하나 이상의 프로세서들에 의해 실행 가능한 명령어들로 구성되는 실재하고, 비-일시적 머신-판독 가능 매체를 포함할 수 있으며, 상기 명령어들은 본 명세서에 설명된 본 개시의 요소를 수행하기 위한 명령어들을 포함한다.
상술된 방법의 다양한 동작들은 다양한 하드웨어 및/또는 소프트웨어 요소(들), 회로들 및/또는 모듈(들)과 같은, 동작들을 수행할 수 있는 임의의 적절한 수단들에 의해 수행될 수 있다. 소프트웨어는 논리적 기능들을 구현하기 위한 실행 가능한 명령어들의 순서 목록(ordered listing)을 포함할 수 있고, 사용을 위해 임의의 "프로세서 판독 가능 매체"에 구현될 수 있거나 단일 또는 다중-코어 프로세서 또는 프로세서-포함 시스템과 같은, 명령어 실행 시스템, 기구(apparatus), 또는 장치와 관련하여 구현될 수 있다.
본 명세서에 개시된 실시 예들과 관련하여 설명된 방법 또는 알고리즘 또는 기능들의 블록들 또는 단계들은 프로세서에 의해 실행되는 소프트웨어 모듈, 또는 이 둘의 조합으로 직접적으로 구현될 수 있다. 소프트웨어로 구현되는 경우, 기능들은 실재하고, 비-일시적 컴퓨터-판독 가능 매체에 하나 이상의 명령어들 또는 코드로 저장되거나 전송될 수 있다. 소프트웨어 모듈은 RAM(Random Access Memory), 플래시 메모리, ROM(Read Only Memory), EPROM(Electrically Programmable ROM), EEPROM(Electrically Erasable Programmable ROM), 레지스터들, 하드 디스크, 이동식 디스크, CD ROM, 또는 당 업계에 공지된 임의의 다른 형태의 스토리지 매체에 속할(또는 저장될) 수 있다.
예시된 실시 예들을 참조하여 설명된 본 개시의 기술적 사상의 원칙들을 가지면, 도시된 실시 예들이 이러한 원칙들로부터 멀어지지 않으면서 배열 및 상세에서 수정될 수 있고 필요한 임의의 방법으로 조합될 수 있음이 이해될 것이다. 앞선 설명이 구체적인 실시 예들에 집중하였지만, 다른 구성들 또한 고려된다. 구체적으로, "본 개시의 기술적 사상의 실시 예에 따른"과 같은 설명들 또는 여기에 사용된 유사한 것들에 불구하고, 이러한 문구들은 일반적으로 실시 예의 가능성들을 참조하며, 본 개시의 기술적 사상을 구체적인 실시 예의 구성들로 한정하는 것을 의도하지 않는다. 여기에 사용되는 바와 같이, 이러한 용어들은 다른 실시 예들로 조합 가능한 동일한 또는 상이한 실시 예들을 참조할 수 있다.
앞서 설명된 실시 예들은 본 개시의 기술적 사상을 그것들로 한정하는 것으로 해석되지 않는다. 적은 실시 예들만이 설명되었지만, 이 분야에 숙련된 자들은 본 기재의 신규한 설명들 및 장점들로부터 실질적으로 멀어지지 않으면서 이러한 실시 예들에 많은 수정들이 가능함을 충분히 이해할 것이다. 따라서, 이러한 모든 수정들은 청구항들에서 정의되는 바와 같이 본 개시의 기술적 사상의 범위 내에 포함되는 것으로 의도된다.
본 개시의 실시 예들은 제한 없이, 다음의 설명으로 확장될 수 있다:
스테이트먼트(statement) 1. 본 개시의 실시 예는 솔리드 스테이트 드라이브(SSD)를 포함하고, 상기 SSD는:
복수의 블록들로 구성되는, 데이터를 위한 플래시 스토리지;
상기 플래시 스토리지로부터 데이터 읽기 및 상기 플래시 스토리지에 데이터 쓰기를 관리하는 컨트롤러;
상기 SSD(Solid State Drive)에서의 에러들에 대한 장치-기반 로그 데이터를 저장하는 메타데이터 스토리지; 및
상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 의심(suspect) 블록을 식별하도록 구성되는 식별(identification) 회로를 포함한다.
스테이트먼트 2. 본 개시의 실시 예는 스테이트먼트 1에 따른 상기 SSD를 포함하고, 상기 메타데이터 스토리지는 상기 SSD에서의 가장 최근의 상기 에러들의 세트(set)만을 위한 장치-기반 로그 데이터를 저장한다.
스테이트먼트 3. 본 개시의 실시 예는 스테이트먼트 2에 따른 SSD를 포함하고, 새로운 에러가 발생하면 장치-기반 로그 데이터에서 가장 오래된 엔트리는 폐기된다.
스테이트먼트 4. 본 개시의 실시 예는 스테이트먼트 2에 따른 SSD를 포함하고, 상기 SSD는
상기 메타데이터 스토리지는 상기 SSD에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하도록 더 구성되고; 그리고
상기 SSD는 검증(verification) 회로를 더 포함하고, 상기 검증 회로는 정확한 블록-기반 데이터 및 장치-기반 로그 데이터 모두에 응답하여 의심 블록이 고장 날 것으로 예상되는지 여부를 결정하기 위해 구성된다.
스테이트먼트 5. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 검증 회로는 상기 의심 블록에 대해서만 실행된다.
스테이트먼트 6. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 검증 회로는 상기 의심 블록을 제외한 복수의 블록들 중 임의의 블록에 대해 실행되지 않는다.
스테이트먼트 7. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 응답하여 상기 의심 블록을 폐기하도록 구성된다.
스테이트먼트 8. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 정확한 블록-기반 데이터는 상기 복수의 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 9. 본 개시의 실시 예는 스테이트먼트 8에 따른 상기 SSD를 포함하고, 상기 복수의 블록들 중에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터들은 상기 복수의 블록들의 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터 및 소거 에러 카운터를 포함한다.
스테이트먼트 10. 본 개시의 실시 예는 스테이트먼트 8에 따른 상기 SSD를 포함하고, 상기 정확한 블록-기반 데이터는 상기 SSD가 제조된 이후 복수의 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 11. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터와 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 구현한다.
스테이트먼트 12. 본 개시의 실시 예는 스테이트먼트 4에 따른 상기 SSD를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터 및 상기 정확한 블록-기반 데이터 모두에 응답하여 상기 복수의 블록들에서 의심 블록을 식별하도록 구성된다.
스테이트먼트 13. 본 개시의 실시 예는 스테이트먼트 2에 따른 상기 SSD를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하도록 구성된다.
스테이트먼트 14. 본 개시의 실시 예는 스테이트먼트 13에 따른 SSD를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터로서 상기 근사 블록-기반 데이터를 결정하도록 구성된다.
스테이트먼트 15. 본 개시의 실시 예는 스테이트먼트 2에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 16. 본 개시의 실시 예는 스테이트먼트 15에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 시간 간격으로 실행하도록 구성된다.
스테이트먼트 17. 본 개시의 실시 예는 스테이트먼트 15에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 개수의 에러들이 발생한 이후 실행하도록 구성된다.
스테이트먼트 18. 본 개시의 실시 예는 솔리드 스테이트 드라이브(SSD)를 포함하고, 상기 SSD는:
복수의 블록들로 구성되는, 데이터를 위한 플래시 스토리지;
상기 플래시 스토리지로부터 데이터 읽기 및 상기 플래시 스토리지에 데이터 쓰기를 관리하는 컨트롤러;
SSD의 에러들에 대한 정확한 블록-기반 데이터를 저장하는 메타데이터 스토리지; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하도록 구성된 식별 회로를 포함한다.
스테이트먼트 19. 본 개시의 실시 예는 스테이트먼트 18에 따른 상기 SSD를 포함하고, 상기 식별 회로는 상기 정확한 블록-기반 데이터에서 상기 의심 블록에 대한 총 에러 카운트에 응답하여 상기 의심 블록을 식별하도록 구성된다.
스테이트먼트 20. 본 개시의 실시 예는 스테이트먼트 18에 따른 상기 SSD를 포함하고, 상기 정확한 블록-기반 데이터는 상기 복수의 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 21. 본 개시의 실시 예는 스테이트먼트 20에 따른 상기 SSD를 포함하고, 상기 복수의 블록들 중에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터들은 상기 복수의 블록들의 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터 및 소거 에러 카운터를 포함한다.
스테이트먼트 22. 본 개시의 실시 예는 스테이트먼트 21에 따른 상기 SSD를 포함하고, 상기 식별 회로는 상기 의심 블록에 대한 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터로부터 총 에러 카운트를 계산하고 상기 총 에러 카운터를 임계값과 비교하도록 구성된다.
스테이트먼트 23. 본 개시의 실시 예는 스테이트먼트 18에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 24. 본 개시의 실시 예는 스테이트먼트 23에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 시간 간격으로 실행하도록 구성된다.
스테이트먼트 25. 본 개시의 실시 예는 스테이트먼트 23에 따른 상기 SSD를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 개수의 에러들이 발생한 이후 실행하도록 구성된다.
스테이트먼트 26. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은:
복수의 블록들을 포함하는 SSD(Solid State Drive)에서 에러들을 추적하는 단계;
상기 SSD에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계; 및
상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계를 포함한다.
스테이트먼트 27. 본 개시의 실시 예는 스테이트먼트 26에 따른 상기 방법을 포함하고, 상기 SSD에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계는, 상기 SSD에서의 가장 최근 상기 에러들의 세트만을 위한 상기 장치-기반 로그 데이터를 저장하는 단계를 포함한다.
스테이트먼트 28. 본 개시의 실시 예는 스테이트먼트 27에 따른 상기 방법을 포함하고, 여기서 상기 SSD의 상기 에러들에 관한 장치-기반 로그 데이터를 저장하는 단계는, 상기 SSD에서 새로운 에러가 발생한 때 상기 장치-기반 로그 데이터에서 가장 오래된 엔트리를 폐기하는 단계를 더 포함한다.
스테이트먼트 29. 본 개시의 실시 예는 스테이트먼트 27에 따른 상기 방법을 포함하고:
상기 SSD에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 및
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 더 포함한다.
스테이트먼트 30. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록이 의심 블록만을 위한 상기 정확한 블록-기반 데이터 및 상기 장치-기반 데이터 모두에 응답하여 고장 날 것으로 예측되는지 여부를 결정하는 포함한다.
스테이트먼트 31. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 고장 날 것으로 예측되는지 여부를 결정하는 단계는 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 32. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 적어도 부분적으로 기반하여 상기 의심 블록을 폐기하는 단계를 더 포함한다.
스테이트먼트 33. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 SSD의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는, 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 34. 본 개시의 실시 예는 스테이트먼트 33에 따른 상기 방법을 포함하고, 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 복수의 블록들 중 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 35. 본 개시의 실시 예는 스테이트먼트 33에 따른 상기 방법을 포함하고, 여기에서 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 상기 카운터들을 저장하는 단계는, 상기 SSD가 제조된 이후 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 36. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 37. 본 개시의 실시 예는 스테이트먼트 29에 따른 상기 방법을 포함하고, 상기 의심 블록이 정확한 블록-기반 데이터 및 장치-기반 로그 데이터 모두에 응답하여 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 38. 본 개시의 실시 예는 스테이트먼트 27에 따른 상기 방법을 포함하고, 상기 장치-기반 로그에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계는 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 39. 본 개시의 실시 예는 스테이트먼트 38에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계는 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 40. 본 개시의 실시 예는 스테이트먼트 27에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 41. 본 개시의 실시 예는 스테이트먼트 40에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 복수의 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 42. 본 개시의 실시 예는 스테이트먼트 40에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 43. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은: 복수의 블록들을 포함하는 SSD(Solid State Drive)에서 에러들을 추적하는 단계;
상기 SSD에서의 상기 에러들에 대한 정확한 장치-기반 데이터를 저장하는 단계; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계를 포함한다.
스테이트먼트 44. 본 개시의 실시 예는 스테이트먼트 43에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 45. 본 개시의 실시 예는 스테이트먼트 44에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 상기 총 에러 카운트를 계산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산하는 단계를 포함한다.
스테이트먼트 46. 본 개시의 실시 예는 스테이트먼트 43에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 47. 본 개시의 실시 예는 스테이트먼트 46에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 48. 본 개시의 실시 예는 스테이트먼트 46에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 49. 본 개시의 실시 예는 장치(또는 물품(article))를 포함하고, 장치 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
복수의 블록들을 포함하는 SSD(Solid State Drive)에서 에러들을 추적하는 단계;
상기 SSD에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계; 그리고
상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 의심(suspect) 블록을 식별하는 단계를 수행하는 것을 야기한다.
스테이트먼트 50. 본 개시의 실시 예는 스테이트먼트 49에 따른 상기 장치를 포함하고, 상기 SSD에서의 상기 에러들에 대한 상기 장치-기반 로그 데이터를 저장하는 단계는 상기 SSD에서의 가장 최근의 상기 에러들의 세트만을 위한 상기 장치-기반 로그 데이터를 저장하는 단계를 포함한다.
스테이트먼트 51. 본 개시의 실시 예는 스테이트먼트 50에 따른 상기 장치를 포함하고, 상기 SSD의 상기 에러들에 관한 장치-기반 로그 데이터를 저장하는 단계는 상기 SSD에서 새로운 에러가 발생한 때 상기 장치-기반 로그 데이터에서 가장 오래된 엔트리를 폐기하는 단계를 더 포함한다.
스테이트먼트 52. 본 개시의 실시 예는 스테이트먼트 50에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 추가 명령어들을 더 포함하고, 상기 추기 명령어들은, 상기 머신에 의해 실행될 때:
상기 SSD에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 그리고
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 수행하는 것을 야기한다.
스테이트먼트 53. 본 개시의 실시 예는 스테이트먼트 52에 따른 상기 장치를 포함하고, 정확한 블록-기반 데이터 및 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록만을 위한 상기 정확한 블록-기반 데이터 및 상기 장치-기반 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 54. 본 개시의 실시 예는 스테이트먼트 52에 따른 상기 장치를 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 55. 본 개시의 실시 예는 스테이트먼트 52에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 추가 명령어들을 더 포함하고, 상기 추기 명령어들은, 상기 머신에 의해 실행될 때 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 적어도 부분적으로 기반하여 상기 의심 블록을 폐기하는 단계를 수행하도록 야기한다.
스테이트먼트 56. 본 개시의 실시 예는 스테이트먼트 52에 따른 상기 장치를 포함하고, 상기 SSD의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 57. 본 개시의 실시 예는 스테이트먼트 56에 따른 상기 장치를 포함하고, 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는 상기 복수의 블록들 중 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 58. 본 개시의 실시 예는 스테이트먼트 56에 따른 상기 장치를 포함하고, 여기에서 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 상기 카운터들을 저장하는 단계는 상기 SSD가 제조된 이후 상기 복수의 블록들 중 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 59. 본 개시의 실시 예는 스테이트먼트 52에 따른 상기 장치를 포함하고, 여기서 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 60. 본 개시의 실시 예는 스테이트먼트 52에 따른 장치를 포함하고, 여기에서 정확한 블록-기반 데이터 및 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 61. 본 개시의 실시 예는 스테이트먼트 50에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계는 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 62. 본 개시의 실시 예는 스테이트먼트 61에 따른 상기 장치를 포함하고, 근사 블록-기반 데이터를 상기 장치-기반 로그 데이터로부터 유도하는 단계는 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 63. 본 개시의 실시 예는 스테이트먼트 50에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 추가 명령어들을 더 포함하고, 상기 추기 명령어들은, 상기 머신에 의해 실행될 때, 상기 장치-기반 로그 데이터에 응답하여 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 64. 본 개시의 실시 예는 스테이트먼트 63에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는 일정한 시간 간격으로 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 65. 본 개시의 실시 예는 스테이트먼트 63에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는 일정한 개수의 에러들이 발생한 이후 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 66. 본 개시의 실시 예는 장치를 포함하고, 장치는 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
복수의 블록들을 포함하는 SSD(Solid State Drive)에서 에러들을 추적하는 단계;
상기 SSD에서의 상기 에러들에 대한 정확한 장치-기반 로그 데이터를 저장하는 단계; 및
상기 정확한 블록-기반 로그 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 67. 본 개시의 실시 예는 스테이트먼트 66에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 복수의 블록들 중 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 68. 본 개시의 실시 예는 스테이트먼트 67에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 총 에러 카운트를 계산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산하는 단계를 포함한다.
스테이트먼트 69. 본 개시의 실시 예는 스테이트먼트 66에 따른 상기 장치를 포함하고, 비-일시적인 스토리지 매체는 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 추가 명령어들을 더 포함하고, 상기 추기 명령어들은, 상기 머신에 의해 실행될 때, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 70. 본 개시의 실시 예는 스테이트먼트 69에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는 일정한 시간 간격으로 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 71. 본 개시의 실시 예는 스테이트먼트 69에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 대해 응답하여 상기 복수의 블록들 중 새로운 의심 블록을 주기적으로 식별하는 단계는 일정한 개수의 에러들이 발생한 이후 상기 복수의 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 72. 본 개시의 실시 예는 스토리지 장치를 포함하고, 스토리지 장치는:
적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체;
적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체;
상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체로부터의 데이터 읽기 및 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 데이터 쓰기를 관리하는 컨트롤러;
상기 스토리지 장치의 에러들에 대한 장치-기반 로그 데이터를 저장하는 메타데이터 스토리지, 상기 장치-기반 로그 데이터는 상기 제 1 스토리지 매체에 대한 제 1 로그 데이터 및 상기 제 2 스토리지 매체에 대한 제 2 로그 데이터를 포함함; 및
상기 장치-기반 로그 데이터에 응답하여 상기 적어도 2 개의 제 1 블록들 및 상기 적어도 2 개의 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함한다.
스테이트먼트 73. 본 개시의 실시 예는 스테이트먼트 72에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 74. 본 개시의 실시 예는 스테이트먼트 72에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 제 1 에러 특성을 포함하고; 그리고
상기 제 2 스토리지 유형은 제 2 에러 특성을 포함하고,
상기 제 1 에러 특성 및 상기 제2 에러 특성은 서로 다르다.
스테이트먼트 75. 본 개시의 실시 예는 스테이트먼트 72에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 76. 본 개시의 실시 예는 스테이트먼트 72에 따른 상기 스토리지 장치를 포함하고, 상기 장치-기반 로그 데이터는:
상기 스토리지 장치의 상기 제 1 스토리지 매체에서의 제 1 가장 최근의 에러들의 세트; 및
상기 스토리지 장치의 상기 제 2 스토리지 매체에서의 제 2 가장 최근의 에러들의 세트를 포함한다.
스테이트먼트 77. 본 개시의 실시 예는 스테이트먼트 76에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체에서의 제 1 가장 최근의 에러들의 세트는 에러들의 제 1 개수를 포함하고; 그리고
상기 제 2 스토리지 매체에서의 제 2 가장 최근의 에러들의 세트는 에러들의 제 2 개수를 포함한다.
스테이트먼트 78. 본 개시의 실시 예는 스테이트먼트 77에 따른 상기 스토리지 장치를 포함하고, 상기 에러들의 제 1 개수 및 상기 에러들의 제 2 개수는 상기 제 1 스토리지 매체의 제 1 용량 및 상기 제 2 스토리지 매체의 제 2 용량에 비례한다.
스테이트먼트 79. 본 개시의 실시 예는 스테이트먼트 77에 따른 상기 스토리지 장치를 포함하고, 상기 에러들의 제 1 개수 및 상기 에러들의 제 2 개수는 상기 제 1 스토리지 매체의 블록들의 제 1 개수 및 상기 제 2 스토리지 매체의 블록들의 제 2 개수에 비례한다.
스테이트먼트 80. 본 개시의 실시 예는 스테이트먼트 76에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서의 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리는 폐기되고;
상기 제 2 스토리지 매체에서 제 2 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 2 스토리지 매체에서의 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리는 폐기된다.
스테이트먼트 81. 본 개시의 실시 예는 스테이트먼트 76에 따른 상기 스토리지 장치를 포함하고,
상기 메타데이터 스토리지는 상기 스토리지 장치의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하도록 더 구성되고; 그리고
상기 정확한 블록-기반 데이터와 상기 장치-기반 로그 데이터 모두에 응답하여, 상기 스토리지 장치는 의심되는 블록이 고장 날 것으로 예측되는지 여부를 결정하도록 구성된 검증 회로를 더 포함한다.
스테이트먼트 82. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델을 포함한다.
스테이트먼트 83. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록과 연관된 선택된 스토리지 유형을 고려할 수 있는 모델을 포함한다.
스테이트먼트 84. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록에 대해서만 실행된다.
스테이트먼트 85. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록 이외의 제 1 블록들 또는 제 2 블록들 중 임의의 블록에 대해 실행되지 않는다.
스테이트먼트 86. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 응답하여, 상기 의심 블록을 폐기하도록 구성된다.
스테이트먼트 87. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 88. 본 개시의 실시 예는 스테이트먼트 87에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 포함한다.
스테이트먼트 89. 본 개시의 실시 예는 스테이트먼트 87에 따른 상기 스토리지 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 포함한다.
스테이트먼트 90. 본 개시의 실시 예는 스테이트먼트 87에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터를 포함한다.
스테이트먼트 91. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 구현한다.
스테이트먼트 92. 본 개시의 실시 예는 스테이트먼트 81에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터와 상기 정확한 블록-기반 데이터 모두에 응답하여, 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하도록 구성된다.
스테이트먼트 93. 본 개시의 실시 예는 스테이트먼트 76에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터로부터 근사 블록 기반 데이터를 유도하도록 구성된다.
스테이트먼트 94. 본 개시의 실시 예는 스테이트먼트 93에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터로서 상기 근사 블록-기반 데이터를 결정하도록 구성된다.
스테이트먼트 95. 본 개시의 실시 예는 스테이트먼트 94에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터로서 상기 근사 블록-기반 데이터를 결정하도록 구성되며, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 96. 본 개시의 실시 예는 스테이트먼트 76에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 97. 본 개시의 실시 예는 스테이트먼트 96에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 일정한 시간 간격으로 상기 식별 회로를 실행하도록 구성된다.
스테이트먼트 98. 본 개시의 실시 예는 스테이트먼트 96에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 일정한 개수의 에러들이 발생한 이후 상기 식별 회로를 실행하도록 구성된다.
스테이트먼트 99. 본 개시의 실시 예는 스토리지 장치를 포함하고, 상기 스토리지 장치는:
적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체;
적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체;
상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체로부터의 데이터 읽기 및 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 데이터 쓰기를 관리하는 컨트롤러;
상기 스토리지 장치의 에러들에 대한 정확한 블록-기반 데이터를 저장하는 메타데이터 저장소, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함한다.
스테이트먼트 100. 본 개시의 실시 예는 스테이트먼트 99에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 101. 본 개시의 실시 예는 스테이트먼트 99에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 102. 본 개시의 실시 예는 스테이트먼트 99에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 정확한 블록-기반 데이터에서 상기 의심 블록에 대한 총 에러 카운트에 응답하여 상기 의심 블록을 식별하도록 구성된다.
스테이트먼트 103. 본 개시의 실시 예는 스테이트먼트 99에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 104. 본 개시의 실시 예는 스테이트먼트 103에 따른 상기 스토리지 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터들은 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터 및 소거 에러 카운터를 포함한다.
스테이트먼트 105. 본 개시의 실시 예는 스테이트먼트 104에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 의심 블록에 대한 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터로부터 총 에러 카운트를 계산하고 상기 총 에러 카운터를 임계값과 비교하도록 구성된다.
스테이트먼트 106. 본 개시의 실시 예는 스테이트먼트 99에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 107. 본 개시의 실시 예는 스테이트먼트 106에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 시간 간격으로 실행하도록 구성된다.
스테이트먼트 108. 본 개시의 실시 예는 스테이트먼트 106에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 개수의 에러들이 발생한 이후 실행하도록 구성된다.
스테이트먼트 109. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지 장치에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계, 상기 장치-기반 로그 데이터는 상기 제 1 스토리지 매체에 대한 제 1 로그 데이터 및 상기 제 2 스토리지 매체에 대한 제 2 로그 데이터를 포함함; 및
상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 포함한다.
스테이트먼트 110. 본 개시의 실시 예는 스테이트먼트 109에 따른 상기 방법을 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 111. 본 개시의 실시 예는 스테이트먼트 109에 따른 상기 방법을 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 112. 본 개시의 실시 예는 스테이트먼트 109에 따른 상기 방법을 포함하고,
상기 스토리지 장치에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계는:
상기 스토리지 장치에서의 상기 제 1 스토리지 매체의 제 1 가장 최근의 에러들의 세트를 저장하는 단계; 및
상기 스토리지 장치에서의 상기 제 2 스토리미 매체의 제 2 가장 최근의 에러들의 세트를 저장하는 단계를 포함한다.
스테이트먼트 113. 본 개시의 실시 예는 스테이트먼트 112에 따른 상기 방법을 포함하고,
상기 스토리지 장치의 상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리를 폐기하는 단계; 그리고
상기 스토리지 장치의 상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 2 스토리지 매체에 제 2 새로운 에러가 발생할 때 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리를 폐기하는 단계를 포함한다.
스테이트먼트 114. 본 개시의 실시 예는 스테이트먼트 112에 따른 상기 방법을 포함하고,
상기 스토리지 장치에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 그리고
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 더 포함한다.
스테이트먼트 115. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하기 위해 모델을 선택하는 단계를 포함하고, 상기 모델은 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델 중 적어도 하나이다.
스테이트먼트 116. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록과 관련된 선택된 스토리지 유형을 고려하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 117. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 스토리지 장치에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계는:
상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터를 저장하는 단계; 그리고
상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 저장하는 단계를 포함한다.
스테이트먼트 118. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 제 1 스토리지 유형 및 제 2 스토리지 유형 중 선택된 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 상기 의심 블록과 연관된다.
스테이트먼트 119. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 의심 블록만에 대한 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 120. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 의심 블록이 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들 내의 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 121. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 적어도 부분적으로 기초하여 의심 블록을 폐기하는 단계를 더 포함한다.
스테이트먼트 122. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 스토리지 장치에서의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 123. 본 개시의 실시 예는 스테이트먼트 122에 따른 상기 방법을 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 124. 본 개시의 실시 예는 스테이트먼트 122에 따른 상기 방법을 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 125. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 126. 본 개시의 실시 예는 스테이트먼트 114에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 127. 본 개시의 실시 예는 스테이트먼트 112에 따른 상기 방법을 포함하고, 상기 장치-기반 로그에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 128. 본 개시의 실시 예는 스테이트먼트 127에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계는 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 129. 본 개시의 실시 예는 스테이트먼트 128에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계는 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 130. 본 개시의 실시 예는 스테이트먼트 112에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 131. 본 개시의 실시 예는 스테이트먼트 130에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 132. 본 개시의 실시 예는 스테이트먼트 130에 따른 상기 방법을 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 133. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지에서의 상기 에러들에 대한 정확한 블록-기반 데이터를 저장하는 단계, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 포함한다.
스테이트먼트 134. 본 개시의 실시 예는 스테이트먼트 133에 따른 상기 방법을 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 135. 본 개시의 실시 예는 스테이트먼트 133에 따른 상기 방법을 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 136. 본 개시의 실시 예는 스테이트먼트 133에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 137. 본 개시의 실시 예는 스테이트먼트 136에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 총 에러 카운트를 연산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산(totaling)하는 단계를 포함한다.
스테이트먼트 138. 본 개시의 실시 예는 스테이트먼트 136에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 139. 본 개시의 실시 예는 스테이트먼트 138에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 140. 본 개시의 실시 예는 스테이트먼트 138에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 141. 본 개시의 실시 예는 장치를 포함하고, 장치는 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계, 상기 장치-기반 로그 데이터는 상기 제 1 스토리지 매체에 대한 제 1 로그 데이터 및 상기 제 2 스토리지 매체에 대한 제 2 로그 데이터를 포함함; 및
상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 142. 본 개시의 실시 예는 스테이트먼트 141에 따른 상기 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 143. 본 개시의 실시 예는 스테이트먼트 141에 따른 상기 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 144. 본 개시의 실시 예는 스테이트먼트 141에 따른 상기 장치를 포함하고, 상기 스토리지에서의 상기 에러들에 대한 장치-기반 로그 데이터를 저장하는 단계는:
상기 스토리지 장치에서의 상기 제 1 스토리지 매체의 제 1 가장 최근의 에러들의 세트를 저장하는 단계; 및
상기 스토리지 장치에서의 상기 제 2 스토리미 매체의 제 2 가장 최근의 에러들의 세트를 저장하는 단계를 포함한다.
스테이트먼트 145. 본 개시의 실시 예는 스테이트먼트 144에 따른 상기 장치를 포함하고,
상기 스토리지 장치의 상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리를 폐기하는 단계; 그리고
상기 스토리지 장치의 상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 2 스토리지 매체에 제 2 새로운 에러가 발생할 때 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리를 폐기하는 단계를 포함한다.
스테이트먼트 146. 본 개시의 실시 예는 스테이트먼트 144에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
상기 스토리지 장치에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 그리고
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 수행하도록 야기한다.
스테이트먼트 147. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하기 위해 모델을 선택하는 단계를 포함하고, 상기 모델은 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델 중 적어도 하나이다.
스테이트먼트 148. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록과 관련된 선택된 스토리지 유형을 고려하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 149. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 스토리지 장치의 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계는:
상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터를 저장하는 단계; 그리고
상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 저장하는 단계를 포함한다.
스테이트먼트 150. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 제 1 스토리지 유형 및 제 2 스토리지 유형 중 선택된 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 상기 의심 블록과 연관된다.
스테이트먼트 151. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 의심 블록만에 대한 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 152. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들 내의 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 153. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 적어도 부분적으로 기초하여 의심 블록을 폐기하는 단계를 수행하도록 야기한다.
스테이트먼트 154. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 스토리지 장치에서의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 155. 본 개시의 실시 예는 스테이트먼트 154에 따른 상기 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 156. 본 개시의 실시 예는 스테이트먼트 154에 따른 상기 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 157. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 158. 본 개시의 실시 예는 스테이트먼트 146에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 장치-기반 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 159. 본 개시의 실시 예는 스테이트먼트 144에 따른 상기 장치를 포함하고, 상기 장치-기반 로그에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는, 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 160. 본 개시의 실시 예는 스테이트먼트 159에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계는, 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 161. 본 개시의 실시 예는 스테이트먼트 160에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계는 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 162. 본 개시의 실시 예는 스테이트먼트 144에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 163. 본 개시의 실시 예는 스테이트먼트 162에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 164. 본 개시의 실시 예는 스테이트먼트 162에 따른 상기 장치를 포함하고, 상기 장치-기반 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 165. 본 개시의 실시 예는 장치를 포함하고, 장치는 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지에서의 상기 에러들에 대한 정확한 블록-기반 데이터를 저장하는 단계, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 166. 본 개시의 실시 예는 스테이트먼트 165에 따른 상기 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 167. 본 개시의 실시 예는 스테이트먼트 165에 따른 상기 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 168. 본 개시의 실시 예는 스테이트먼트 165에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 169. 본 개시의 실시 예는 스테이트먼트 168에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 총 에러 카운트를 연산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산(totaling)하는 단계를 포함한다.
스테이트먼트 170. 본 개시의 실시 예는 스테이트먼트 165에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 171. 본 개시의 실시 예는 스테이트먼트 170에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 172. 본 개시의 실시 예는 스테이트먼트 170에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 173. 본 개시의 실시 예는 스토리지 장치를 포함하고,
적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체;
적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체;
상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체로부터의 데이터 읽기 및 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 데이터 쓰기를 관리하는 컨트롤러;
상기 스토리지 장치의 에러들에 대한 장치-기반 로그 데이터를 저장하는 메타데이터 스토리지, 상기 장치-기반 로그 데이터는 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 대한 통합 로그 데이터를 포함함; 및
상기 통합 로그 데이터에 응답하여 상기 적어도 2 개의 제 1 블록들 및 상기 적어도 2 개의 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
스테이트먼트 174. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 제 1 에러 특성을 포함하고; 그리고
상기 제 2 스토리지 유형은 제 2 에러 특성을 포함하고,
상기 제 1 에러 특성 및 상기 제2 에러 특성은 서로 다르다.
스테이트먼트 175. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 176. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체의 크기는 상기 제 1 스토리지 매체의 제 1 용량을 포함하고;
상기 제 2 스토리지 매체의 크기는 상기 제 2 스토리지 매체의 제 2 용량을 포함하고; 그리고
상기 스토리지 장치의 크기는 상기 스토리지 장치의 전체 용량을 포함한다.
스테이트먼트 177. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체의 크기는 상기 제 1 스토리지 매체의 블록들의 제 1 개수를 포함하고;
상기 제 2 스토리지 매체의 크기는 상기 제 2 스토리지 매체의 블록들의 제 2 개수를 포함하고; 그리고
상기 스토리지 장치의 크기는 상기 스토리지 장치의 전체 블록들의 개수를 포함한다.
스테이트먼트 178. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 가중치를 적용하고, 그리고
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 상기 가중치를 적용한다.
스테이트먼트 179. 본 개시의 실시 예는 스테이트먼트 178에 따른 상기 스토리지 장치를 포함하고, 상기 가중치는 상기 스토리지 장치에 대한 쓰기 동작들의 통합 파라미터에 대한 제 1 상대적 기여도 또는 상기 스토리지 장치에 대한 읽기 동작들의 통합 파라미터에 대한 제 2 상대적 기여도 중 적어도 하나를 포함한다.
스테이트먼트 180. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고, 상기 메타데이터 스토리지는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수, 상기 제 1 스토리지 매체로부터의 읽기 동작들의 제 2 개수, 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수, 상기 제 2 스토리지 매체로부터의 읽기 동작들의 제 4 개수를 저장한다.
스테이트먼트 181. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 182. 본 개시의 실시 예는 스테이트먼트 173에 따른 상기 스토리지 장치를 포함하고, 상기 통합 로그 데이터는:
상기 스토리지 장치의 상기 제 1 스토리지 매체에서의 제 1 가장 최근의 에러들의 세트; 및
상기 스토리지 장치의 상기 제 2 스토리지 매체에서의 제 2 가장 최근의 에러들의 세트를 포함한다.
스테이트먼트 183. 본 개시의 실시 예는 스테이트먼트 182에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체에서의 제 1 가장 최근의 에러들의 세트는 에러들의 제 1 개수를 포함하고; 그리고
상기 제 2 스토리지 매체에서의 제 2 가장 최근의 에러들의 세트는 에러들의 제 2 개수를 포함한다.
스테이트먼트 184. 본 개시의 실시 예는 스테이트먼트 183에 따른 상기 스토리지 장치를 포함하고, 상기 에러들의 제 1 개수 및 상기 에러들의 제 2 개수는 상기 제 1 스토리지 매체의 제 1 용량 및 상기 제 2 스토리지 매체의 제 2 용량에 비례한다.
스테이트먼트 185. 본 개시의 실시 예는 스테이트먼트 183에 따른 상기 스토리지 장치를 포함하고, 상기 에러들의 제 1 개수 및 상기 에러들의 제 2 개수는 상기 제 1 스토리지 매체의 블록들의 제 1 개수 및 상기 제 2 스토리지 매체의 블록들의 제 2 개수에 비례한다.
스테이트먼트 186. 본 개시의 실시 예는 스테이트먼트 182에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서의 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리는 폐기되고;
상기 제 2 스토리지 매체에서 제 2 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 2 스토리지 매체에서의 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리는 폐기된다.
스테이트먼트 187. 본 개시의 실시 예는 스테이트먼트 182에 따른 상기 스토리지 장치를 포함하고,
상기 메타데이터 스토리지는 상기 스토리지 장치의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하도록 더 구성되고; 그리고
상기 정확한 블록-기반 데이터와 상기 통합 로그 데이터 모두에 응답하여, 상기 스토리지 장치는 의심되는 블록이 고장 날 것으로 예측되는지 여부를 결정하도록 구성된 검증 회로를 더 포함한다.
스테이트먼트 188. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델을 포함한다.
스테이트먼트 189. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록과 연관된 선택된 스토리지 유형을 고려할 수 있는 모델을 포함한다.
스테이트먼트 190. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록에 대해서만 실행된다.
스테이트먼트 191. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 의심 블록 이외의 제 1 블록들 또는 제 2 블록들 중 임의의 블록에 대해 실행되지 않는다.
스테이트먼트 192. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 응답하여, 상기 의심 블록을 폐기하도록 구성된다.
스테이트먼트 193. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 194. 본 개시의 실시 예는 스테이트먼트 193에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 포함한다.
스테이트먼트 195. 본 개시의 실시 예는 스테이트먼트 193에 따른 상기 스토리지 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 포함한다.
스테이트먼트 196. 본 개시의 실시 예는 스테이트먼트 193에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터를 포함한다.
스테이트먼트 197. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 검증 회로는 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 구현한다.
스테이트먼트 198. 본 개시의 실시 예는 스테이트먼트 187에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 통합 로그 데이터와 상기 정확한 블록-기반 데이터 모두에 응답하여, 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하도록 구성된다.
스테이트먼트 199. 본 개시의 실시 예는 스테이트먼트 182에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 통합 로그 데이터로부터 근사 블록 기반 데이터를 유도하도록 구성된다.
스테이트먼트 200. 본 개시의 실시 예는 스테이트먼트 199에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 통합 로그 데이터로부터 평균 블록-기반 데이터로서 상기 근사 블록-기반 데이터를 결정하도록 구성된다.
스테이트먼트 201. 본 개시의 실시 예는 스테이트먼트 200에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터로서 상기 근사 블록-기반 데이터를 결정하도록 구성되며, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 202. 본 개시의 실시 예는 스테이트먼트 182에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 203. 본 개시의 실시 예는 스테이트먼트 202에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 일정한 시간 간격으로 상기 식별 회로를 실행하도록 구성된다.
스테이트먼트 204. 본 개시의 실시 예는 스테이트먼트 202에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 일정한 개수의 에러들이 발생한 이후 상기 식별 회로를 실행하도록 구성된다.
스테이트먼트 205. 본 개시의 실시 예는 스토리지 장치를 포함하고, 상기 스토리지 장치는:
적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체;
적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체;
상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체로부터의 데이터 읽기 및 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 데이터 쓰기를 관리하는 컨트롤러;
상기 스토리지 장치의 에러들에 대한 정확한 블록-기반 데이터를 저장하는 메타데이터 저장소, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함한다.
스테이트먼트 206. 본 개시의 실시 예는 스테이트먼트 205에 따른 상기 스토리지 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 207. 본 개시의 실시 예는 스테이트먼트 205에 따른 상기 스토리지 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 208. 본 개시의 실시 예는 스테이트먼트 205에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 정확한 블록-기반 데이터에서 상기 의심 블록에 대한 총 에러 카운트에 응답하여 상기 의심 블록을 식별하도록 구성된다.
스테이트먼트 209. 본 개시의 실시 예는 스테이트먼트 205에 따른 상기 스토리지 장치를 포함하고, 상기 정확한 블록-기반 데이터는 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 포함한다.
스테이트먼트 210. 본 개시의 실시 예는 스테이트먼트 209에 따른 상기 스토리지 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 상기 카운터들은 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터 및 소거 에러 카운터를 포함한다.
스테이트먼트 211. 본 개시의 실시 예는 스테이트먼트 209에 따른 상기 스토리지 장치를 포함하고, 상기 식별 회로는 상기 의심 블록에 대한 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터로부터 총 에러 카운트를 계산하고 상기 총 에러 카운터를 임계값과 비교하도록 구성된다.
스테이트먼트 212. 본 개시의 실시 예는 스테이트먼트 205에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 주기적으로 실행하도록 구성된다.
스테이트먼트 213. 본 개시의 실시 예는 스테이트먼트 212에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 시간 간격으로 실행하도록 구성된다.
스테이트먼트 214. 본 개시의 실시 예는 스테이트먼트 212에 따른 상기 스토리지 장치를 포함하고, 상기 SSD는 상기 식별 회로를 일정한 개수의 에러들이 발생한 이후 실행하도록 구성된다.
스테이트먼트 215. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지 장치의 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에서의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계; 및
상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 포함하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
스테이트먼트 216. 본 개시의 실시 예는 스테이트먼트 215에 따른 상기 방법을 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 217. 본 개시의 실시 예는 스테이트먼트 215에 따른 상기 방법을 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 218. 본 개시의 실시 예는 스테이트먼트 215에 따른 상기 방법을 포함하고,
상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여, 상기 통합 로그 데이터의 통합 파라미터로부터 상기 제 1 스토리지 매체에 대한 제 1 파라미터를 유도하는 단계, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 가중치를 적용함;
제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여, 상기 통합 로그 데이터의 상기 통합 파라미터로부터 상기 제 2 스토리지 매체에 대한 제 2 파라미터는 유도하는 단계, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 상기 가중치를 적용함을 포함한다.
스테이트먼트 219. 본 개시의 실시 예는 스테이트먼트 218에 따른 상기 방법을 포함하고, 상기 가중치는 상기 스토리지 장치에 대한 쓰기 동작들의 통합 파라미터에 대한 제 1 상대적 기여도 또는 상기 스토리지 장치에 대한 읽기 동작들의 통합 파라미터에 대한 제 2 상대적 기여도 중 적어도 하나를 포함한다.
스테이트먼트 220. 본 개시의 실시 예는 스테이트먼트 215에 따른 상기 방법을 포함하고, 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수, 상기 제 1 스토리지 매체로부터의 읽기 동작들의 제 2 개수, 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수, 상기 제 2 스토리지 매체로부터의 읽기 동작들의 제 4 개수를 저장하는 단계를 더 포함한다.
스테이트먼트 221. 본 개시의 실시 예는 스테이트먼트 215에 따른 상기 방법을 포함하고, 상기 스토리지 장치의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계는:
상기 스토리지 장치의 상기 제 1 스토리지 매체의 제 1 가장 최근의 에러들의 세트를 저장하는 단계; 및
상기 스토리지 장치의 상기 제 2 스토리지 매체의 제 2 가장 최근의 에러들의 세트를 저장하는 단계를 포함한다.
스테이트먼트 222. 본 개시의 실시 예는 스테이트먼트 221에 따른 상기 방법을 포함하고,
상기 스토리지 장치의 상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리를 폐기하는 단계; 그리고
상기 스토리지 장치의 상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 2 스토리지 매체에 제 2 새로운 에러가 발생할 때 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리를 폐기하는 단계를 포함한다.
스테이트먼트 223. 본 개시의 실시 예는 스테이트먼트 221에 따른 상기 방법을 포함하고,
상기 스토리지 장치에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 그리고
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 더 포함한다.
스테이트먼트 224. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하기 위해 모델을 선택하는 단계를 포함하고, 상기 모델은 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델 중 적어도 하나이다.
스테이트먼트 225. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록과 관련된 선택된 스토리지 유형을 고려하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 226. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 스토리지 장치의 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계는:
상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터를 저장하는 단계; 그리고
상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 저장하는 단계를 포함한다.
스테이트먼트 227. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 제 1 스토리지 유형 및 제 2 스토리지 유형 중 선택된 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 상기 의심 블록과 연관된다.
스테이트먼트 228. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 의심 블록만에 대한 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 229. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들 내의 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 230. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 적어도 부분적으로 기초하여 의심 블록을 폐기하는 단계를 더 포함한다.
스테이트먼트 231. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 스토리지 장치에서의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 232. 본 개시의 실시 예는 스테이트먼트 231에 따른 상기 방법을 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 233. 본 개시의 실시 예는 스테이트먼트 231에 따른 상기 방법을 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 234. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 235. 본 개시의 실시 예는 스테이트먼트 223에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 236. 본 개시의 실시 예는 스테이트먼트 221에 따른 상기 방법을 포함하고, 상기 통합 로그에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는, 상기 통합 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 237. 본 개시의 실시 예는 스테이트먼트 236에 따른 상기 방법을 포함하고, 상기 통합 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계는, 상기 통합 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 238. 본 개시의 실시 예는 스테이트먼트 237에 따른 상기 방법을 포함하고, 상기 통합 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계는, 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 239. 본 개시의 실시 예는 스테이트먼트 221에 따른 상기 방법을 포함하고, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 240. 본 개시의 실시 예는 스테이트먼트 239에 따른 상기 방법을 포함하고, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 241. 본 개시의 실시 예는 스테이트먼트 239에 따른 상기 방법을 포함하고, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 242. 본 개시의 실시 예는 방법을 포함하고, 상기 방법은:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지에서의 상기 에러들에 대한 정확한 블록-기반 데이터를 저장하는 단계, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 포함한다.
스테이트먼트 243. 본 개시의 실시 예는 스테이트먼트 242에 따른 상기 방법을 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 244. 본 개시의 실시 예는 스테이트먼트 242에 따른 상기 방법을 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 245. 본 개시의 실시 예는 스테이트먼트 242에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 246. 본 개시의 실시 예는 스테이트먼트 245에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 총 에러 카운트를 연산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산(totaling)하는 단계를 포함한다.
스테이트먼트 247. 본 개시의 실시 예는 스테이트먼트 242에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 더 포함한다.
스테이트먼트 248. 본 개시의 실시 예는 스테이트먼트 247에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 249. 본 개시의 실시 예는 스테이트먼트 247에 따른 상기 방법을 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 250. 본 개시의 실시 예는 장치를 포함하고, 장치는 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지 장치의 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에서의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계; 및
상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하도록 야기하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된다.
스테이트먼트 251. 본 개시의 실시 예는 스테이트먼트 250에 따른 상기 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 252. 본 개시의 실시 예는 스테이트먼트 250에 따른 상기 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 253. 본 개시의 실시 예는 스테이트먼트 250에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여, 상기 통합 로그 데이터의 통합 파라미터로부터 상기 제 1 스토리지 매체에 대한 제 1 파라미터를 유도하는 단계, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 가중치를 적용함;
제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여, 상기 통합 로그 데이터의 상기 통합 파라미터로부터 상기 제 2 스토리지 매체에 대한 제 2 파라미터는 유도하는 단계, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 상기 가중치를 적용한다.
스테이트먼트 254. 본 개시의 실시 예는 스테이트먼트 253에 따른 상기 장치를 포함하고, 상기 가중치는 상기 스토리지 장치에 대한 쓰기 동작들의 통합 파라미터에 대한 제 1 상대적 기여도 또는 상기 스토리지 장치에 대한 읽기 동작들의 통합 파라미터에 대한 제 2 상대적 기여도 중 적어도 하나를 포함한다.
스테이트먼트 255. 본 개시의 실시 예는 스테이트먼트 250에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수, 상기 제 1 스토리지 매체로부터의 읽기 동작들의 제 2 개수, 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수, 상기 제 2 스토리지 매체로부터의 읽기 동작들의 제 4 개수를 저장하는 단계를 수행하도록 야기한다.
스테이트먼트 256. 본 개시의 실시 예는 스테이트먼트 250에 따른 상기 장치를 포함하고, 상기 스토리지 장치의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계는:
상기 스토리지 장치의 상기 제 1 스토리지 매체의 제 1 가장 최근의 에러들의 세트를 저장하는 단계; 및
상기 스토리지 장치의 상기 제 2 스토리지 매체의 제 2 가장 최근의 에러들의 세트를 저장하는 단계를 포함한다.
스테이트먼트 257. 본 개시의 실시 예는 스테이트먼트 256에 따른 상기 장치를 포함하고,
상기 스토리지 장치의 상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 1 스토리지 매체에서 제 1 새로운 에러가 발생할 때 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리를 폐기하는 단계; 그리고
상기 스토리지 장치의 상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트를 저장하는 단계는, 상기 스토리지 장치의 상기 제 2 스토리지 매체에 제 2 새로운 에러가 발생할 때 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리를 폐기하는 단계를 포함한다.
스테이트먼트 258. 본 개시의 실시 예는 스테이트먼트 256에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
상기 스토리지 장치에서의 상기 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계; 그리고
상기 의심 블록이 식별되면, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 수행하도록 야기한다.
스테이트먼트 259. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하기 위해 모델을 선택하는 단계를 포함하고, 상기 모델은 상기 제 1 스토리지 유형에 대한 제 1 모델 및 상기 제 2 스토리지 유형에 대한 제 2 모델 중 적어도 하나이다.
스테이트먼트 260. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록과 관련된 선택된 스토리지 유형을 고려하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 261. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 스토리지 장치의 에러들에 관한 정확한 블록-기반 데이터를 저장하는 단계는:
상기 제 1 스토리지 매체의 에러들의 개수에 대한 제 1 카운터를 저장하는 단계; 그리고
상기 제 2 스토리지 매체의 에러들의 개수에 대한 제 2 카운터를 저장하는 단계를 포함한다.
스테이트먼트 262. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 제 1 스토리지 유형 및 제 2 스토리지 유형 중 선택된 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 상기 의심 블록과 연관된다.
스테이트먼트 263. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터와 상기 의심 블록만에 대한 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 264. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들 내의 임의의 다른 블록이 고장 날 것으로 예측되는지 여부를 결정하지 않는 단계를 포함한다.
스테이트먼트 265. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 적어도 부분적으로 기초하여 의심 블록을 폐기하는 단계를 수행하도록 야기한다.
스테이트먼트 266. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 스토리지 장치에서의 상기 에러들과 관련된 정확한 블록-기반 데이터를 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 267. 본 개시의 실시 예는 스테이트먼트 266에 따른 상기 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 저장하는 단계를 포함한다.
스테이트먼트 268. 본 개시의 실시 예는 스테이트먼트 266에 따른 상기 장치를 포함하고, 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계는, 상기 스토리지 장치가 제조된 이후 상기 제 1 블록들 및 상기 제 2 블록들에서 각 블록에 대한 에러들의 개수에 대한 카운터들을 저장하는 단계를 포함한다.
스테이트먼트 269. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터에 대해 랜덤 포레스트(Random Forest), 로지스틱 회귀(Logistic Regression), 이상점 검출(Outlier Detection), 예외 검출(Anomaly Detection) 중 하나를 적용하는 단계를 포함한다.
스테이트먼트 270. 본 개시의 실시 예는 스테이트먼트 258에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터 및 상기 통합 로그 데이터 모두에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계는, 상기 의심 블록에 대한 공간적 지역성 정보에 응답하여 상기 의심 블록이 고장 날 것으로 예측되는지 여부를 결정하는 단계를 포함한다.
스테이트먼트 271. 본 개시의 실시 예는 스테이트먼트 256에 따른 상기 장치를 포함하고, 상기 통합 로그에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는, 상기 통합 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계를 포함한다.
스테이트먼트 272. 본 개시의 실시 예는 스테이트먼트 271에 따른 상기 장치를 포함하고, 상기 통합 로그 데이터로부터 근사 블록-기반 데이터를 유도하는 단계는, 상기 통합 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계를 포함한다.
스테이트먼트 273. 본 개시의 실시 예는 스테이트먼트 272에 따른 상기 장치를 포함하고, 상기 통합 로그 데이터로부터 평균 블록-기반 데이터를 결정하는 단계는, 상기 제 1 스토리지 유형 및 상기 제 2 스토리지 유형으로부터 선택된 스토리지 유형에 대한 평균 블록-기반 데이터를 결정하는 단계를 포함하고, 상기 선택된 스토리지 유형은 의심되는 블록과 연관된다.
스테이트먼트 274. 본 개시의 실시 예는 스테이트먼트 256에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 275. 본 개시의 실시 예는 스테이트먼트 274에 따른 상기 장치를 포함하고, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 276. 본 개시의 실시 예는 스테이트먼트 274에 따른 상기 장치를 포함하고, 상기 통합 로그 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
스테이트먼트 277. 본 개시의 실시 예는 장치를 포함하고, 장치는 비일시적 스토리지 매체를 포함하되, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때:
제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하는 스토리지 장치에서 에러들을 추적하는 단계, 제 1 스토리지 유형의 상기 제 1 스토리지 매체는 적어도 2 개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 2 개의 제 2 블록들로 구성됨;
상기 스토리지에서의 상기 에러들에 대한 정확한 블록-기반 데이터를 저장하는 단계, 상기 스토리지 장치의 에러들에 대한 상기 정확한 블록-기반 데이터는 상기 제 1 스토리지 매체의 에러들의 제 1 개수에 대한 제 1 카운터 및 상기 제 2 스토리지 매체의 에러들의 제 2 개수에 대한 제 2 카운터를 포함함; 및
상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 278. 본 개시의 실시 예는 스테이트먼트 277에 따른 상기 장치를 포함하고, 상기 스토리지 장치는 SSD(Solid State Drive)를 포함한다.
스테이트먼트 279. 본 개시의 실시 예는 스테이트먼트 277에 따른 상기 장치를 포함하고,
상기 제 1 스토리지 유형은 SLC(single-level cell) 유형을 포함하고; 그리고
상기 제 2 스토리지 유형은 MLC(multi-level cell), TLC(triple level cell), QLC(quad-level cell), 또는 PLC(penta-level cell) 중 적어도 어느 하나를 포함한다.
스테이트먼트 280. 본 개시의 실시 예는 스테이트먼트 277에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제 2 블록들에서 의심 블록을 식별하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계; 및
상기 총 에러 카운트와 임계 에러 카운트를 비교하는 단계를 포함한다.
스테이트먼트 281. 본 개시의 실시 예는 스테이트먼트 277에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 총 에러 카운트를 계산하는 단계는:
상기 정확한 블록-기반 데이터로부터 상기 의심 블록에 대한 읽기 에러 카운터, 쓰기 에러 카운터, 및 소거 에러 카운터를 결정하는 단계; 및
상기 의심 블록에 대한 총 에러 카운트를 연산하기 위해 상기 읽기 에러 카운터, 상기 쓰기 에러 카운터, 및 상기 소거 에러 카운터를 합산(totaling)하는 단계를 포함한다.
스테이트먼트 282. 본 개시의 실시 예는 스테이트먼트 277에 따른 상기 장치를 포함하고, 상기 비일시적 스토리지 매체는 상기 비일시적 스토리지 매체에 저장된 명령어들을 포함하고, 상기 명령어들은, 머신에 의해 실행될 때, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계를 수행하도록 야기한다.
스테이트먼트 283. 본 개시의 실시 예는 스테이트먼트 282에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 시간 간격으로 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인(check)하는 단계를 포함한다.
스테이트먼트 284. 본 개시의 실시 예는 스테이트먼트 282에 따른 상기 장치를 포함하고, 상기 정확한 블록-기반 데이터에 응답하여 상기 제 1 블록들 및 상기 제2 블록들에서 새로운 의심 블록을 주기적으로 식별하는 단계는, 일정한 개수의 에러들이 발생한 이후 상기 제 1 블록들 및 상기 제 2 블록들을 상기 의심 블록에 대해 확인하는 단계를 포함한다.
결과적으로, 본 명세서에 설명된 실시 예들에 대한 상기 다양한 순열들의 관점에서, 이 상세한 설명 및 첨부된 자료는 단지 예시를 위해 의도된 것이고, 본 개시의 범위를 제한하는 것으로 간주되어서는 안 된다. 따라서, 본 개시로서 청구되는 것은 다음의 청구항들 및 균등물들의 범위 및 사상 내에서 올 수 있는 모든 수정들이다.
Claims (10)
- 스토리지 장치에 있어서,
적어도 2 개의 제 1 블록들로 구성되고, 제 1 데이터를 저장하는 제 1 스토리지 유형의 제 1 스토리지 매체;
적어도 2 개의 제 2 블록들로 구성되고, 제 2 데이터를 저장하는 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 제 2 스토리지 매체;
상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체로부터의 데이터 읽기 및 쓰기를 관리하는 컨트롤러;
상기 스토리지 장치의 에러에 대한 장치-기반 로그 데이터를 저장하는 메타데이터 스토리지, 에러들에 대한 상기 장치-기반 로그 데이터는 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체에 대한 통합 로그 데이터를 포함함; 및
상기 통합 로그 데이터에 응답하여 적어도 2 개의 제 1 블록들 및 적어도 2 개의 제 2 블록들에서 의심 블록을 식별하도록 구성된 식별 회로를 포함하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 제 1 스토리지 매체에 대한 읽기 동작들의 제2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된 스토리지 장치. - 제 1 항에 있어서,
상기 제 1 스토리지 유형은 제 1 에러 특성들을 포함하고; 및
상기 제 2 스토리지 유형은 제 2 에러 특성들을 포함하고,
상기 제 1 에러 특성들 및 상기 제 2 에러 특성들은 서로 다른 스토리지 장치. - 제 1 항에 있어서,
상기 메타데이터 스토리지는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 상기 제 1 개수, 상기 제 1 스토리지 매체로부터의 읽기 동작들의 상기 제 2 개수, 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 상기 제 3 개수, 및 상기 제 2 스토리지 매체로부터의 읽기 동작들의 상기 제 4 개수를 저장하는 스토리지 장치. - 제 1 항에 있어서,
상기 통합 로그 데이터는:
상기 스토리지 장치의 상기 제 1 스토리지 매체의 제 1 가장 최근의 에러들의 세트; 및
상기 스토리지 장치의 상기 제 2 스토리지 매체의 제 2 가장 최근의 에러들의 세트를 포함하는 스토리지 장치. - 제 4 항에 있어서,
상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트는 에러들의 제 1 개수를 포함하고,
상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트는 에러들의 제 2 개수를 포함하는 스토리지 장치. - 제 5 항에 있어서,
에러들의 상기 제 1 개수 및 에러들의 상기 제 2 개수는 상기 제 1 스토리지 매체의 제 1 용량 및 상기 제 2 스토리지 매체의 제 2 용량에 비례하는 스토리지 장치. - 제 4 항에 있어서,
상기 제 1 스토리지 매체의 제 1 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 1 스토리지 매체의 상기 제 1 가장 최근의 에러들의 세트에서 제 1 가장 오래된 엔트리는 폐기되고; 그리고
상기 제 2 스토리지 매체에서 제 2 새로운 에러가 발생할 때, 상기 스토리지 장치의 상기 제 2 스토리지 매체의 상기 제 2 가장 최근의 에러들의 세트에서 제 2 가장 오래된 엔트리는 폐기되는 스토리지 장치. - 스토리지 장치의 에러들을 추적하는 단계, 상기 스토리지 장치는 제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하고, 제 1 스토리지 유형의 제 1 스토리지 매체는 적어도 두개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 두개의 제 2 블록들로 구성됨;
상기 스토리지 장치의 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계; 및
상기 통합 로그 데이터에 응답하여 상기 제 1 블록들과 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 포함하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 상기 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된 방법. - 제 8 항에 있어서,
상기 제 1 스토리지 매체에 대한 쓰기 동작들의 상기 제 1 개수와 상기 제 1 스토리지 매체에 대한 읽기 동작들의 상기 제 2 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 상기 제 1 스토리지 매체에 대한 상기 제 1 파라미터를 유도하고, 상기 제 1 파라미터는 상기 스토리지 장치의 상기 쓰기 동작들의 개수 및 상기 읽기 동작들의 개수와 관련되고, 가중치를 적용하는 단계, 그리고
상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 상기 제 2 스토리지 매체에 대한 상기 제 2 파라미터를 유도하고, 상기 제 2 파라미터는 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고, 상기 가중치를 적용하는 단계를 포함하는 방법. - 비일시적 명령어들을 저장하는 비일시적 스토리지 매체를 포함하는 장치에 있어서, 상기 명령어들이 머신에 의해 실행될 때:
스토리지 장치의 에러들을 추적하는 단계, 상기 스토리지 장치는 제 1 데이터를 저장하는 제 1 스토리지 매체 및 제 2 데이터를 저장하는 제 2 스토리지 매체를 포함하고, 제 1 스토리지 유형의 제 1 스토리지 매체는 적어도 두개의 제 1 블록들로 구성되고, 상기 제 1 스토리지 유형과 다른 제 2 스토리지 유형의 상기 제 2 스토리지 매체는 적어도 두개의 제 2 블록들로 구성됨;
상기 스토리지 장치의 상기 제 1 스토리지 매체 및 상기 제 2 스토리지 매체의 상기 에러들에 대한 통합 로그 데이터를 저장하는 단계; 및
상기 통합 로그 데이터에 응답하여 상기 제 1 블록들과 상기 제 2 블록들에서 의심 블록을 식별하는 단계를 수행하고,
상기 제 1 스토리지 매체에 대한 제 1 파라미터는 상기 제 1 스토리지 매체에 대한 쓰기 동작들의 제 1 개수 및 상기 제 1 스토리지 매체에 대한 읽기 동작들의 제 2 개수에 비례하여 상기 통합 로그 데이터의 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련되고,
상기 제 2 스토리지 매체에 대한 제 2 파라미터는 상기 제 2 스토리지 매체에 대한 쓰기 동작들의 제 3 개수 및 상기 제 2 스토리지 매체에 대한 읽기 동작들의 제 4 개수에 비례하여 상기 통합 로그 데이터의 상기 통합 파라미터로부터 유도될 수 있고, 상기 스토리지 장치의 쓰기 동작들의 개수 및 읽기 동작들의 개수와 관련된 장치.
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US202063073926P | 2020-09-02 | 2020-09-02 | |
| US202063073923P | 2020-09-02 | 2020-09-02 | |
| US63/073,926 | 2020-09-02 | ||
| US63/073,923 | 2020-09-02 | ||
| US202063076370P | 2020-09-09 | 2020-09-09 | |
| US63/076,370 | 2020-09-09 | ||
| US17/093,626 | 2020-11-09 | ||
| US17/093,626 US11500753B2 (en) | 2020-09-02 | 2020-11-09 | Multi-non-volatile memory solid state drive block-level failure prediction with unified device log |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20220030188A true KR20220030188A (ko) | 2022-03-10 |
Family
ID=80356622
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020210116213A KR20220030189A (ko) | 2020-09-02 | 2021-09-01 | 불휘발성 메모리 장치마다 별도의 로그 사용하는 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 |
| KR1020210116204A KR20220030188A (ko) | 2020-09-02 | 2021-09-01 | 통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020210116213A KR20220030189A (ko) | 2020-09-02 | 2021-09-01 | 불휘발성 메모리 장치마다 별도의 로그 사용하는 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 |
Country Status (2)
| Country | Link |
|---|---|
| US (3) | US11500753B2 (ko) |
| KR (2) | KR20220030189A (ko) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11669754B2 (en) * | 2020-02-25 | 2023-06-06 | Samsung Electronics Co., Ltd. | Data management, reduction and sampling schemes for storage device failure |
| US11436072B2 (en) * | 2020-02-27 | 2022-09-06 | Hewlett Packard Enterprise Development Lp | System and method for collecting contextual log files from a computing system |
| US11500753B2 (en) * | 2020-09-02 | 2022-11-15 | Samsung Electronics Co., Ltd. | Multi-non-volatile memory solid state drive block-level failure prediction with unified device log |
| US11967388B2 (en) * | 2022-08-11 | 2024-04-23 | Western Digital Technologies, Inc. | Stress test for grown bad blocks |
| CN116719486B (zh) * | 2023-08-10 | 2023-11-17 | 杭州智灵瞳人工智能有限公司 | 一种内置数据自动传输功能的多模存储装置及控制方法 |
Family Cites Families (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7181647B2 (en) * | 2003-10-15 | 2007-02-20 | International Business Machines Corporation | Error tracking method and system |
| JP4806557B2 (ja) | 2005-10-18 | 2011-11-02 | 株式会社日立製作所 | ログを管理するストレージ装置及び計算機システム |
| US7765426B2 (en) | 2007-06-07 | 2010-07-27 | Micron Technology, Inc. | Emerging bad block detection |
| US9547589B2 (en) | 2008-06-18 | 2017-01-17 | Super Talent Technology, Corp. | Endurance translation layer (ETL) and diversion of temp files for reduced flash wear of a super-endurance solid-state drive |
| US9123422B2 (en) | 2012-07-02 | 2015-09-01 | Super Talent Technology, Corp. | Endurance and retention flash controller with programmable binary-levels-per-cell bits identifying pages or blocks as having triple, multi, or single-level flash-memory cells |
| US8891298B2 (en) | 2011-07-19 | 2014-11-18 | Greenthread, Llc | Lifetime mixed level non-volatile memory system |
| US8176367B2 (en) | 2009-05-28 | 2012-05-08 | Agere Systems Inc. | Systems and methods for managing end of life in a solid state drive |
| US8400854B2 (en) | 2009-09-11 | 2013-03-19 | Sandisk Technologies Inc. | Identifying at-risk data in non-volatile storage |
| US20110252289A1 (en) | 2010-04-08 | 2011-10-13 | Seagate Technology Llc | Adjusting storage device parameters based on reliability sensing |
| US8489979B2 (en) | 2010-05-28 | 2013-07-16 | Seagate Technology Llc | Methods and devices to reduce outer code failure rate variability |
| US8806106B2 (en) | 2010-11-12 | 2014-08-12 | Seagate Technology Llc | Estimating wear of non-volatile, solid state memory |
| US9176862B2 (en) | 2011-12-29 | 2015-11-03 | Sandisk Technologies Inc. | SLC-MLC wear balancing |
| JP2013222435A (ja) | 2012-04-19 | 2013-10-28 | Toshiba Corp | 半導体記憶装置及びその制御方法 |
| US9251019B2 (en) | 2012-05-29 | 2016-02-02 | SanDisk Technologies, Inc. | Apparatus, system and method for managing solid-state retirement |
| US9349476B2 (en) | 2013-02-21 | 2016-05-24 | Sandisk Technologies Inc. | Methods, systems, and computer readable media for early detection of potential flash failures using an adaptive system level algorithm based on flash program verify |
| US9423970B2 (en) | 2013-12-30 | 2016-08-23 | Sandisk Technologies Llc | Method and system for predicting block failure in a non-volatile memory |
| US9779015B1 (en) * | 2014-03-31 | 2017-10-03 | Amazon Technologies, Inc. | Oversubscribed storage extents with on-demand page allocation |
| US9804922B2 (en) | 2014-07-21 | 2017-10-31 | Sandisk Technologies Llc | Partial bad block detection and re-use using EPWR for block based architectures |
| US9569120B2 (en) | 2014-08-04 | 2017-02-14 | Nvmdurance Limited | Adaptive flash tuning |
| US9632854B2 (en) | 2014-11-05 | 2017-04-25 | International Business Machines Corporation | Electronic system configuration management |
| US9558847B2 (en) * | 2014-11-21 | 2017-01-31 | Sandisk Technologies Llc | Defect logging in nonvolatile memory |
| US10114584B2 (en) | 2014-12-22 | 2018-10-30 | Sandisk Technologies Llc | Removing read disturb signatures for memory analytics |
| US9710317B2 (en) | 2015-03-30 | 2017-07-18 | Netapp, Inc. | Methods to identify, handle and recover from suspect SSDS in a clustered flash array |
| US9639282B2 (en) | 2015-05-20 | 2017-05-02 | Sandisk Technologies Llc | Variable bit encoding per NAND flash cell to improve device endurance and extend life of flash-based storage devices |
| US9606737B2 (en) | 2015-05-20 | 2017-03-28 | Sandisk Technologies Llc | Variable bit encoding per NAND flash cell to extend life of flash-based storage devices and preserve over-provisioning |
| TWI599880B (zh) | 2016-03-22 | 2017-09-21 | 威盛電子股份有限公司 | 非揮發性記憶體裝置及其操作方法 |
| US10297333B2 (en) | 2016-04-08 | 2019-05-21 | Steven McConnell | Drying system and method |
| US10127125B2 (en) | 2016-10-21 | 2018-11-13 | Accenture Global Solutions Limited | Application monitoring and failure prediction |
| US9971537B1 (en) | 2016-10-26 | 2018-05-15 | Pure Storage, Inc. | Hardware support to track and transition flash LUNs into SLC mode |
| JP6386523B2 (ja) | 2016-12-15 | 2018-09-05 | ファナック株式会社 | Ｎａｎｄフラッシュメモリの寿命を予測する機械学習装置、寿命予測装置、数値制御装置、生産システム、及び機械学習方法 |
| US10325668B2 (en) | 2017-04-05 | 2019-06-18 | Micron Technology, Inc. | Operation of mixed mode blocks |
| US11049009B2 (en) | 2017-06-12 | 2021-06-29 | Western Digital Technologies, Inc. | Identifying memory block write endurance using machine learning |
| US10346232B2 (en) | 2017-08-16 | 2019-07-09 | Western Digital Technologies, Inc. | Non-volatile storage with failure prediction |
| US10387281B2 (en) | 2017-08-30 | 2019-08-20 | Micron Technology, Inc. | Flash memory block retirement policy |
| US10726930B2 (en) | 2017-10-06 | 2020-07-28 | Western Digital Technologies, Inc. | Method and system for a storage (SSD) drive-level failure and health prediction leveraging machine learning on internal parametric data |
| US10446243B2 (en) * | 2017-12-18 | 2019-10-15 | Macronix International Co., Ltd. | Storage device and associated control method to determine target memory blocks for probe operation |
| KR102524676B1 (ko) | 2017-12-21 | 2023-04-24 | 마이크론 테크놀로지, 인크. | Nand 논리 대 물리 테이블 영역 트랙킹 |
| US10802733B2 (en) | 2018-04-27 | 2020-10-13 | Western Digital Technologies, Inc. | Methods and apparatus for configuring storage tiers within SSDs |
| US10665309B2 (en) | 2018-08-21 | 2020-05-26 | Micron Technology, Inc. | Memory endurance measures based on an extrapolated function fit to metric points for a memory sub-system |
| US11069425B2 (en) | 2018-08-21 | 2021-07-20 | Intel Corporation | Multi-level memory repurposing technology to process a request to modify a configuration of a persistent storage media |
| CN109830254A (zh) | 2018-12-17 | 2019-05-31 | 武汉忆数存储技术有限公司 | 一种闪存寿命预测方法、系统、存储介质 |
| US10930365B2 (en) | 2019-02-21 | 2021-02-23 | Intel Corporation | Artificial intelligence based monitoring of solid state drives and dual in-line memory modules |
| US20200027503A1 (en) | 2019-09-27 | 2020-01-23 | Intel Corporation | Method and apparatus to improve read latency of a multi-threshold level cell block-based non-volatile memory |
| CN113821156A (zh) * | 2020-06-18 | 2021-12-21 | 桑迪士克科技有限责任公司 | 前瞻识别潜在不可校正的误差校正存储器单元和现场对策 |
| US11500753B2 (en) * | 2020-09-02 | 2022-11-15 | Samsung Electronics Co., Ltd. | Multi-non-volatile memory solid state drive block-level failure prediction with unified device log |
-
2020
- 2020-11-09 US US17/093,626 patent/US11500753B2/en active Active
- 2020-11-09 US US17/093,620 patent/US11500752B2/en active Active
-
2021
- 2021-09-01 KR KR1020210116213A patent/KR20220030189A/ko unknown
- 2021-09-01 KR KR1020210116204A patent/KR20220030188A/ko unknown
-
2022
- 2022-10-11 US US17/964,013 patent/US20230037270A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| US11500752B2 (en) | 2022-11-15 |
| US20220066683A1 (en) | 2022-03-03 |
| US20220066897A1 (en) | 2022-03-03 |
| US20230037270A1 (en) | 2023-02-02 |
| US11500753B2 (en) | 2022-11-15 |
| KR20220030189A (ko) | 2022-03-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR20220030188A (ko) | 통합 장치 로그를 사용한 복수의 불휘발성 메모리 스테이트 드라이브 블록-레벨 고장 예측 방안 | |
| CN109901788B (zh) | 存储器控制器、存储器系统及控制方法 | |
| US10049055B2 (en) | Managing asymmetric memory system as a cache device | |
| US10922235B2 (en) | Method and system for address table eviction management | |
| US9547589B2 (en) | Endurance translation layer (ETL) and diversion of temp files for reduced flash wear of a super-endurance solid-state drive | |
| US9767032B2 (en) | Systems and methods for cache endurance | |
| US8959280B2 (en) | Super-endurance solid-state drive with endurance translation layer (ETL) and diversion of temp files for reduced flash wear | |
| US8161241B2 (en) | Temperature-aware buffered caching for solid state storage | |
| US11567670B2 (en) | Firmware-based SSD block failure prediction and avoidance scheme | |
| US8775723B2 (en) | Storage system and control method of storage system | |
| US20150106557A1 (en) | Virtual Memory Device (VMD) Application/Driver for Enhanced Flash Endurance | |
| CN110928807B (zh) | 用于检查存储器系统中的有效数据的设备和方法 | |
| KR102663661B1 (ko) | 메모리 시스템 내 저장된 데이터를 제어하는 방법 및 장치 | |
| US11157402B2 (en) | Apparatus and method for managing valid data in memory system | |
| US20140047164A1 (en) | Physically Addressed Solid State Disk Employing Magnetic Random Access Memory (MRAM) | |
| US11500572B2 (en) | Method of optimizing performance of a data storage system | |
| US9842660B1 (en) | System and method to improve enterprise reliability through tracking I/O performance metrics in non-volatile random access memory | |
| US11016889B1 (en) | Storage device with enhanced time to ready performance | |
| Dayan et al. | GeckoFTL: Scalable flash translation techniques for very large flash devices | |
| US20140047161A1 (en) | System Employing MRAM and Physically Addressed Solid State Disk | |
| CN101752008B (zh) | 固态储存媒体可靠度的测试方法 | |
| Chakraborttii | Improving Performance of Solid State Drives Using Machine Learning | |
| CN112711492A (zh) | 基于固件的固态驱动器块故障预测和避免方案 | |
| Haghdoost | Towards Performance and Reliability Enhancements of Enterprise Data Storage Systems | |
| BORBA | Stochastic modeling of data storage systems for evaluating performance, dependability, and energy consumption |