2013-09-04 04:03 AM
Hi guys ,
I am having this trouble with a snapmirror relationship that i cannot initiate because i am getting the above error.
I do not understand why i am getting this :
the destination volume is bigger than the source.
thanks in advance.
2013-09-04 11:30 AM
yes i was, but since i start having this error i did some research and stop
the deduplication in that volume.
On Wed, Sep 4, 2013 at 7:21 PM, Riley Welshman <
2013-09-04 11:31 AM
even with this i did not solve the problem, i cannot replicate it simply
does not initialize and start the replication.
2013-09-04 02:03 PM
A few questions:
1) When you turned off dedupe, did you rehydrate the volume (i.e. "undedupe the volume")?
2) Are you using Volume SnapMirror or Qtree SnapMirror (assuming that this is 7-mode)
3) Are you using thin provisioning for the volumes?
With SnapMirror, when a source volume is deduplicated, the destination SnapMirror volume needs to be larger than the source in order to accommodate the expansion of the deduplicated data. I recall that this pertained to Qtree SnapMirror because the replicated Qtree data is re-hydrated (i.e. not deduplicated) in the SnapMirror destination. This means that the destination volume needs to be able to re-hydrated data.
2013-09-05 01:21 AM
1) A: no i did not "undedupe the volume". But when you say undedupe the
volume, you mean ?
myfilser> sis undo /vol/vol1
If is the above command i did not.
*Could it be the issue???
2) A: I am using Volume SnapMirror in DOT 7.3.7, and both filers have the
3) A: No, the volumes are not using thin provisioning.
On Wed, Sep 4, 2013 at 10:04 PM, jeras <
2013-09-05 10:30 AM
Yes, when you disable dedupe and not do run the sis undo command, the existing data in the volume is still deduplicated. Any new data added to the volume after dedupe is disabled will not be deduplicated.
What are the volume sizes for both the source & the destination volumes (df -g <vol path> & df -g -S <vol path> would be helpful)
Do you have dedupe enabled on the destination volume?
Also, you may want to take a look at the SnapMirror log file on the destination system (found in the /etc/log directory. There may be several versions of the log file there (i.e. snapmiror, snapmirror.0, snapmirror.1). I've found that you can get more details in the snapmirror log file than appears on the console when trying to troubleshoot SnapMirror.
2013-09-05 01:48 PM
Guys The command sis undo solved the problem.
Thanks a lot.
On Thu, Sep 5, 2013 at 6:30 PM, jeras <