First update of a Mirror connection after the source has shrunk will generate a false error message. In situations where Dynamic Secondary Sizing is enabled for a mirror
relationship and the source volume has shrunk, the next update will generate a secondary re-sizing error message that can be ignored.The update job might will an error for the resize but the mirror job will complete fine.
The error message is generated because Data ONTAP issues an error message stating that secondary resizing cannot happen because the resize is smaller
than the active file system. This error message can be ignored if seen only once on the first update after the source volume has shrunk. The displayed
message reads as follows: The new volume size would be less than that of the replica file system.
This issue fixes itself and no backups are lost so no workaround is necessary.
Error Message: myDfmStation: Could not resize secondary volume
myFiler:/myVolumeName (10565) to 10.0 GB.
I understand your concern and I think this should instead be made a warning and not an error. BTW I am not going to give you further responses until you add a case for the upgrade issue you raised today
This is because the VSM destinaiton keeps last 2 VSM snapshots and you cant shrink them beyond the snapshot size. I can raise a REF for you to change the severity of this can you provide me the case # so that its gets some priority ?
I also have an issue with the volume auto resizing. We have 1st tier -- snapvault --> 2th tier -- snapmirror --> 3th tier. Volumes on the 2th tier are resizing (however there is no need too, because more then large enough) and therefore snapmirrors are failing since the dest volumes are then smaller than then there sources.
I now have disabled the dpDynamicSecondarySizing option to get everyting working again. Is there another solution ?