NetApp slims for Storage Foundation

Goes on thin reclamation diet

By Chris Mellor, 5th August 2010

Magic Quadrant for Enterprise Backup/Recovery

NetApp is supporting Symantec's thin reclamation API, almost two years after it was announced.

Symantec announced its thin reclamation API as part of a Veritas Storage Foundation update in October 2008, with 3PAR first off the block in supporting it. IBM gave the API the thumbs up a year later. It solves a problem with thinly-provisioned block storage in that when files are deleted by a host server the storage array providing the storage doesn't know anything about it.

With thinly-provisioned storage a host server application only consumes storage as it writes data. Although it has a logical allocation of, say, 10TB, it has written 5TB of data and that is all it's actually given by the storage array, driving up disk utilisation. If that application then deletes a 250GB file it remains allocated by the storage array, sending disk utilisation down again. Cue the host running Veritas Storage Foundation software, and it sends a message to the array, using the thin reclamation API, which then hunts down the deleted file, reclaims the space and returns it to its general storage pool for use elsewhere.

NetApp calls this hole punching and had introduced a host-based deleted file space reclamation facility with SnapDrive for Windows back in 2008. It wanted an industry-standard way of doing this, but that has not come to pass and so now it's going with the Symantec flow.

In these days of focus on general data reduction, having disk capacity occupied by deleted files is just silly. Symantec Storage Foundation users with NetApp arrays will now be able to increase their disk utilisation rate. The larger the IT shop and the higher the file deletion rate the more effective this API will be. ®

Agentless Backup is Not a Myth

COMMENTS

House Rules Send Corrections

All Reader Comments (1)

Highly Rated

Posted Thursday 5th August 2010 14:26 GMT

Barry Burke

Actually, standards are near

Symantec uses a SCSI command extension known as WRITE_SAME with an UNMAP flag, which T10 has (or will soon) ratify. T10 has also defined the UNMAP command which affords a bit more cooperation between initiator and target, this too is ratified (or will be soon).

Most of the industry waited until the two standards stabilized before implementing, and we should soon start seeing more file systems, volume managers and hypervisors using one or both of these APIs.

FWIW, these APIs have value far beyond just freeing up space in thin devices - Symmetrix will support these APIs for non-thin devices as well, interpreting them to mean that the UNMAPped blocks need no longer be replicated (for example).

Also, as with the SATA TRIM command, some Flash drives will support these APIs as a means to improve performance by freeing up blocks that are no longer needed...