A user's Asus laptop would not boot. The SSD showed up as a 1MB device within the BIOS. While this does look alarming, it is actually a positive sign, because no physical disk is 1MB, and the actual information being communicated by the controller is about what specifically has occurred.
This is a scenario, not a case study. It illustrates a common failure type that we address on a regular basis, and how it is approached, written from the technical side (versus as part of a single customer project). Please visit our documented case files here.
After running fine the day before, an SSD is now reported as a device through the BIOS or the Disk Management tool. The reporting shows the SSD to be 1 MB, 2 MB or 8 MB. The SSD is detected, responding normally to requests from the BIOS or the Disk Management tool and reporting a capacity that is clearly inaccurate.
It is not simply a matter of some random reading error. Several controllers have been written to report a small (tiny) capacity if they determine their internal state is inconsistent: a corrupted translation table, a failed self-test, uncleanly loaded firmware etc.
Controllers use this method as protection. Instead of reporting a normal-sized disk and returning incorrect information, the controller reports something that is obviously not correct. This prevents an operating system from writing to user data on a disk that the OS can no longer accurately reference.
Therefore, the drive is functioning just as intended. It has determined that it cannot safely provide access to your files, and it is communicating this message using the only method available to it.
The operating system does not know where an SSD stores its data. The translation layer takes a logical address from the computer and translates that into a physical location on the NAND flash memory. This translation layer is altered at all times by the wear levelling process as it moves data from one NAND block to another. Each of these translations is stored within the SSD's metadata (in the controller).
If there is damage to the translation layer, none of the NAND below it will have been written to. All bytes are physically located in some NAND block, but the drive will no longer be able to locate them due to loss of the indexing information (the mapping), which was part of the metadata.
Recovering data therefore involves repairing the translation layer using the manufacturer's vendor mode, or alternatively, accessing the NAND directly, and then recreating the mapping outside of the SSD (reversing the effects of wear levelling, interleaving and scrambling done by the SSD controller).
Do not run a firmware update or a secure erase. These two options are presented as solutions for this problem, and they both write to the drive in some way. Secure erase in particular does exactly what it says, and when your drive is in safe mode it is the one action which causes all of the data to be unrecoverable.
Almost certainly not. A drive of this size does not exist in manufacturing. This is just a “placeholder” that the controller displays when it fails to load its firmware or mapping tables. Typically the flash containing your data remains unchanged behind this placeholder.
This is convention, not measurement. Each manufacturer has their own “placeholder capacity” (commonly seen: 1MB, 2MB and 8MB) as an indication that the drive is alive but not ready to serve data.
No. Updates rewrite the service area that recovery needs to read from. On drives already in a fallback state, this can make problems permanent. Secure erase and any “repair” utility provided by manufacturers will have the same results.
A diagnostic mode built into the controller by its manufacturer which allows bypassing of the normal interface. It enables direct reading of the service area and translation tables for imaging, even though no computer can mount the drive.
Due to slower speeds, increased risk, and it often being useless with modern controllers. Many controllers encrypt data at rest, so a chip-off returns a perfect copy of something that is unreadable. Recovering the controller lets it do all its own decryption and address translation.
When we are able to revive the controller, it usually takes a few days. This one was done in three. Cases that need direct flash reads are much more time consuming, which is another reason why we prefer the controller path.
There have been many methods of power cycling the drive at various intervals that are posted around the web. While some will exit the safe mode with these cycles, others will run their housekeeping functions during the cycle and discard your damaged map.
You can update/flash firmware on a controller unable to read its own metadata, but the process may only partially complete, leaving the drive in an even worse state than the safe mode.
Provided by several vendor utilities to fix the problem with a drive reporting an incorrect size. It does fix it; however, it also deletes all the data on the drive.