Solved!
Go to SolutionP
Pablo_Szajt
11 Posts
0
3072
April 28th, 2010 13:00
Thin LUN "Consumed Capacity" shows unaccurate info
Hi,
I'm pretty new in the EMC world. We just bougth a couple of CX4-480. We are using Flare 29 basicaly to take advantage of the Thin Provisioning feature, which looks really nice, but encountered a couple of issues.
One of them, is that if I release data on the server side (Windows 2003), Navishpere will not decrease "Consumed Capacity".
I was able to probe it doing the following:
1) On the Windows server, copied 10 GB to a new 50 GB Thin LUN. Results: Consumed space 12 GB since 2 is overhead.
2) Deleted 9 GB. Consumed space still 12 GB.
3) Copied 4 GB. Consumed space still 12 GB.
4) Copied another 4. Consumed space 13 GB.
5) Copied another 8. Consumed space 17 GB.
Is anybody having the same issue?
I'd like to be in contact with people who has some experience with This Provisioning on CX4.
Thanks,
Pablo
1041
1
Posted April 29th, 2010 01:00
AFAIK capacity that is once used cannot be taken back, so if a block is written, space is consumed on the thin LUN. If you delete the data from dat block, the Clariion doesn't know that, it only sees blocks that the host has once written to. If you overwrite old block, nothing changes, if you write to new blocks, more capacity is used.
1041
0
Posted April 29th, 2010 07:00
This is exactly what is happening. Does not make any sense to me.
If Clariion knows when a server needs a new block, why does not know about a deletion? It's probably a design issue.
The whole idea of Virtual Provisioning is to buy time oversubscribing. But you don't want to reach a point where you will be out of space, so, you need to manage "consume capacity".
My question now is how can I manage the real consumed space? I guess I can not.
Thanks a bunch for your answer,
Pablo
1041
1
Posted April 29th, 2010 07:00
Pablo,
i do not know if this functionality is available in Windows 2003 but it Windows 2008 you can shrink LUN size in the OS using VDS ..and then it should allow you to shrink LUN size in Clariion. Take a look at this paper
1041
0
Posted April 29th, 2010 08:00
Hi Dynamox,
Thanks for the interesting paper. I've just read it.It looks like it works with FAT LUNS, not with Thin LUNS. Do you agree?
Thanks again,
Pablo
1041
0
Posted April 29th, 2010 09:00
ah yes ..no support for shrinking thin LUNs. Bummer
1041
0
Posted April 29th, 2010 12:00
Aran,
according to this you can shrink LUN size in Clariion
emc230411
1041
0
Posted April 29th, 2010 12:00
Yeah,
I can see what you are saying. What a shame anyway.
What Dyname ad you are saying makes perfect sense now.
Thanks,
Pablo
1041
0
Posted April 29th, 2010 13:00
Correct me if I am missing the point, but is that necessarily what is trying to be accomplished here? We are talking about the consumed capacity of a thin provisioned LUN not the size of the LUN that was provisioned right? If the thin LUN is 100GB, the application consumed 20GB then 10GB of data was deleted, the consumed capacity is still 20GB. Shrinking the LUN would be going from a 100GB thin provisioning to 50GB or 20GB provisioned LUN. So to recclaim that 10GB of space from the deleted application data you would have to shrink the 100GB LUN to 10GB, then expand it again so that the application can grow.
358
0
Posted April 29th, 2010 14:00
i was thinking of the ability to shrink the consumed space. If NTFS volume grew to 20G, you deleted 10G worth of data ..now shrink the NTFS volume and lun to 12G ..thus releasing 8G back into the pool. Am i completly off here ?
Message was edited by: dynamox
AranH1
2163 Posts
1041
0
Posted April 29th, 2010 10:00
Pablo,
It is not an issue with the CLARiiON array, as the operating system has initialized and written to the blocks that caused the size of the consumed space to increase. Deleting the data from those blocks on the server just marks those blocks as free on the file system but does not release those blocks from the array. NTFS is not shrinking the blocks that it has initialized and written to so the array will not see that the consumed space is reduced at all. Rember that a block array is not file system aware, so once the space is initialized it will not shrink.