2012-08-01 07:55 AM
I've been setting up some thin-provisioned LUNs for a customer who has then gone on to perform a full format on the LUNs from Windows 2008R2. This actually zeroes out the disk and thefore the LUN is showing full allocation within the volume.
I had set things up like this:
Volume: space guarantee - none and twice the size of the LUN (one LUN per volume)
Now the volumes are showing as 50% full because the LUNs have been fully formatted.
I'm wondering what will happen the first time a snapshot is taken and what will happen when actual data is added (i.e. SQL databases). I'm going to do some testing myself but I wondered if anyone would explain the mechanics of what will happen.
Is there any point in keeping these LUNs thin-provisioned now that they are technically fully allocated? What about the volumes? Shoud I go back to the 2 x LUN size plus space for snapshots now?
Currently there is enough space in the aggregate to honour all the allocated space but I'm worried that a volume only 2x the size of the LUN will not be enough now.
Thanks for any advice
Solved! SEE THE SOLUTION
2012-08-01 08:53 AM
The obvious answer - do not do full format on thin provisioned storage (any type, any vendor).
Do space reclamation to return unused space on filesystem back (requires SnapDrive).
Mechanics of what happens is explained in full details in TR-3965.
2012-08-01 01:23 PM
Nope, it was never my intention for them to be fully formatted and I didn't expect that they would be. However, we provided LUNs for a customer and technically they can do what they like with them from the Windows side. They cited performance reasons, apparently performing a quick format is not good enough...
SnapDrive is not installed.
Either way, it's done now so I have to deal with it. I will read the TR you mentioned, it looks very helpful.
2012-08-01 09:27 PM
besides doing a full format, a lun will fill up to 100% over time anyway unless you run snapdrive space reclaimer. ontap just doesnt know which blocks were actualy deleted from the operating system and which contain valid data. snapshotting isnt an issue as long as you have enough space and either volume autogrow or snap autodelete.
I havent tested myself but isnt a format supposed to write plenty of 0´s to the disk and ontap realizes this as sort of "zero´d disk space" and doesnt fill up? Which ontap are you using?
2012-08-01 10:02 PM
I havent tested myself but isnt a format supposed to write plenty of 0´s to the disk and ontap realizes this as sort of "zero´d disk space" and doesnt fill up?
I have never heard about it. Of course, using A-SIS is one possibility to reduce physical space consumption, it will do exactly what you mention
2012-08-02 01:29 AM
We're using OnTap 8.0.2. Prior to the LUNs being formatted, volume usage was 0%, i.e. 100g volume with 50g LUN = 0% usage. After a full format, usage went to 50% with no data on the LUN.
I could try A-SIS, currently it's only in use on the NAS volumes (with great success) but I hadn't considered using it on volumes containing LUNs.
I will also make sure that volume autogrow is configured correctly.
2012-08-02 08:20 AM
Fractional reserve is reported as zero on all the volumes. I guess the point of my question was to make sure that I do understand the implications. Currently, I do not but I'm reading as much as I can to make sure that I do.
2012-08-02 10:30 AM
Like your name, your description indicates something that is fairly healthy. A thin volume will only account for the blocks that are used. The fully zeroed LUN is reporting the used blocks back to the volume. If you have "Snapshot Thin Provisioning" configured (i.e. snap autodelete AND autogrow, as mentioned above) then here is what happens:
First snapshot freezes all of the used blocks in the volume (the entire LUN). When new writes occur, space in the volume will be consumed to provide space for those writes (this is why the snap reserve is irrelevant in this config; *all* of the space is meant for redirected writes after snaps [unless one does the sacrilege of adding other data to this volume--set it to 0).
As additional snaps continue to freeze blocks, the remaining space in the volume will continue to be consumed for new writes. At a particular percentage threshold (~above 85%; adjustable), snap autodelete will begin removing snapshots to free up blocks that were previously frozen. Autogrow is important: once a percentage threshold is crossed, this will automatically grow the volume to provide additional blocks to be used for new writes.
A thin volume, in this scenario, makes all the blocks discussed (i.e. all that are not in the original frozen LUN) available to the aggregate to offer to other volumes. Once you get to the point where you are exhausting the supply and growing the volume, the thin thing makes no difference.
Does this sour you... or make you shake? : )
2012-08-03 08:36 AM
Many thanks for your reply, your explanation helps a lot. It's good to read stuff in manuals but it's nice to have someone explain things in normal speak! I will be carefully checking my auto delete and autogrow settings accordingly to make sure the LUNs don't run out of space.
Incidentally, my user name is actually based on the Dairy Milk chocolate bar as I was eating one when I was trying to think of my user name! I was probably drinking milk at the same time though as I find they go together well
Have a great weekend