Releasing dedupe data store space

[Marc.mvh.vanhoof]

We were planning for migrating 3.2.2 MU4 cpg with all deduped vv's to 3.1.1 cpg with all compressed vv's. It seem that we can't recover space from dedupe data store (DDS) until all vv were converted. Confirmed by HPE. Since we do not have enough space free to cover old dedupe cgp and new compressed cpg at the same time we are pushed to buy extra capacity.
Someone with same situation .... And maybe an other solution than buying extra capacity ?

[cali]

Did you read this:
HPE Migrating TDVV from 3PAR 3.2.1 or 3.2.2 to 3.3.1
http://h20564.www2.hpe.com/portal/site/ ... 21632en_us

[Marc.mvh.vanhoof]

Yes i did read this brand new document ... Then i became worried .

[JohnMH]

Page 19 - Migration if the system does not have at least as much free space as that allocated to the largest CPG containing a DDS on the system to be migrated.

You have to consider that shared blocks can't be released until all dependents are released (volumes), although some space will be released via garbage collection the process on TDVV2 is slow. So it requires some sizing calculations and potentially shuffling of capacity if you don't have plenty of free space available. If you have very little free capacity to work with or simply can't make the space savings then you may still need to add capacity.

Have a chat with your account team they should be able to assist with this.

[chris.black]

We are in a similar boat with our older system. It seems HPE pulled the documents does somebody have a copy they can send me?

[chris.black]

We are in a similar boat with our older system. It seems HPE pulled the documents does somebody have a copy they can send me?

Support sent me a copy, if somebody is interested I uploaded it here https://www.docdroid.net/icxmDcV/download.pdf

[anders.dicker]

Is there someone having experience on any performance impact for the final release of dedup version 2 space?

I was finally able to migrate all data on one side of a peer-persistence configuration to new dedup version 3. And now everything is running fine on new dedup version 3 LUNs. But the old CPG still has roundabout 50 TB of disk space for version 2 deduplication in use.

Is it safe to remove the last dedup volume from this CPG during normal working hours? Is a compact_cpg necessary afterwards to free up the space or do I get this disk space back instantly? Or would it be better to temporarily switch back to the other side (with all LUNs still being dedup v2), stop all rcopy groups and delete the last LUN on an idle system?

[MammaGutt]

Is there someone having experience on any performance impact for the final release of dedup version 2 space?

I was finally able to migrate all data on one side of a peer-persistence configuration to new dedup version 3. And now everything is running fine on new dedup version 3 LUNs. But the old CPG still has roundabout 50 TB of disk space for version 2 deduplication in use.

Is it safe to remove the last dedup volume from this CPG during normal working hours? Is a compact_cpg necessary afterwards to free up the space or do I get this disk space back instantly? Or would it be better to temporarily switch back to the other side (with all LUNs still being dedup v2), stop all rcopy groups and delete the last LUN on an idle system?

Once you delete the final volume in a CPG it will (at least for me) always do compact cpg. Once that is done, all the chunklets will become uninitialized and it will initialize them (similar to what happens during disk add-on without the tunesys).

I've not done anything special for the ~10 arrays I've converted from dds2 to dds3. Not had any issues yet. Largest DDS was 55TB.

[anders.dicker]

Once you delete the final volume in a CPG it will (at least for me) always do compact cpg. Once that is done, all the chunklets will become uninitialized and it will initialize them (similar to what happens during disk add-on without the tunesys).

I've not done anything special for the ~10 arrays I've converted from dds2 to dds3. Not had any issues yet. Largest DDS was 55TB.

Unfortunately it looks like I'm not that lucky.

I also had a DDS with roundabout 50 TB in the old CPG. But after the removal of the last dedup volume the DDS stayed there. And a compact cpg didn't free up space.

And then the situation got weird:

• wanted to swap the CPG names (rename CPG1 to CPG1_old and rename CPG2 to CPG1) via setcpg -name ...
• command ran fine without errors
• some hours later after checking again everything I wanted to delete the former CPG
• CPG removal was blocked because of a running DDS defrag on both CPGs
• defrag processes got stuck during the renaming action and are not returning anymore
• cancelling those tasks is not possible
• renaming CPGs back to the initial names also doesn't change anything

This is the output of the tasks so far:

Code: Select all

2021-12-08 11:25:00 CET Started     defrag process for VVs
2021-12-08 12:03:07 CET Failed      mcall_checkvv_notify: VV ".sysvv_0CPG1" invalid
2021-12-08 12:03:07 CET Updated     Sysmgr MCVV_ADMCK_NOTIFY failed with: mcall_checkvv_notify: VV ".sysvv_0CPG1" invalid
2021-12-08 12:03:07 CET Failed      mcall_checkvv_notify: defrag VV ".sysvv_0CPG1" invalid

Does anyone have some ideas on how to get rid of this annoying situation?

[anders.dicker]

I rebooted both nodes of the 3PAR sequentially and afterwards the stuck tasks had been gone.

And luckily after the reboot the DDS got automatically deleted leading to unitialized chunklets.

So despite the worrying about the "invalid" error message I'm lucky to have at least some disk space available again...