I was doing a routine disk health pass across my homelab NVMe drives with nvme smart-log from
nvme-cli when one of them refused to fit the math.
7% worn after 8 TB written#
A 990 PRO 2TB reported this:
percentage_used : 7%
Data Units Written : 15,667,509 (8.02 TB)
power_on_hours : 366
media_errors : 0
available_spare : 100%The 2TB model is rated for 1200 TBW. 8 TB written is about 0.7% of the endurance budget, yet the drive claimed 7% used. An order of magnitude off, with zero media errors and full spare capacity. Nothing in the SMART data suggested a NAND problem. The wear accounting was the obvious outlier.
Launch firmware with broken wear accounting#
nvme list gave the answer:
/dev/nvme1n1 S6Z2N... Samsung SSD 990 PRO 2TB ... 0B2QJXD70B2QJXD7 is the launch firmware for the 1TB and 2TB 990 PRO. If that rings a bell, it is the firmware behind the early 2023 story where brand new
990 PROs were burning through their reported health at absurd speed. Samsung fixed the counter logic in 1B2QJXD7 and later releases, but the
inflated value is permanent by design: percentage_used is monotonic and never rolls back.
The number itself is cosmetic. Warranty is based on actual TBW, and 8 out of 1200 TB is nothing. What is not cosmetic: a drive that lies about wear makes SMART-based monitoring useless. My Prometheus alerts on wear rate would either fire on noise or get muted, and both outcomes are bad.
Why fwupd shows the drive but never updates it#
First instinct on Linux: fwupd.
fwupdmgr get-devices
...
├─SSD 990 PRO 2TB:
│ Current version: 0B2QJXD7
│ Device Flags: • UpdatableLooks promising, delivers nothing. fwupdmgr get-upgrades came back empty. The “Updatable” flag only means the device supports the standard
NVMe firmware download and commit mechanism. Whether an update actually exists depends on the vendor publishing payloads to LVFS, and at the time
of writing Samsung does not do that for consumer SSDs. So fwupd is not broken and your setup is not broken. There is simply nothing on the server
for this hardware. You can confirm that without installing anything: the LVFS device list shows which hardware
has vendor-published firmware, and Samsung consumer SSDs are not on it. If the stack is new to you, the
fwupd article on the Arch Wiki is the shortest useful map of how the daemon, LVFS, and vendor payloads
fit together.
Samsung ships it as a bootable ISO#
Samsung distributes consumer SSD firmware in two forms: through Samsung Magician on Windows and as bootable ISO images on the consumer storage tools page. The page leads with Magician downloads, so scroll past those to the Firmware section and grab the ISO for your model, in my case “990 PRO Series Firmware”. A pleasant surprise: forum threads from December 2025 were still discussing 7B2QJXD7 as the latest, but the ISO I downloaded carried 8B2QJXD7. The filename tells you the version before you flash anything.
Flashing without a USB stick#
The official route is to write the ISO to a USB stick, disable Secure Boot, and boot from it. That works, but there is a shortcut. The ISO is a
tiny Linux image, and the actual updater, fumagician, sits inside its initrd. I was able to extract the updater and run it directly from my
live Linux system.
This is not Samsung’s documented update path. It worked with the ISO and Linux environment described here, but the ISO layout or updater behavior may change. If you want the supported procedure, boot the ISO from USB. The trick itself is not mine: the Samsung section of the Arch Wiki SSD page documents the same extraction, and it is the first place I would check if a future ISO changes the layout.
mkdir -p /tmp/iso /tmp/fw
sudo mount -o loop Samsung_SSD_990_PRO_8B2QJXD7.iso /tmp/iso
cd /tmp/fw
gzip -dc /tmp/iso/initrd | cpio -idv --no-absolute-filenames
cd root/fumagician
sudo ./fumagicianTwo notes. Run the fumagician binary, not fumagician.sh: the script wraps the binary and reboots the machine as soon as it finishes. And on
some platforms fumagician scans, finds the drive, and exits without flashing anything. If that happens to you, fall back to the bootable USB
route, which is the workflow Samsung documents.
The tool is interactive: it detects supported drives, shows current and available firmware, and asks for confirmation. The update is designed to preserve existing data, but flashing a storage controller is never completely risk-free. Verify your backups first. That is not a firmware-day rule, that is an every-day rule.
New firmware waits for a power cycle#
Here is the part that confuses people. After fumagician reports success, nvme list may still show the old version:
/dev/nvme1n1 ... Samsung SSD 990 PRO 2TB ... 0B2QJXD7That is expected. The image is written to a firmware slot but only activates after a controller reset. You can inspect the slots first:
sudo nvme fw-log /dev/nvme1fw-log, smart-log, and the rest of the toolbox are covered well on the
Arch Wiki NVMe page if you do not use nvme-cli daily.
If the new version shows up in a slot, finish the job with a full power cycle. A warm reboot is sometimes not enough for these drives: shut down, leave the machine without power for a few seconds, then boot. I went the paranoid route and physically reseated the drive, which is overkill but definitive:
/dev/nvme1n1 ... Samsung SSD 990 PRO 2TB ... 8B2QJXD7Done.
The number stays, the slope matters#
The 7% stays forever, and I can live with that. What matters is the slope. The naive math says 1% per 12 TB written, but I do not expect it to
be perfectly linear: percentage_used is a vendor-defined endurance estimate, while Data Units Written counts host writes before write
amplification. The relationship is still useful as a sanity check, so I left myself a note to compare both values again in a couple of months.
If the counter keeps racing ahead of the actual workload on fixed firmware, that becomes an RMA conversation. If it advances at a plausible
rate, the drive goes back to being a boring, healthy piece of the lab, which is exactly what I want from storage.
