Hi,

I've read in one of the EMC documents that the only differences between thick and thin LUNs are the thin lun allocates more space in 8KB chunks while thin ones in 1GB chunks so on the thin one your data in case your filesystem is more scattered. Also thin does not reserve space from the pool while thick does. I believe the only impact is performance and you will not get data curroption if you use thin LUNs for file.

I was told by an EMC engineer over the phone you can migrate file LUNs only if the underlying disks are the same and in the same raid configuration as the filer will create its own volume/slice structure you don't want to change.

So as the safest bet I would recommend introduce thick LUNs into the filer's pool and create new file-systems on it and use file-system migration within the VNX. The big question is how would you tell AVM to use only thick LUNs for the new file-system.. I seem to remeber AVM is trying to locate and use thick luns prior to thin ones while it wants to allocate space for a file-system/extentions. SO if this is true you could just create a new filesystem and migrate the data onto it and remove the old file-systems and then when the underlying thin dVols are not in use you could remove them.

Please take the above as theory and with a pinch of salt. I'm far form an expert but in the same shoes as you with thin LUNs in filer pool which I'm also trying to turn into thick.

Of course – as with any other client OS – there is a risk with thin LUNs if your pool runs out of space

File systems don’t understand if blocks that were promised to them cant be written to and generally respond with a panic

Thank you.  Your advice on how to convert the system would definately work.  A user defined pool could be created, and the filesystems can be migrated offline.  According to the Nas Support Matrix you should avoid mixing thin and thick luns in the same file-system, so i assume that means that thin luns are supported and should not cause corruption.  If it is only in the best practice guide for performance reasons, I may choose not to change the configuration, since i was aware of the performance penatly for using thin when it was configured, and there is not a problem with performance today.

All it says in the support matrix is do not mix thin and thick luns in the same filesystem. 

Pool based LUN Support for VNX Gateways and Arrays

 One AVM system-defined virtual pool is automatically created for each visible VNX Pool during

regular diskmark process.

 Pool LUNs are managed during regular disk mark and delete operations.

 Recommend homogeneous data services in a pool that will be used for NAS LUNs.

 Do not mix thin and thick LUNs in the same file system

 Cannot mix mirrored and non-mirrored LUNs in the same pool

 Recommend against using compression for any NAS LUNs

 Otherwise, VNX storage array rules and best practices apply.

The Nas Support Matrix can be found On powerlink

Home > Products > Hardware/Platforms > VNX Family > VNX Series > Matrices

You have mentioned the NAS support matrix. Where is that? I could actually run into a situation very soon to expand a file-system resides on a thin lun onto a thick one. So within the file-system would spread accross thin and thick luns mixed. Is that something would cause corruption or just adverse performance or AVM would potentially refuse to extend the file-system?

Yes – the best practice is to use thick LUNs for file (NAS)