As far as I know, and assuming a recent version of freenas, ZFS scrubs are primarily sequential I/O:
A scrub is split into two parts: metadata scanning and block scrubbing. The metadata scanning sorts blocks into large sequential ranges which can then be read much more efficiently from disk when issuing the scrub I/O.
(source)
I don’t believe a restic check is going to be as “nice” a workload for the pool as the scrub. I’d expect more random I/O basically, because restic isn’t aware of which blocks are contiguous on disk, so it has no way of trying to make all the read requests sequential like a scrub does.
Your 120MB/s figure looks fairly reasonable for a mostly sequential workload. The more random I/O is included in the the workload though, the lower the performance is going to be relative to this.
To offer a point of comparison, I triggered a restic check --read-data against a repository hosted on a btrfs raid1 filesystem, and got around 50MB/s average on one disk (older, 7200rpm drive), and 65MB/s on the other (newer, 5400rpm drive).
Ugh, nevermind, ignore my numbers, I think my setup is network bottlenecked.
(Longer explanation: In my setup, the system hosting the repository has a slower CPU, so running restic locally delivers significantly worse performance than running check remotely from the client. Client and server are connected via a 1Gbps link (125MB/s). 50+65~=115MB/s so add in a little bit of extra for network overhead and you get the 125MB/s figure).
Hope that helps 