Samsung Enterprise NVMe Shows Up as 1 GB. Don't Secure-Erase It.

Written and maintained by the Desert Data Recovery lab team. · Updated November 13, 2026

Used enterprise NVMe is cheap right now, and a lot of it ends up in home labs, small-business servers, and NAS boxes with an M.2 or U.2 adapter. We already wrote about used enterprise SAS SSDs that fail at a fixed hour count. This page is a different Samsung failure that looks much stranger: a multi-terabyte drive that suddenly says it is 1 GB.

What the 1 GB means

The drive has entered its controller's error mode. The controller still enumerates on PCIe and still answers commands, so the host sees a device. What it will not do is load its flash translation layer, the table that maps each logical address to where the data physically sits on the NAND. Without that table it exposes a small placeholder namespace so the host has something to talk to.

The best public teardown of this state we have found is OSSLab's diagnosis of a Samsung PM983 NF1 3.84 TB (Chinese, published November 11, 2026). On their drive:

• The controller identify data still reported the full 3.84 TB. Namespace 1 was 2,097,152 sectors of 512 bytes, exactly 1 GiB. There was no hidden second namespace.
• The firmware revision field read ERRORMOD. The original firmware was still in its read-only slot.
• Samsung's own diagnostic dump showed DeviceFail, the last shutdown recorded as a sudden power-off, and the translation-layer sections empty. Their reading is that the power-loss protection did not finish writing the table's metadata, the rebuild failed on the next boot, and the controller gave up.
• Controller resets, subsystem resets, and PCIe-level resets all came straight back to ERRORMOD. Only a cold start, with the 3.3 V rail actually off, made the controller run its full boot again, and it landed in error mode again.

Supermicro describes the PM9A3 version of the same symptom as the drive "showing up as numerous 1gb individual disks." Whether you see one 1 GB namespace or several, it is the same story: the controller is up, the map is not.

Every published fix is an erase

Supermicro's FAQ for a failed PM9A3 showing up as 1 GB disks gives three steps: drain, secure erase, firmware update. Step 1 is to power off, unplug the drive, and leave it unpowered for one to two hours. Step 2 is nvme format with --ses=1, a cryptographic erase. Step 3 loads firmware they supply by serial number. They are honest about it. Their own warning says the secure erase step permanently and irreversibly destroys all data on the drive, and to back up any recoverable data first.

Samsung's tooling says the same thing in fewer words. OSSLab found that the function in Samsung's tool for leaving this state is named EscapeErrorModeUsingSecureErase. A cryptographic erase throws away the drive's internal encryption key and starts a fresh, empty map. The drive comes back at full capacity, looks healthy, and is blank. That is why the "it worked, the drive is fine now" posts are true and useless at the same time.

The trap is the advice to back up first. On a drive in error mode there is nothing to back up from the host. OSSLab scanned the whole 1 GiB and got zeros. They sent raw reads with Force Unit Access to addresses far past 1 GiB, and the controller returned success and zeros in about 0.02 ms, which is too fast to have touched the NAND. ddrescue, R-Studio, or a passthrough read all get the same zeros. A clean image of that is not a copy of your data.

Why chip-off is not the backup plan

On a lot of older flash, when the controller dies, a lab can read the NAND chips directly and rebuild the data. Not here. OSSLab notes the PM983 encrypts everything it writes to NAND with the controller's built-in AES, and the key is not stored on the NAND. We explain the same wall on consumer drives in chip-off won't save an AES-encrypted NVMe drive. For these drives, the data comes back through that drive's own controller, with its own key, or it does not come back. A secure erase removes that key on purpose.

What about a firmware update?

This is the honest gray area. OSSLab lists ERRORMODE fixes in later PM983 firmware release notes, including a power-loss dump failure that fits their drive's sudden power-off record, and says a corrected firmware could in theory let the controller retry its boot without clearing data. In practice their controller refused every image that was not signed for its exact product line, and the matching NF1 firmware was not publicly available. Samsung's DC Toolkit 3.0 guide lists, as a known issue, that the program hangs and cannot exit during an ERRORMOD firmware update. And in Supermicro's sequence, the firmware comes after the erase, not instead of it.

So a firmware load is not a guaranteed erase, but it is a write to a controller that is already failing, from tools that have documented trouble in this exact state. If the drive is the only copy, that is not the experiment to run first.

Don't read the SMART numbers

OSSLab saw temperature 0 K, Percentage Used 255%, Available Spare 0%, and 0 power-on hours. None of that is real. The process that keeps those values is not running in error mode. A drive that reports 0% spare because it is in ERRORMOD is not the same as a working drive that has actually used up its spare blocks. Do not let those numbers convince anyone the drive is worn out and the data is gone anyway, so the erase costs nothing.

Their drive was also sitting at 77°C idle in error mode. Leaving it powered on in a server bay, or power-cycling it over and over hoping it clears, adds heat and cold boots without adding information.

What to do right now

1. No format, no sanitize, no secure erase. That covers nvme format with any --ses value, nvme sanitize, a vendor tool's erase button, a BIOS or BMC secure-erase option, and a NAS or hypervisor offering to initialize the "new" 1 GB disk.
2. The drain is the step that does not write. Step 1 of the Supermicro FAQ, unplugged for one to two hours and then one cold start, is reasonable. If the drive comes back at full capacity, copy what you need off it before anything else. If it comes back at 1 GB again, power it off and leave it off.
3. Hold off on the firmware. If the data matters, a firmware load waits until someone has decided, with the drive in hand, that it is the right move.
4. Write down what you saw. Model and part number from the label (for example, MZQL2... or MZ1L2...), capacity, the firmware string, the namespace sizes, what the drive was doing when it failed, and whether the server lost power. Note any command anyone already ran.
5. If it was in an array, leave the array alone. In a mirror or a RAID-Z with healthy members, copy from the surviving members first. If the 1 GB drive was a needed member, a single-disk volume, a cache or special device, or a ZFS log, do not let the system replace it, resilver over it, or recreate the pool. See why zpool import -F is a rewind and rebuild versus recovery.
6. If it is a self-encrypting drive, bring the credentials. Whatever locked the drive at the host level still applies once the controller is talking again. We cannot brute-force it.

How a lab handles it

We do not run the erase. We do not load a random firmware image found on a forum. The work is getting this drive's own controller to bring up its translation layer again, so the data can be read the way the drive always read it, and then imaging it before anything else happens. Whether that is possible on a given drive depends on the model, the firmware, and what actually broke inside it. We find that out during the evaluation and tell you before you owe anything.

We will tell you if it is not there. A secure erase or format that finished is the end of that drive's data, on purpose. The public case log has no Samsung enterprise NVMe that came in showing 1 GB, and we will not invent one. We don't advertise a success rate.

Pack it the way any failed drive is packed, with a note of the commands already run. Arizona drop-off is on the locations page. Everywhere else is mail-in. The work is SSD data recovery. The phone number on this site is (602) 686-2622, Mon–Fri 9:00am–5:00pm.