I am running TrueNAS 25.10.3.1 - Goldeye on both the source and target.
Source:
Running in Proxmox vm with HBA passthrough, RAIDZ2 8x 10TB drives (all SMR CMR), ~25TB data. 10GbE NIC
Target:
Running on bare metal, RAIDZ1 4x 14TB drives (all SMR CMR), 10GbE
Issue: Two drives are writing on the target at ~900MiB/s and 2 are ~112MiB/s, overall transfer speed from source to target is ~2gbps. I can’t explain this.
Oh the “fast” drives on the target are TOSHIBA MG07ACA1 and “slow” ones are Seagate ST14000NM005G-2K.
Do you mean CMR instead of SMR in your posts? SMR is the bad one with ZFS.
EDIT. I checked the drive model numbers listed and edited the original post as they were CMR.
Crap I did mean CMR.
900MiB/s seems improbable, right?
Where and how are you seeing this issue?
It helps if you know what your pool layouts are capable of. Linking to pool layout whitepaper. Second link will be an article on checking performance problems. Keeping all the MB vs Mb and MiB vs MB correct can be a chore, too. Last link is if you need to post screenshots and can’t yet.
https://www.truenas.com/white-papers/#TrueNAS-PDF-zfs-storage-pool-layout/1/
Browse some other threads and do the Tutorial by the Bot to get your forum trust level up and post images and links.
TrueNAS-Bot
Type this in a new reply and send to bring up the tutorial, if you haven’t done it already.
@TrueNAS-Bot start tutorial
@TrueNAS-Bot start tutorial
I’m inclined to think this is a NetData or SMART database bug. Those numbers aren’t physically possible.
This is what I was thinking. At first I was questioning the delta, then I was questioning the higher numbers heh.
I would try checking the command line and see what is reported from the Klara Systems article. If the four drives are very similar there then it points to something with the GUI and reporting as stated above. You can try using Report a Bug in the GUI and including a Debug Dump on the target system. Including screenshots of the four disks data over a longer period may help them. At least that way it was reported with as much data as you can provide for them to attempt reproduction.
I agree, it appears to be a reporting bug.
However, I have seen odd behavior that is real, yet has a simple explanation.
For example, assume both Seagate and Toshiba HDDs have a write cache, and it is enabled. Then, what if the Toshiba disks have a larger write cache on the drive, perhaps twice as large. With ZFS writing an entire stripe, (aka 4 disks in RAID-Z1), the writes fill the Seagate write cache quickly. The writes to the vDev are then throttled by the Seagate drives. Yet the Toshiba say they can handle more writes, by reporting write completion much earlier.
Could even be a case where the Seagate reports the use of a write cache and the Toshiba does not.
But, Occam’s razor says it is likely just a bug in reporting.
