Reserved User size more than 100%

[PiRo]

I'm on the same company as mija and we have tried alot of thing. The strange thing was that the 10GB test volyme was filled to 50% and then we removed those files and started to run sdelete. After that the volumed growed to 110%.

We also tried to delete the volume in Windows (2008R2) and create it again with both quick format and normal format and we see no differences at all on the numbers on the 3Par and that volume.... we have an level 2 HP case on it now.

[Richard Siemers]

It appears Microsoft has thrown a curve ball... pay close attention to your sdelete version and the output of /?

sdelete versions BEFORE 1.6 use the -c option to zero and -z to clean (which seemed backwards).
sdelete versions AFTER 1.6 use the -z option to zero instead, and -c to clean.

Make sure you use the switch that your version describes as "Zero free space (good for virtual disk optimization)" and not the one that is described as "Clean Free Space".

"Clean" in this context means a secure erase which will fully allocate the volume.

[kwalters]

I have the same problem on a physical W2K8R2 server. MSFT Premier Support said SDELETE would work, though testing has shown otherwise. I am using v1.61 of SDELETE. The output of sdelete /? seems to have changed a bit. I have used both switches -c and -z separately and together. My VV has zero detect enabled. I use IOMETER to fill of the disk, and then delete the file (which is too big for the recycle bin, so it deletes permanently). I have a 7400 running 3.1.2 MU2.

C:\Users\kwalters\Downloads\SDelete>sdelete /?

SDelete - Secure Delete v1.61
Copyright (C) 1999-2012 Mark Russinovich
Sysinternals - http://www.sysinternals.com

usage: sdelete [-p passes] [-s] [-q] <file or directory> ...
sdelete [-p passes] [-z|-c] [drive letter] ...
-a Remove Read-Only attribute
-c Clean free space
-p passes Specifies number of overwrite passes (default is 1)
-q Don't print errors (Quiet)
-s or -r Recurse subdirectories
-z Zero free space (good for virtual disk optimization)

I will log a call with HP and ping MSFT again and see if they can come up with anything. I am not worried about the whole %Virtual > 100, but I would like to reclaim unused space when host drive utilization changes dramatically. *

[Richard Siemers]

What command are you using to monitor and measure the effectiveness of the zero reclamation?

[Cleanur]

From the earlier posts (screenshot) it appears people are looking at "Reserved User Size" which is actually a region of the logical disk layer backing this volume, instead you need to be looking at "Used User Size". To add the column to the GUI you need to right click on any one of the columns above the VV, select "Show" from the popup menu and then select “Used User Size”.

When the zeroes destined for the volume hit the ASIC the array will deallocate "Used User Size" in 16KB increments in real time back to the volume. The "Reserved User Size" will remain in place for a period of time until the array decides to reclaim this back to the CPG (128MB Increments) and eventually with a Compact CPG back to the array as a whole.

The "Reserved User Space" isn't immediately returned since this likely requires data be reallocated in a shared CPG to obtain 128MB's of contiguous zero's and it's very likely that the same volume will attempt to grow space again in the very near future so it's reclaimed periodically as a background task.

Obviously this ongoing growth doesn't typically apply to test scenarios, the concepts guide covers some of this and I'd encourage you to take a look. "Reserved User Size" will never drop below a 4GB per node pair boundary once this capacity threshold is crossed, this is to ensure the data blocks for an existing volume have a wide enough spread to maintain performance even after data deletion.

If you want to monitor the reclaim in real time you can also use the CLI
showvv –s
look to the right under the "usr" column, "% VSize" column, "used" and you should see this reducing.

There's also a good white paper available on TP http://h20195.www2.hp.com/v2/GetPDF.asp ... 987ENW.pdf

[kwalters]

I am using the UI. At first I was looking at Reserved User Size, since that is what starts at 0 and then moves up as you fill the disk. I then added the Used User Size. Used User size always stays around .05 regardless of whether not the VV is full or empty.

I gave the beast a day or so to reclaim the space, no change.

I will check out the white paper as recommended.

Thanks

ken

[kwalters]

I tried it again using the CLI to monitor reclamation this time and you could clearly see the two columns labeled "Used" drop significantly while SDELETE -z was running. No change in the UI, not sure what is up with that, but I can see that it is doing something now. SANMGT_PROD_VOL002 had been full at the host with 10GB before the SDELETE on VOL002. I used IOMETER the fill the disks, which read 10GB used on the host. Neither VV in the 3PAR CLI ever exceeded this 2713 Used or 26 Used you see in the screenshot. I guess that is the 3PAR zero detection feature in action and IOMETER was writing a lot of zeros. Thanks for your help.
Ken

[scoggins]

This looks to be the same issue we hit. We can't reclaim space anymore no matter what mechanism we try. Apparently there is a bug in the defrag/house cleaning that stops the reserved space being reduced and returned to the CPG. I logged a case and it took me about 9 months but they finally acknowledged it was a bug and claim that the fix has been added to 3.1.3. I've checked the 3.1.3 release notes but I can't see any mention of it so I need to get some confirmation before I look at upgrading.

But yes, this is a huge pain. We currently have doubt 5TB of reclaimed space that isn't being released back to the CPG for compacting..

[Cleanur]

Not aware of this being a bug, I demo this regularly, although depending on how long the space has been in use and how its been "used and abused" (fill / delete / fill / delete testing etc) it can take time to defrag before it can be returned to the CPG for reclaim to the pool via a compactcpg. This part of the reclaim is designed to be non intrusive to I/O so fragmentation runs against lots of data may take multiple passes. Biggest problem I encounter is people trying to test this feature without fully understanding the process, which IMHO hasn't been too well documented, hopefully this will be better documented going forward.

If you want to circumvent the background defrag and just do this upfront you can convert the offending volumes from thin to thick and then back to thin. This will force a defrag and return the space immediately. However you need to ensure you have the Dynamic Optimization license and enough physical free space to accommodate the conversion to a fully provisioned volume.

[Richard Siemers]

This is more theory than knowledge... but does it make sense for the array to give back 100% of the space? Could that not lead to a back and forth condition that causes excessive fragmentation?

I *assumed* the space left over after a thin reclamation in the VV is to accommodate any new writes contiguously.