HPE Storage Users Group
https://3parug.com/

Giant USR RVSD on tdvv
https://3parug.com/viewtopic.php?f=18&t=3204
Page 1 of 1

Author:  thebossbaby [ Mon May 27, 2019 2:25 am ]
Post subject:  Giant USR RVSD on tdvv

Hi 3par Admins,

I've got a tdvv with a USR RSVD space that is more than double the used capacity. What would be the best way to reclaim this space without down-time? Should I do a tunevv to another cpg?

showvv output as follows:

----Adm---- ---------Snp---------- -------------Usr-------------
---(MB)---- --(MB)--- -(% VSize)-- ------(MB)------ -(% VSize)-- ------(MB)------ -Capacity Efficiency-
Id Name Prov Type Rsvd Used Rsvd Used Used Wrn Lim Rsvd Used Used Wrn Lim Tot_Rsvd VSize Compaction Dedup
41 VM-VOL4 tdvv base 25323 24546 0 0 0.0 -- -- 10089691 4922333 85.4 0 0 10115014 5767168 1.2 1.1
----------------------------------------------------------------------------------------------------------------------------
1 total 25323 24546 0 0 10089691 4922333 10115014 5767168 1.2 1.1

Attachments:
showvv id 41.JPG
showvv id 41.JPG [ 39.02 KiB | Viewed 14896 times ]

Author:  MammaGutt [ Mon May 27, 2019 2:46 am ]
Post subject:  Re: Giant USR RVSD on tdvv

Please add some more details about your system.

If this is tdvv1 or tdvv2, that number might not be real. And trying do to something with that single volume on a big DDS might not give you what you are after. (Volume might shrink but DDS is still the same)

Author:  markinnz [ Mon May 27, 2019 4:10 am ]
Post subject:  Re: Giant USR RVSD on tdvv

We had similar problems with early versions of 3.2.2 code (pretty much the release code), 300giB volume reserving 16TiB :-)
After the array crashed badly HPE put some patches on, told us not to use de-dupe and tunevv'd everything to a new CPG, and I never saw the issue again.

What code level are you on ?

Author:  thebossbaby [ Mon May 27, 2019 10:06 pm ]
Post subject:  Re: Giant USR RVSD on tdvv

MammaGutt wrote:
Please add some more details about your system.

If this is tdvv1 or tdvv2, that number might not be real. And trying do to something with that single volume on a big DDS might not give you what you are after. (Volume might shrink but DDS is still the same)


3par: 7200
Firmware: 3.2.2.709 (MU6)+P99,P115,P119,P126

Can you please tell me how to find out if the volume is tdvv1 or 2? I've tried running showcpg -d and looking in the CPG section of SSMC but there were no info which indicated what tdvv version I was on.

If I tune a tdvv or tpvv into another CPG, will that cause any down-time? I recently converted a tdvv into a tpvv into the same CPG and it appeared to have no system impact. Just wondering if the same would apply if moving it to a different CPG.

I just want to release some of the reserved space on this particular volume as I'm currently in the process of re-organising data so that I can have enough space to convert all my TDVV into TPVV and ultimately release the DDS.

Author:  thebossbaby [ Mon May 27, 2019 10:10 pm ]
Post subject:  Re: Giant USR RVSD on tdvv

markinnz wrote:
We had similar problems with early versions of 3.2.2 code (pretty much the release code), 300giB volume reserving 16TiB :-)
After the array crashed badly HPE put some patches on, told us not to use de-dupe and tunevv'd everything to a new CPG, and I never saw the issue again.

What code level are you on ?


3.2.2.709 (MU6)+P99,P115,P119,P126

This is basically what HPE were telling us, minus the patch installations. They basically told us to tune everything to a new CPG and not use de-dupe (as we were only seeing a saving of 1.1).

The problem is that we have a lot of important files on this SAN and we're trying to move as much as we can in order to tune everything away from de-dupe. This would require a large amount of free space, unfortunately.

I really wish HPE would provide us with a better solution that didn't involve down-time or spending more money on storage when we don't need that extra storage.

Author:  MammaGutt [ Tue May 28, 2019 12:38 am ]
Post subject:  Re: Giant USR RVSD on tdvv

You have tdvv1.

That means that the number you are seeing is a weighted/assumed number for the VV that in some cases could be completly off.

I'm in your shoes as well and would have really liked another/better solution, but I guess they understood that themselves by developing tdvv2 and tdvv3. Not always easy to fix mistakes done in the past, but at least it's fixed in the future.

The 7000 is getting closer and closer to the grave when HPE stops selling addons next year, and the final nail in the coffin when they stop supporting it in 2022.

Page 1 of 1 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/