Abstract: A process for reliably erasing data from a solid-state drive (SSD) includes first, prior to user data being stored on the drive, generating a restore image of information stored on the drive which characterizes a restore state of the drive, such as a factory image. Then, imparting energy to the drive to promote electrons representing bits in corresponding memory cells to exit the cells, such as imparting thermal energy or high-energy electromagnetic radiation to the drive. Also, generating a set of quantitative data for verifying erasure of the data for presentation to the user helps ensure trust in the data wipe process. The drive may also be electrically erased prior to imparting energy to the SSD, to provide another level of confidence in the data wipe process. The restore image may then be loaded to the necessary locations on the wiped drive to restore drive functionality.

Abstract: Systems, methods, and/or devices are used to manage open blocks within non-volatile storage devices, in order to improve the reliability of non-volatile storage devices. In some embodiments, when a shut-down request is received from a host device, the storage device fetches information about open blocks and their boundary regions susceptible to data reliability issues, and for each identified boundary region, the storage device programs a region contiguous to the identified boundary region. In some embodiments, the device updates an XOR parity table used for XOR parity management with the information that the region contiguous to the identified boundary is programmed. Subsequently, in some embodiments, the storage device can use the information, stored in the contiguous region and/or the XOR parity table, for data recovery in the event of a data loss. As a result, the reliability of the non-volatile storage device is improved.

Abstract: Systems, methods, and/or devices are used to manage open blocks within non-volatile storage devices, in order to improve the reliability of non-volatile storage devices. In some embodiments, when a shut-down request is received from a host device, the storage device fetches information about open blocks and their boundary regions susceptible to data reliability issues, and for each identified boundary region, the storage device programs a region contiguous to the identified boundary region. In some embodiments, the device updates an XOR parity table used for XOR parity management with the information that the region contiguous to the identified boundary is programmed. Subsequently, in some embodiments, the storage device can use the information, stored in the contiguous region and/or the XOR parity table, for data recovery in the event of a data loss. As a result, the reliability of the non-volatile storage device is improved.

Abstract: A non-volatile flash memory has bit lines spanning multiple blocks grouped into columns, where each block is connected along multiple regular columns and one or more redundancy columns. When there is a local column defect, so that the defect is not at the level of the whole block or global column, the portions of a column at an individual block can be remapped to a portion of the same block along a redundant column. Sections of multiple columns from different blocks can be remapped to the same redundancy column. Then a memory block includes a number of independently accessible sub-blocks, the process can also be implemented at the sub-block level. A dynamic, system level implementation is presented.

Abstract: A non-volatile flash memory has bit lines spanning multiple blocks grouped into columns, where each block is connected along multiple regular columns and one or more redundancy columns. When there is a local column defect, so that the defect is not at the level of the whole block or global column, the portions of a column at an individual block can be remapped to a portion of the same block along a redundant column. Sections of multiple columns from different blocks can be remapped to the same redundancy column. Then a memory block includes a number of independently accessible sub-blocks, the process can also be implemented at the sub-block level. A dynamic, system level implementation is presented.