Converting Thick LUN to Thin, help required

[RamsdensIT]

Hi everyone,

Currently when i joined my company they configured the filer with a strictly thick provisioned setup. I'll like to change a lot of these to Thin to free up space and organise the data more effeciently but I'm conserned as to the effects this might cause. Can i get your opinions and advice on the best way to handle this.

Current Setup

PUBLIC drive is provisioned as THICK lun using up all the avaliable space on the filer

Proposed setup

Multiple Thin luns, overprovisioned seqmenting the departments across individual luns to control usage and access.

I'll like to change the PUBLIC drive to a thin, this would immediately free up TB's of space, i could then create another LUN and copy data from the PUBLIC lun to this one. I'm not sure if you can change THINK to THIN and if could loose data doing so.

Can anyone help me with this?

Nathan

[ekashpureff]

Nathan -

Yes, you can do that,

You can do that on the fly with no data loss.

But you should understand the dangers involved.

(If you do run out of space it can be a bad thing !)

In my environs I use 'extreme' thin provisioning.

I set the volume level guarantee to 'none' for NAS and SAN.

This has the effect of disabling space guarantee for LUNs on the volumes.

There are many other ways to manage thin provisioning in Data ONTAP.

You probably want to read through some of the TRs on thin provisioning that may be found at www.netapp.com/library

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.
Independent NetApp Consultant http://www.linkedin.com/in/eugenekashpureff
Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp
(P.S. I appreciate 'kudos' on any helpful posts.)

[bobshouseofcards]

Hi Nathan -  

Eugene has already given you really good advice and I second all he mentioned.  I'll add one item associated with your specific plan.  If you convert the LUN in question from thick to thin, you may not recover any space to create a second LUN.  Let me explain.

Because it's a LUN, the client operating system controls allocation of blocks within the LUN.  Consider how DoT sees it.  Let's start with a simple case for illustration.  Let's assume a LUN that only contains 10 data blocks.  The client OS writes a file that needs 2 blocks. DoT sees 2 blocks have been written.  If you switched from thick to thin at that's moment, since only 2 blocks have ever been written, 8 blocks are physically available for use other LUNs like you want.  So you create another LUN and maybe do some copying or whatever.

Now consider the case where three such files have been created, so 6 total blocks are used.  Then you go and delete all the files.  Now you switch from thick to thin.  How many blocks do you get back?  Answer is 4.  Because the blocks in the LUN were once in use, DoT has no way to tell that they aren't still in use.  The client OS logically knows that those blocks don't contain any meaningful data, but DoT doesn't.  

Why is this important?  Consider a 4TB LUN.  The OS thinks it is 1TB in use because files have been created, destroyed, added, deleted over a long time.  Question is over that time, how many unique blocks have ever been written to by the client OS using whatever allocation scheme the client has for its file system?  Assume that 3.5TB worth of unique blocks in the LUN have been written over time, even though at the moment only 1TB worth, per the OS, actually contain useful data.  Switch that 4TB LUN from thick to thin and you only get back 0.5TB - the sum of e blocks that have never been used in the LUN.  

It's only been in the DoT 8.2 code line that support has been added for SCSI UNMAP (the general LUN equivalent of SSD TRIM), and even if you retrofit it in it only affects deletes done in the client OS after support has been enabled.  I've been in this situation where to "generate" free space after marking the LUNs to support UNMAP (a disruptive event since you have to cycle the LUN offline to make it take affect) by artificially creating large files in the LUN and then deleting them for legacy LUNs I couldn't just recreate from scratch.  

This is same situation doesn't apply where DoT is your file share directly via CIFS or NFS.  Then, since DoT is both the file system and the disk manager, it knows exactly what blocks are in use if you switch from think to thin.  LUNs are a special case because the contents of the LUN are opaque to Data OnTap, by design.  Be sure to take this into consideration when you plan how much space you expect to get back when you convert.

Hope this helps you.

Bob Greenwald

Lead Storage Enginer

Huron Legal | Huron Consulting Group

NCIE - SAN Clustered, Data Protection