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.
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 <
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.