Huge mirrorclone disadvantage

[zxcv]

Hi ,

We have EVA6400 in our setup with 28TB of storage. 1 DG

Recently we had implemented mirrorclone for 16 of our clients .

Yesterday morning one hdd failed, which we replaced it by evening .

Then when my support team fired mirrorclone the RSM script just got halted at Wait for Storage Normalization.

Now the DG levelling will take another 3-4 days.

what is the solution for this ?

We created two scripts like below ;

1] 

// Replicate storage volume(s).
// Assign some variables that will be used in this jo
Launch ( "ganesh", "/var/hp/BC/scripts/gb/gb_pre_bc_script_dbday", "", WAIT, "0" ) onerror goto E2:
//
UnpresentStorageVolume ( "\\EVA-6400\Database\GB\Vdisk_GB_DB_100\Mirror of Vdisk_GB_DB_100", "gesh", HOST_FC_PORT ) onerror goto E3:
//
ResyncMirrorclones ( ("\\EVA-6400\Database\GB\Vdisk_GB_DB_100\Mirror of Vdisk_GB_DB_100") ) onerror goto E4:
//
//
Launch ( "hma", "/var/hp/BC/scripts/gb/gb_begin_bkp_mode_dbday", "", WAIT, "0" ) onerror goto E2:
//
// Success

2]

// Replicate storage volume(s).
// Assign some variables that will be used in this jo
//
FractureMirrorclones ( ("\\EVA-6400\Database\gb\Vdisk_gb_DB_100\Mirror of Vdisk_gb_DB_100"), WAIT ) onerror goto E6:
//
Launch ( "hma", "/var/hp/BC/scripts/gb/gb_end_bkp_mode_dbday", "", WAIT, "0" ) onerror goto E2:
//
PresentStorageVolume ( "\\EVA-6400\Database\gb\Vdisk_gb_DB_100\Mirror of Vdisk_gb_DB_100", "gesh", 27, READ_WRITE, HOST_FC_PORT ) onerror goto E3:
//
Launch ( "gesh", "/var/hp/BC/scripts/gb/gb_post_bc_script_dbday", "", WAIT, "" ) onerror goto E2:
// Success

Between 1 and 2 i have asked them to manually fracture the mirror disk .

But why is DG levelling coming into picture for Storage Normalization  ??

[zxcv]

Hi ,

FYI we had snaplcones earlier , which had no problems when such HDD failure incident occured.