For YEARS now it’s been bothering me that syncoid can only tell you the progress on the current dataset, not the entire recursive replication task. That’s been a hard limit because of the use of an external program (Andrew Wood’s excellent pv) to provide the meter.
That’s gonna change soon! I’ve already written a pv alternative in perl as a proof of concept, and I’m going to start working on incorporating that proof of concept directly into syncoid, so it can show both progress on the current dataset AND the entire replication task.
For measuring durations you want want Time::HiRes::clock_gettime(CLOCK_MONOTONIC) over Time::HiRes::time, as this isn’t affected by changes to the system clock.
For FreeBSD/Rust uutils dd status=progress I used a SIGALRM/sleep thread with a boolean flag to signal the copy loop to handle progress updates at a fixed interval, without involving timekeeping calls for every block. Looks like you could do something similar with Time::HiRes::setitimer.
The apparent rate anomalies are likely because perlpv uses an algorithm which averages together instantaneous transfer rate, ten second average rate, one minute average rate, and five minute average rate in its estimator… And I didn’t think to replace that with the simple overall mean in the final output line. Oops!
Also: this is why it’s not the worst thing to create proof of concept stuff and put it on GitHub, somebody like @Freaky might happen along and improve it for you even BEFORE it goes into production.
Yes, it will. But keep in mind, it still won’t be any more accurate in estimating sizes than it ever was–that’s an upstream issue in ZFS itself, not something I can fix here.
That won’t generally matter much on large jobs, but little ones with lots of snapshots but very little actual data will still tend to show very inaccurate estimates.
