There are few reasons for doing write tests:
- Drive manufacturers are not marking their devices as SMR, thus detection of those drives is community driven. Absense on the site is a good sign, but not 100% gurantee that drive is not SMR. I also assume that such drives are rarely in forcus of NAS community as not used in NAS servers typically. So might never appear in the list.
- Clean SMR drive behaves the same way as CMR, until almost filled up and data start to be rewritten.
- SMR drives contain CMR areas on platters, which may hold up to 60 Gbs data written at full speed. Consider it as write cache.
- You need to find area to dig to. You have multiple now: urbackup, btrfs, hdd, link between hdd and system, OS. Any of those might be the cause. Try to remove them one by one from equation.
- To see if your system is using USB3 speeds for the drive.
From what I see on the lastest screenshot:
- very typical picture of SMR drive: super slow operations when you have disk writes. And you have them on level of 300 Kb/s.
- IO is hogged by BTRFS kernel processes. I would say that Urbackup has nothing to do with this.
My suggestion is to abort backups, as you might need to destroy FS during your tests. And 300 Kb/s would take enternity anyway.
As for SMART - smart is not capturing “slow blocks”. So for example if it takes to read part of sectors, let’s say 5 seconds - unless HDD firmware will report error (for example for NAS drives those timeouts are less), SMART will not show any errors, while your disk performance will be disgusting. Slow sectors might easily be the reason for performance you’re seeing.