Question Samsung 990 PRO 2TB: Performance Degradation After 7B2QJXD7 Firmware Upgrade - Capacity-Specific Bug?

[SFdrifter]

PLEASE NOTE THAT THIS FIRST POST WAS MOSTLY INCORRECT -- I MISINTERPRETED SLC CACHE EXHAUSTION FOR POOR PERFORMANCE; I DO NOT BELIEVE THERE IS A FIRMWARE BUG INVOLVED

I'm reporting an apparently capacity-specific firmware bug affecting Samsung 990 PRO 2TB drives after updating to firmware 7B2QJXD7. My 4TB 990 PRO with identical firmware (updated at the same time) performs normally.

---

**AFFECTED DRIVE:**
- Model: Samsung SSD 990 PRO with Heatsink 2TB (used as system drive with 5 partitions)
- Serial: S7DRNJ0XC08579H
- Firmware: 7B2QJXD7 (upgraded from 4B2QJXD7)
- System: Arch Linux, AMD Ryzen 9 9900X

**COMPARISON DRIVE (NORMAL):**
- Model: Samsung SSD 990 PRO 4TB (used as data drive with 1 partition)
- Serial: S7DSNJ0X912378T
- Firmware: 7B2QJXD7 (upgraded simultaneously with the 2TB SSD)

---

**PERFORMANCE DEGRADATION (FIO BENCHMARKS):**

**2TB Drive - BEFORE firmware upgrade, using 4B2QJXD7:**
✓ Sequential Write: 6,650 MB/s
✓ Random Write: 4,436 MB/s (1,135K IOPS)
✓ Sequential Read: 6,650 MB/s
✓ Random Read: 2,970 MB/s (760K IOPS)

**2TB Drive - AFTER firmware upgrade, using 7B2QJXD7:**
Sequential Write: 1,478-3,691 MB/s (45-78% LOSS)
Random Write: 1,375-1,460 MB/s (68-70% LOSS) ← CRITICAL
Sequential Read: 6,752-7,007 MB/s (normal)
Random Read: 2,369-2,582 MB/s (13-20% loss)

**4TB Drive - AFTER firmware 7B2QJXD7:**
Sequential Write: 6,577 MB/s (NORMAL)
Random Write: 4,435 MB/s (NORMAL - matches 2TB baseline!)
Sequential Read: 6,687 MB/s (NORMAL)
Random Read: 4,594 MB/s (EXCELLENT - better than 2TB baseline!)

---

**TESTING METHODOLOGY:**

To isolate the issue, I performed the following testing:

1. Tested across multiple partitions (root, home, data)
2. Tested from Live USB (eliminating OS activity)
3. Tested both drives with identical parameters
4. Monitored temperatures during tests

**KEY FINDINGS:**
- Performance degradation occurs on ALL partitions of 2TB drive
- Live USB testing (no OS) still shows degraded performance
- 2TB drive runs 26°F hotter than 4TB (113°F vs 87°F)
- Higher temp suggests excessive write amplification?
- 4TB drive with SAME firmware performs perfectly
- Both drives updated simultaneously
- Both have similar write endurance (~22-23TB)

---

**TEMPERATURE COMPARISON:**
- 2TB (Problem): 113°F / 45°C (elevated)
- 4TB (Normal): 87°F / 31°C (normal)

---

**POSSIBLE IMPLICATIONS**

Is this a **capacity-specific firmware regression** affecting 2TB 990 PRO models? Does the 7B2QJXD7 firmware have different code paths for different capacities, and does the 2TB implementation has a critical bug in random I/O handling?

The elevated temperature on the 2TB drive suggests the firmware is causing excessive internal operations (write amplification, garbage collection, etc.).

****Has anyone else experienced this after updating 2TB 990 PRO to 7B2QJXD7?**

I have detailed benchmark logs, SMART data, and test results available as requested.

----

**System Details:**
- OS: Arch Linux (kernel 6.x)
- Motherboard: AsRock x870e Taichi
- Zen5 9900x CPU
- Testing Tool: fio 3.39
- Test Parameters: libaio, direct I/O, various block sizes

----

UPDATE: SMART Data Analysis

I also noticed that SMART data for the 2TB and 4TB 990 Pro SSDs report the same number of power cycles (the drives were both installed at the initial build in February) but much different power-on hours. Similar results were also apparent from earlier tests in September using the older firmware.

8 Sept 2025; 4B2QJXD7 firmware

metric // nvme0 (4TB) // nvme1 (2TB) // ratio/delta

Power Cycles // 689 // 689 // 1.0x

Power On Hours // 945 // 2,108 // 2.23x

Temperature // 33°C // 39°C // +6°C

Controller Busy Time // 978 // 1,899 // 1.94x



23 October 2025; 7B2QJXD7 firmware

metric // nvme1n1 (4TB) // nvme0n1 (2TB) // ratio/delta

Power Cycles // 821 // 821 // 1.0x

Power On Hours // 1,025 // 2,447 // 2.39x

Temperature // 31°C // 45°C // +14°C

Controller Busy Time // 1,118 // 2,224 // 1.99x


The odd counting of power_on_hours is either intentional or it's a bug that was at least present in the 4B2QJXD7 firmware.

Regardless, the firmware update seems to have caused thermal issues.

Temperature comparison (both drives in same system):
- 8 Sept (4B2QJXD7): 2TB=39°C, 4TB=33°C (6°C difference)
- 23 Oct (7B2QJXD7): 2TB=45°C, 4TB=31°C (14°C difference)

The 2TB drive's temperature increased by 6°C after the firmware update, and the temperature delta between drives more than doubled.

This thermal increase, combined with the 70% performance loss, suggests that the 7B2QJXD7 firmware is causing the 2TB drive to work much harder internally, possibly due to excessive write amplification or garbage collection activity.

 

[Shmee]

Interesting, good of you to report this here, and if possible you should report to Samsung as well. Is it possible to flash back to/downgrade the firmware? If not you may need to reach out to Samsung for an RMA or a fixed firmware revision.

 

[SFdrifter]

Thanks for your response...I've reported it on the Samsung forum and will RMA it as soon as possible. To my knowledge, it's not possible to downgrade, but I admit I haven't aggressively tried.

I'm really hoping there are others who've collected similar benchmarking data with each FW upgrade, especially with both a 2TB and 4TB 990 Pro installed. My experience may, of course, be completely idiosyncratic. But if it's not...

 

[bba-tcg]

Thanks for your response...I've reported it on the Samsung forum and will RMA it as soon as possible. To my knowledge, it's not possible to downgrade, but I admit I haven't aggressively tried.

I'm really hoping there are others who've collected similar benchmarking data with each FW upgrade, especially with both a 2TB and 4TB 990 Pro installed. My experience may, of course, be completely idiosyncratic. But if it's not...

Or, it could point to another issue with your specific drive. A sample size of one is inconclusive. Maybe some users with the same model could do some testing or someone could buy a few just to find out.

Please don't take it the wrong way, I'm not saying you're wrong.

 

[SFdrifter]

Of course…that’s what I meant when I said my experience may be idiosyncratic. I actually hope I’m wrong — the 7B2QJXD7 firmware is supposed to fix the disappearing drive problem that’s caused over 20 system crashes since I built this PC on February. Again, thanks for your attention.

 

[Ken g6]

Oh, goody, I have that drive. Let's see what firmware...

0B2QJXG7

Maybe I should update it? Maybe not?

I have noticed the drive runs a little hot, which 4B2QJXG7 is meant to fix. I've also noticed its temperature depends a lot on how much other components (CPU, GPU, other drives I guess) are heating the interior of my case. @SFdrifter, was the ambient temperature the same for both your tests, and were you doing anything to draw more power the second time?

 

[SFdrifter]

I built this PC just this past February and decided, for the first time in 40 years of PC ownership, to systematically benchmark system performance. In the past, if it worked without errors, data corruption, crashing, or egregious latency, then, as far as I was concerned, it worked well enough.

Since February, though, I use a benchmarking script and a health-checking script that I run manually after every major change (updated BIOS, updated firmware, updated kernel, new components). Generally, I try not to do anything on the PC while the scripts are running. I then review the results by manually comparing the new results to the most recent prior results and maybe run and get screenshots of a set of KDiskMark tests as well...usually, the test comparison is just a quick perusal, but this time the new results stood out.

The "UPDATE: SMART Data Analysis" section shown above is summarizing two script logs from two different dates, where the results for any particular date reflect the same ambient temperature. True, the tests themselves could raise the ambient case temperature, but, while I've since modified my benchmarking script to capture temps before and after each fio test, the temperatures reported in the "UPDATE: SMART Data Analysis" section above are from my health-checking script which initiates either short or long self-tests, waits, and then uses "smartctl -x" to collect the data from all my drives. The "smartctl -x" command is only issued after the last self-test has completed, and, for long tests, that's determined by the system's backup HDD, not the SSDs. On 8 Sept, that was about 8 hours after the SSD self-tests had ended, so the SSD temps weren't affected by the HDD self-test; on 23 October, the 2-minute short tests were run on all the drives, where they shouldn't unduly raise the temps.

I know, it's not strictly apples to apples, but, hey, I wasn't expecting to see anything special. Drive temperatures in general fluctuate -- the same script run, say, an hour apart, won't show the exact same temps, but the broad results are consistent. If I really wanted to obtain more precise drive performance, I'd boot from a live USB stick and remove effects of the OS from the measurements. (I did exactly that to confirm the results I saw on the 2TB drive, but I haven't explicitly shown those results here.) The main point of the "UPDATE: SMART Data Analysis" section was to highlight the difference observed in power_on_hours.

Probably more than you really wanted to know.

 

[SFdrifter]

Apologies for derailing my own thread…but let me get back on point.

To be clear: the degraded performance that I see on the 990 Pro 2TB drive isn’t really perceptible. If I hadn’t been benchmarking, I wouldn’t have noticed any difference in performance. Even with “degraded” performance, the 990 Pro 2TB is still faster than an HDD.

If you’ve already upgraded the firmware to 7B2QJXD7, I’d appreciate you running some tests to see what the performance is. Ideally, you’d have results from your prior firmware, but you can still compare to spec.

The tests I currently run are as follows, where the burst sequential write is a new test I introduced in the last few days to get closer to spec values:

# BURST TEST (capture SLC cache performance for NVMe)
fio --name=burst_seq_write --directory="$TEST_DIR" --size=5G \
--bs=1M --iodepth=32 --numjobs=1 --rw=write \
--ioengine=libaio --direct=1 --group_reporting=1

# SUSTAINED SEQUENTIAL WRITE
fio --name=seq_write --directory="$TEST_DIR" --numjobs=1 --size=10G \
--time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --bs=1M --iodepth=32 --rw=write --group_reporting=1

# SEQUENTIAL READ
fio --name=seq_read --directory="$TEST_DIR" --numjobs=1 --size=10G \
--time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --bs=1M --iodepth=32 --rw=read --group_reporting=1

# RANDOM WRITE IOPS
fio --name=rand_write --directory="$TEST_DIR" --numjobs=2 --size=10G \
--time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --bs=4K --iodepth=32 --rw=randwrite --group_reporting=1

# RANDOM READ IOPS
fio --name=rand_read --directory="$TEST_DIR" --numjobs=2 --size=10G \
--time_based --runtime=60s --ramp_time=2s --ioengine=libaio \
--direct=1 --bs=4K --iodepth=32 --rw=randread –group_reporting=1


Note that the random r/w tests have numjobs set to 2 – I experimented a bit and found that the 2TB drive shows worse performance with numjobs=4 as the drive saturates, its command queue becomes full, and latency increases. The 4TB drive shows roughly the same performance with numjobs=2 and 4 but then falls off with numjobs=6 as it saturates. For the sequential r/w tests, saturation becomes evident as soon as numjobs=2, hence my use of numjobs=1 in testing.

My current benchmarking script additionally runs fstrim on each SSD drive before testing, monitors temperatures before and after each fio run, and sleeps for 60 seconds after each fio test to give the drive under test opportunity to settle between fio runs.

Here’s what Samsung specifies for the 990 Pro (where, as is normal, they don’t indicate the exact test parameters):

sequential write: up to 6,900 MB/s
sequential read: up to 7,450 MB/s

random write (4kB, QD32): up to 1,550,000 IOPS
random read (4kB, QD32): up to 1,400,000/1,600,000 IOPS (2TB/4TB)

[note that I’m not testing QD1]
random write (4kB, QD1): up to 80,000 IOPS
random read (4kB, QD1): up to 22,000 IOPS

Here are my current results for the 7B2QJXD7 firmware (captured today) as well as earlier results for the 990 Pro 2TB taken using a live USB stick to avoid any impact from the test partition being on the system drive (2TB 3 Nov 2025 | 2TB 23 Oct 2025 with live USB stick):

990 Pro 2TB
burst sequential write: 6,918 MB/s (6,598 MiB/s) | n/a
sustained sequential write: 5,221 MB/s (4,979 MiB/s) | 6,932 MB/s (6,611 MiB/s)
sequential read: 7,411 MB/s (7,068 MiB/s) | 6,018 MB/s (5,739 MiB/s)
random write: 584,000 IOPS | 439,000 IOPS
random read: 1,023,000 IOPS | 661,000 IOPS

temperature summary (3 Nov 2025):
initial: 104°F (max sensor)
peak: 129°F (max sensor)
increase: 25°F
no thermal throttling detected

990 Pro 4TB
burst sequential write: 6,830 MB/s (6,514 MiB/s)
sustained sequential write: 6,902 MB/s (6,583 MiB/s)
sequential read: 7,012 MB/s (6,687 MiB/s)
random write: 1,264,000 IOPS
random read: 1,177,000 IOPS

temperature summary:
initial: 86°F (max sensor)
peak: 113°F (max sensor)
increase: 27°F
no thermal throttling detected


And here’s what I saw with the earlier 4B2QJXD7 firmware (4 Sept 2025 | 17 June 2025 tests)

990 Pro 2TB
sustained sequential write: 6,973 MB/s (6,650 MiB/s) | 6,960 MB/s (6,643 MiB/s)
sequential read: 6,973 MB/s (6,650 MiB/s) | 6398 MB/s (6,101 MiB/s)
random write: 1,135,000 IOPS | 562,000 IOPS
random read: 760,000 IOPS | 626,000 IOPS

990 Pro 4TB
sustained sequential write: 6,904 MB/s (6,585 MiB/s) | 6,903 MB/s (6,583 MiB/s)
sequential read: 7,012 MB/s (6,687 MiB/s) | 7,012 MB/s (6,687 MiB/s)
random write: 1,265,000 IOPS | 1,279,000 IOPS
random read: 1,177,000 IOPS | 1,179,000 IOPS

I don’t know why the 4B2QJXD7 2TB random read performance is so far from spec – the result with the newer firmware is much more in line with expectations, except when the tests were run from a live USB stick. The 4B2QJXD7 2TB random write performance is also odd – similarly, why is it OK one day but not the next? The 7B2QJXD7 2TB random write performance is markedly lower than spec. By contrast, the 4TB test results are remarkably consistent across both time and firmware versions. The fact that the 2TB drive is my system drive may be causing some of the problem here, but I saw similar results when I ran these tests from a live USB stick.

So this is why benchmarking is so important. Anyone else with results for the 7B2QJXD7 firmware on a 990 Pro 2TB?

For reference, the only pertinent web discussion I see is this one:

https://www.reddit.com/r/buildapc/comments/1mp8kki/low_random_write_speeds_on_samsung_990_pro_2tb

 

[SFdrifter]

I wanted to end this thread in light of further investigation. For details, see https://us.community.samsung.com/t5...er-7B2QJXD7/m-p/3403006/highlight/true#M17532

My conclusions are:

**I don’t think the 7B2QJXD7 firmware caused any degradation in performance that wasn’t already present in earlier firmware;

**burst random write performance of the 990 Pro 2TB drive over 5 seconds roughly meets the spec’ed value (or at least isn’t egregiously lower);

**sustained random write performance of the 990 Pro 2TB drive over 10 seconds or more drops to ~25% of spec, but the worst value I saw (375k IOPS) is still significantly better than the SATA 870 EVO drives I tested or than a hard drive.

**the difference I reported earlier in the Power On Hours from “smartctl -x” for the two drives is still a mystery – if it’s correct, then what’s going on?

In general, this review of the Samsung 990 Pro 2TB is excellent, explaining benchmarking procedures and highlighting on page 6 the impact of the SLC cache on benchmarking results: https://www.techpowerup.com/review/samsung-990-pro-2-tb/