Mirror DSS: Could not resize secondary volume

[brauntvr2swiss]

Hi all

I have a really new (Since few hours) OnCommand 5.1 Environment. Now I have some new Warnings in the PM Jobs:

Server_AllDBs_arch: Could not resize secondary volume Nearstore:/Server_AllDBs_arch_mirror_1 (33160) to 363 GB. The new volume size would be less than that of the replica file system

Does someone know why this warning occurs and how to solve this Problem?

TIA

Thomas

[adaikkap]

Hi Thomas,

     OCUM 5.1 introduced what is called as Dynamic Secondary Sizing for mirrors.  This is not something to worry and is expected. Take a look at this GSS video to get more info the same.

Looks like you successfully upgraded to 5.1, so did the workaround help you ?

7 Mode Protection Enhancements

Regards

adai

[brauntvr2swiss]

Hi Adai

I know about the DSS feature in 5.1, But the message I see is a warning. Its this warning expected?

Server_AllDBs_arch: Could not resize secondary volume Nearstore:/Server_AllDBs_arch_mirror_1 (33160) to 363 GB. The new volume size would be less than that of the replica file system

The Problem is, that this warning markes my snapcreator Job Status as yellow (normally green). Can I disable this warning (like the "processHostPrimaryAddress" Option)?

I have solved the problem, before you have send me your workaround. So I couldn't test your workaround..

regards

Thomas

[adaikkap]

Hi Thomas,

     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

Regards

adai

[adaikkap]

BTW here is the bugs online link for the same. http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=527011

Regards

adai

[brauntvr2swiss]

Hi Adai

Case is open since 7 hours (Case No. 2004037295) 🙂

regards

Thomas

[adaikkap]

Thanks thomas, Now you will get prompt responses from me

Regards

adai

[brauntvr2swiss]

Hi Adai

Do you have Solution yet for this "little Problem"

regards

Thomas

[brauntvr2swiss]

Hi Adai

I have read a discussion about the hidden option resize_up_only. In my Case set to 1 would be a solution,

Because Mirror Node would not try to make snapmirror destination smaller than the source Volumen (because no resize down happen), correct?

Are there different Sizing Settings for DSS Backup Node and DSS Mirror Node. When yes I could set different Values to avoid the "smaller than" Issue

Regards

Thomas

[adaikkap]

Hi Thomas,

     The resize_Up_only cant be tuned. Also the DSS for Backup and Mirror Node is controlled by the same option.(dpDynamicSecondarySizing).

As said earlier this message should  go away in your next subsequent update. Are you still seeing the issue ? IF you think this message shouldnt be marked as Warning pls do open a RFE.

Regards

adai

[brauntvr2swiss]

Hi Adai

Thanks for your response... Sometimes the Issue happens sometimes not. I think everytime the Backup Node gets resized down, the warning on the Mirror Node comes Back.

My last question in this thread is: Where do I open a RFE?

Thanks a lot for your explanation

Thomas

[adaikkap]

Hi Thomas,

     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 ?

Regards

adai

[brauntvr2swiss]

Hi Adai

Like you have suggested, I have open a Case for a RFE. The Number ist 2004125420....

Thanks for your help

Thomas

[gdefevere]

Hi Adaikkappan ,

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 ?

KR, Geert

[jonfraley]

We are having the exact issue you were having.  Have you figured it out?

Jon

[MIP_GMT01]

I am also getting SM failed because of error "destination volume is smaller than source" after secondary volume resize. Has anyone found a fix for this?