Oh didn’t know this was linux
If I find some time this weekend, I will redeploy my fedora installation with ext4 instead.
I don’t think 30% is too full?
That strongly depends on you drive size and test pattern. To utilize pSLC chache with X GB benchmark write volume, you must have at very least 4X GB of free space available in theory (3x for pSLC temporary area + 1*x for permanent storage).
I don not believe controller behaviour is well studied , we just know rougly how works by observation. It will be much more conservative with necessary free space than the minimum I outlined.
So if you are running benchmark that writes 50 GB of data and have 500GB of free space on drive, you can safely ignore it.
If you have 100GB of free space, they you might run into premature loss of write performance.
Case point - bitlocker whole drive encryption on 512GB intel 660p drive (QLC budget drive from years back). Since whole drive was being sequentially encrypted, once write cache was depleted due continuous operation, i reached steady write performance of only 45 MB/s.
And that was not random write operation 
Are you sure it’s not CPU capped anywhere? Q1T1 of 1.7 would sound as reasonable score but Q8T1 should be higher than that on 990 pro since it’s already “unrealistic synthetic benchmark” territory ngl.
@lapsio: I’m pretty positive, this is on a 24 core/48 thread threadripper. The fact that the synthetics are so low and consistent is really what is getting me
Does it work fine in windows? If it’s the same then maybe issues with drive?
1 Like
if you’re on TR PRO 5965 WX then I’m on exactly the same CPU with ASRock WRX80 Creator motherboard. I can provide you with more benchmarks if you’d like to see 1:1 comparison to my platform. I have 2x 990 PRO 2TB in btrfs RAID1 (on top of two LUKS volumes) but I can mount single drive in degraded mode if you want single drive results.
Oh neat! I’m actually on TR 7000, but that may be interesting. My benchmarks above were RAID1 BTRFS, so that should be very comparable