3PAR's 'thin' technologies: Part 2

Thin Persistence reduces the space consumption of a thin provisioned virtual volume in real-time


For 3PAR, staying thin is more than just thin provisioning. It's keeping storage volumes thin and being able to reclaim storage space. 3PAR introduced its 'thin' strategy earlier this week at Storage Networking World. This newsletter discusses Thin Persistance, Thin Copy Reclamation and Thin Copy Reclamation with Veritas Storage Foundation.

3PAR's 'thin' technologies: Part 1

Thin Persistence is 3PAR's ability to reduce the space consumption of a thin provisioned virtual volume (TPVV) in real-time, results in reduced storage costs by allowing thinly provisioned volumes to stay 'thin' – it's like putting your storage on a maintenance diet and not having to worry about what the array stores -- the array will stay thin. Thin persistence enables the detection of contiguous strings of zeros to re-thin already thinned volumes. In thin persistence, standard file system tools reclaim allocated but deleted blocks in the user space and write zeros into the blocks. Freed 16KB blocks are returned to the existing volume as free space.

Thin persistence keeps a volume from growing when there are a large number of deletes and writes. Typically, applications have storage capacity that grows exponentially – for those applications, thin provisioning works well. If, however, there are applications that continually write and then delete data, thin persistence works best.

Consider this scenario: The host file system has 100GB of data written to it, an amount that is matched by the InServ volume. As data is written to the host file system it is also written to the InServ array. If 10GB of data is deleted on the host file system, the array has no knowledge of the deletion. If another 20GB is written to the file system, the file system will consume 110GB, while the storage array unaware that data has been deleted, will show 120GB. Thin Persistence can be used to reclaim this deleted space from the Thin Volumes. The significance of thin persistence is in not having to grow volumes to free up space.

3PAR's Thin Copy Reclamation feature of the InForm operating system operates much like thin persistence, except it is for snapshots rather than volumes. Traditionally, snapshot space is reserved and when snapshots are taken they are duplicative. Multiple copies of the snapshot will exist and disk space consumed. By contrast, 3PAR's snapshot technology is reservationless and does not create duplicate copies of data. Only deltas changes are created from the previous snapshot.

Thin Copy Reclamation allows free space to be regained when individual snapshots are deleted, thus reducing storage capacity costs by reclaiming storage capacity that is locked up in allocated snapshot space. When virtual or remote copy snapshots are deleted, space is reclaimed from the TPVV and returned automatically to the array for reuse by other volumes. With Thin Copy Reclamation, the entire snapshot is returned to the common provisioning group (CPG). The difference from thin persistence is that space from retired or deleted snapshots can be deleted without the process of sweeping for zero-filled space.

When virtual, full or remote copy snapshots are deleted, freed contiguous 128MB blocks are reclaimed from the TPVV and returned automatically to the CPG for reuse by other volumes.

3PAR worked with Symantec on a Thin Reclamation API that allows a host file system to intelligently communicate with the InServ to reclaim space associated with file deletions. This new software product from 3PAR is designed to enable InServ arrays to use granular file system-level information to autonomically reclaim unused space within thin InServ volumes so that they stay thin over time.

Space reclamation uses the 'write same' SCSI command and requires Version 5.0 MP3 of Veritas Storage Foundation and a 3PAR Thin Persistence license for the InServ Storage Server. Thin reclamation for Veritas Storage Foundation differs from Thin Persistence in that an administrator does not need to mark deleted space with zeros. The server administrator on the host issues a command and deleted block information is sent to the InServ. The InServ on receiving this information will autonomically un-map the allocated space.

Learn more about this topic

3PAR's 'thin' technologies: Part 1

Cloud computing model suits economic decline: 3PAR

3PAR puts more storage efficiency smarts into chip

3PAR rolls out new, fast arrays

Chromebook: 6 ways it changed my life, one way it didn't
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies