topic Re: Volume SnapMirror very slow - QSM & SV very fast in comparison in ONTAP Discussions

Volume SnapMirror very slow - QSM & SV very fast in comparison

marcel_juhnke — Wed, 04 Jun 2025 21:57:04 GMT

Hey all,

lately we've been running into the problem that Volume SnapMirrors on our 7-Mode 8040 (8.2.4P1) are veeery slow.

In comparison, qtree SnapMirrors and SnapVault from the same source volumes run as fast as expected.

This is even when transferring within the same filer from one aggr to another one.

Example: VSM from aggr1 to aggr2 on same Filer: transfers with around 1 MB/s and transfers (no matter if initializes or updates) take ages to complete.

From the same source volume in aggr1 to same dest volume in aggr2 QSM & SV run with around 100 MB/s without any issues, also no matter if initialize or update is running.

Any ideas from the community, maybe some bug we're hitting (though I found nothing in that regards).

Support ticket is also already opened.

Re: Volume SnapMirror very slow - QSM & SV very fast in comparison

naren_s — Wed, 02 Mar 2016 11:40:29 GMT

As you might know, VSM (Volume SnapMirror) is done at block level. QSM (Qtree SnapMirror) is done at inode level (folder/file). Even Snapvault uses Qtree concept.

What is the data in your volume (Luns/ normal NAS Files/ Multiple Qtrees)

Is deduplication enabled on source ?
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 ?

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.

Wait for the baseline to complete.

Did you upgrade any one of the nodes recently ?

Are you using same interfaces/vif for VSM and QSM ?

Re: Volume SnapMirror very slow - QSM & SV very fast in comparison

marcel_juhnke — Wed, 02 Mar 2016 12:30:42 GMT

Hello, thanks for your reply.

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.