If you aren’t familiar with thin provisioning, it’s a technology being widely adopted by storage vendors that only allocates back-end disk space to a LUN when data is written. For example, if you present a 500GB LUN to a server and only write 100GB of data, the array only uses 100GB of disk space. The remaining 400GB can be used by another server, or the same server when more data is written.

But what happens when you delete the data? With many arrays the space is still allocated to that LUN and not put back into the ‘scratch’ pool for future re-use. Depending on your data access patterns, you may end up with a lot of trapped capacity. Thin volumes can gain weight and become fat..like much of America!

Several vendors such as EMC, Hitachi and 3PAR have updated their arrays to reclaim some of this trapped capacity. They do this by detecting chunks of zeros and tossing those chunks back into an unallocated storage pool. Since we use a 3PAR array at work, I decided to put their Thin Persistencefeature to the test.

Unfortunately I can’t post screen shots since I don’t have an array at home and this is my personal blog. So you will have to take my word for the results. Listed below are the high-level steps that I took to perform the test.

1. Provisioned a new thin-provisioned virtual volume of 100GB in the 3PAR T400.
2. Enabled zero-detection on the volume (simple GUI check-box).
3. Exported that virtual volume as a LUN to a Windows Server 2003 R2 physical server.
4. Formatted the new LUN with the NTFS file system and assigned it a drive letter.
5. Copied 90GB of data into the new volume and verified in the 3PAR InForm Management Console that it showed approximately 90GB capacity utilization for that volume. Check, it did!
6. Deleted 40GB worth of data from the LUN, so 50GB was remaining.
7. Executed the MS Sysinternal tool “sdelete” with the -c option to zeroize all unused disk space.
8. I then monitored the volume’s utilization in the 3PAR InForm management console, and it slowly dropped as the sdelete command was running.
9. By the time the sdelete command finished, the volume utilization was down to 50%, matching the 50GB of still used disk space. 40GB of space has been reclaimed.

This test proved that the 3PAR zero reclaim feature worked as advertised, happens in real time, and take very little effort to use. The same process would work for a virtual machine as well. If I was using the Veritas Storage Foundation I would not have to use the sdelete command and it would be fully automated. Hopefully they will work with Microsoft and VMware to support a fully automatic and native method to reclaim the deleted space. Until then, you can run sdelete from time to time to drop those extra pounds from your fat LUNs.