I'm well aware of the differences between VSM & QSM/SV, that's why I don't really get why VSM is so much slower here then QSM/SV. It's not the initial block/inode change computation, but the actual transfer that's very slow.
What is the data in your volume (Luns/ normal NAS Files/ Multiple Qtrees
Doesn't matter, affects every Volume we have (VMware NFS datastore, Volumes with Exchange iSCSI LUNs, but only a single qtree max.)
Is deduplication enabled on source ?
Yes, dedupe is enabled, but not running during the transfer. But this issue also affects Volumes for which dedupe was never enabled.
Is replication throttle enabled ? Try to disable it and then initialize VSM (depending on your business hours). Did you try VSM during throttle ON timings ?
No replication throttle set, global setting is also disabled
Try not to update VSM using existing snapshot and go for a fresh initialize. Useful if aggregates are recently converted from 32 to 64 bit.
Only 64-Bit aggr from the start, Filer is only a year old. The same issue with updates & initializes happens, no difference
Wait for the baseline to complete.
Did you upgrade any one of the nodes recently ?
We did upgrade from 8.2.2P1 to 8.2.4P1 a month ago, but the issue already started before that.
Are you using same interfaces/vif for VSM and QSM ?
Interface doesn't matter, as slow VSM but fast QSM also happens within the same filer from one aggregate to another. But outbound they use the same ifgrp.