HPE Storage Users Group

I am planning for a conversion from fat to thin volume on the T800 Inserv. It's a three step process, to plan, prepare (write zeroes on the file system) and do the conversion.
I will be using IMC GUI 4.4.1 to complete the conversion. The array is running on 3.1.2 InForm OS.

My Questions are:
1. Should i have to enable the zero_detect on the VV after the conversion is complete?
2. If one VV has been exported to more than one Host, how should i approach the conversion process?

I do apologize if i was not clear with my question, i will try and be more elaborative. Please review and any input is greatly appreciated.

From the 3par array, all the virtual volumes (LUNS) that were exported to the host are Fully Provisioned (thick/Fat) VV's. The volumes need to be converted to Thin to optimize the utilization. The conversion from Fat to Thin is a three step process:
1. At Planning stage - we will evaluate/quantify the amount of free space on the File system/ LUN.
2. At Preparation Stage - A host application is used to write zeroes on the unused or the free space on the file system.
3. At Conversion stage - we convert the volume from fat to thin on IMC, GUI.
I will be using IMC GUI 4.4.1 to complete the conversion. The array is running on 3.1.2 InForm OS.

Once the conversion is complete, the Thin Persistence feature on the array will identify the zeroes written to that LUN and does not allocate any physical storage to it.

I would like to know:

if a VV has been exported to a cluster servers (3 in a cluster), if the changes are made to a VV on one of the host, does the same changes get applied to the rest of the hosts?
How does this work?

> From the 3par array, all the virtual volumes (LUNS) that were exported to the host are Fully Provisioned (thick/Fat) VV's.

What kind of volumes?
Which file system?
OS connected?
Data type stored on those volumes?


> 1. At Planning stage - we will evaluate/quantify the amount of free space on the File system/ LUN.
OK.

> 2. At Preparation Stage - A host application is used to write zeroes on the unused or the free space on the file system.
I think that in most cases this step might be waste of time and you can skip it.
This is assuming that most "dirty" blocks will get overwritten again over time.
I haven't done any testing about this - just my general assumption.
I think that thin provision is a good thing, especially for disk space that is left untouched - for example free space on a virtualization volume where no virtual disk is using it, or within the guest VM.
I don't think that you should aim to get the most saving out of thin volumes, eliminating wasting space for never yet touched blocks (not dirty blocks overwritten by zeros) is good enough for me.

> 3. At Conversion stage - we convert the volume from fat to thin on IMC, GUI.
OK.
I suggest that large volumes will be converted one at a time.

> Once the conversion is complete, the Thin Persistence feature on the array will identify the zeroes written to that LUN and does not allocate any physical storage to it.
Not exact.
Zero detection works on the fly during the conversion and not as a second process afterwards, as far as I know. You just need to enable it when initially converting the volume.


> if a VV has been exported to a cluster servers (3 in a cluster), if the changes are made to a VV on one of the host, does the same changes get applied to the rest of the hosts?
Which king of cluster?
Which kind of "changes made"?
If you mean changes to the data, so general answer is yes, this is how a cluster works, and the hosts participating in the cluster use some kind of locks.
If you ask about the conversion - this is transparent to hosts, read on...

> How does this work?
The conversion from fat to thin is transparent to the hosts, happens on the 3par backend and the hosts are not aware of it.

Yizhar