Under a minute of mains failure, and one desktop came back reporting an impossible capacity and refusing every read. Nothing had worn out — the drive had simply lost confidence in its own record of where everything lived.
An engineering practice lost mains power for less than a minute. Most machines came back without complaint; one desktop did not, reporting no bootable device. Its SSD held CAD drawings and a local project database that had not yet synced to the server.
The drive was detected by the BIOS but reported an implausible capacity and refused read requests. That particular combination — present, identifiable, but incoherent — is diagnostic in itself.
A hard disk writes to a fixed physical location for a given logical address, and does so for its whole life. An SSD cannot work that way, for two reasons that follow from how flash behaves.
Flash can be written a page at a time but only erased a whole block at a time, and a block is much larger than a page. Overwriting one page in place would mean reading the entire block, erasing it and writing it back — slow, and it consumes one of the finite number of erase cycles that block will tolerate. So the drive does not overwrite in place. It writes the new version to a fresh page somewhere convenient, marks the old one stale, and updates a table recording where the current version now lives.
That table is the flash translation layer. It is what lets the drive spread wear evenly, reclaim stale pages in the background, and present a simple linear address space to a computer that has no idea any of this is happening. It is also, unavoidably, the single point on which everything depends: without it the NAND is undifferentiated data, and reading every page recovers nothing.
The translation tables are large and change constantly, so they are held partly in the drive’s volatile memory and committed to flash periodically rather than on every write. Between commits there is a window where the memory copy is current and the committed copy is behind.
Cut power in that window and the drive restarts holding a map that does not match what is physically on the flash — it describes pages that have moved, or omits ones that were written. A controller in that state has a choice: serve data it cannot vouch for, or refuse. Well-designed firmware refuses, which is what produces the wrong-capacity, no-read behaviour. The drive is telling you it has lost confidence in its own map.
Enterprise SSDs address this with power-loss protection — a bank of capacitors holding enough charge to flush the in-flight metadata after power is gone. Consumer drives generally do not have it, and this was a consumer drive in a desktop with no UPS.
The NAND itself tested sound, with unremarkable wear indicators. That ruled out exhaustion and confirmed the fault was structural.
Access was established through the controller’s vendor-specific diagnostic mode, which bypasses the normal interface and allows the reserved service area to be read directly — the region where the drive keeps its translation tables, its bad-block map, its firmware and its own logs. That access is the whole job. Without it there is no route to the map, and without the map there is no route to the data.
Critically, the drive was not repeatedly power-cycled during troubleshooting before it arrived. Each restart in this condition gives an uncertain controller another opportunity to commit something worse, and a few of these arrive having been rebooted twenty times in the hope of a different outcome.
Modern controllers do not keep only one copy of the map. They journal changes and retain earlier checkpoints, precisely because this failure mode is anticipated.
The most recent commit was inconsistent, so the tables were rebuilt from the last checkpoint that validated internally — a mapping known to have been coherent at the moment it was written. What that loses is only the writes in flight between that checkpoint and the outage, which on a drive of this class is typically seconds.
From the reconstructed mapping the drive was imaged read-only in a single pass, and the file system rebuilt from the image rather than from the drive.
CAD files were opened in their own application rather than checked for size, because a truncated drawing frequently opens far enough to look complete. The project database was checked for structural consistency page by page — a database captured mid-write can be byte-complete and still refuse to attach, and confirming that before handover is the difference between a recovery and a disappointment a week later.
Complete, apart from a few seconds of writes at the instant of the outage. The practice fitted a UPS to the machines holding local working data, which is the correct response — this failure mode has nothing to do with drive quality and is entirely preventable for the price of the smallest UPS on the shelf.
One thing to take away if this happens to you: an SSD that suddenly reports the wrong capacity is not a dying SSD. It is a drive protecting you from its own uncertainty, and the flash behind it is usually intact. Stop power-cycling it. SSD recovery is from £300 +VAT after a free 48-hour diagnostic.
Send the device over with a short account of what happened to it. The diagnostic costs nothing and commits you to nothing, and the figure that follows is fixed in writing before anything is opened.
Nothing can begin until the device is on the bench, which makes this the only step that needs anything from you. Pack it properly, put your details in with it, and send it over. What follows is a free diagnostic and a written figure, in that order.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Tell us what the device is, what it is doing, and anything already tried — an engineer will come back with a realistic view of the odds and a price band, before you commit to posting anything.
We’ll be in touch shortly. For anything urgent, call 0161 871 0788.
It can leave it unable to describe itself, which looks much worse than it is. An SSD keeps tables mapping logical addresses to physical flash, holds part of them in volatile memory and commits them periodically — so losing power mid-commit leaves the drive holding a map that no longer matches what is on the NAND.
Because a controller that cannot trust its own map will not serve data it cannot vouch for. Reporting an impossible size is the firmware refusing rather than failing. The flash behind it is generally untouched, which is why these recover as well as they do.
Usually only the writes in flight at the instant the power went — seconds, on a drive of this class. The tables are rebuilt from the last checkpoint that validates internally, which restores everything committed before that point. What it cannot restore is what had not been committed yet.
From £300 plus VAT after a free 48-hour diagnostic, with most jobs no fix, no fee. Controller-level work carries a 50% deposit with the balance on success.
Start with an instant online quote, or call and talk it through with us first. You'll have a clear, fixed price before any work begins.