First, T10 is the INCITS governing body over SAM (SCSI Architectural Model). The SAM includes SCSI interconnects (Serial, FC, etc), SCSI Transport (SAS, FCP, etc), SCSI Primary commands (shared command set) and Device Specific Commands (SCSI block commands, Multi-media commands, etc). AFAIK, these are commands, not APIs. So, unless I'm missing something, the API doesn't fall (or shouldn't fall) into T10. The implementation of the API *could* fall into T10, if the implementation requires an extension to either the SCSI primary or device specific commands. Otherwise, no. It's not what T10 does and is out of their scope.

Thus, any standard API should fall under SNIA's SMI-S initiative. In fact, one could make the case that thin provisioning should fall under the block service profile in SMI-S v1.2 (which BTW, cannot be altered unless INCITS doesn't ratify). SMI-S v1.3 is the current working version.

But these aren't the real issue. The real issue is whether or not Symantec should have put this API in SMI-S. (Remember it was Roger Reich from Symantec who made the initial proposal to SNIA to take on a storage management initiative, which eventually became Bluefin). IMO, I don't think they should. SMI-S, for all the good it has done (created the idea of profiles for CIM, led us to a web-services management model) has thus far, failed to meet it's original objective (storage management interoperability). Can we name one console vendor (like Symantec) that uses SMI-S to manage a heterogeneous storage environment? How many providers out there instrument ALL of the manageability on the system they were written for? Better still — how many customers rely on SMI-S to manage their environment.

Yes, standards take time (believe me, I know). But how long must we wait? SMI-S was started over 8 years ago. CIM is over 11 years old. It's high time SMI-S and CIM proved the interoperability or moved on to better territory. In fact, one can make the case that “higher causes” aren't far away. Rather than defining every intricate detail within CIM and SMI-S, why not move up the management stack and define APIs at a higher level? Rather than managing the tachometer of the fan or the RAID level of a storage pool, why not create an API that is simple and service oriented? (i.e. CreateLUN (spaceRequired, redundancyLevel) ) Let the underlying implementation remain the job of the storage vendors.

First, T10 is the INCITS governing body over SAM (SCSI Architectural Model). The SAM includes SCSI interconnects (Serial, FC, etc), SCSI Transport (SAS, FCP, etc), SCSI Primary commands (shared command set) and Device Specific Commands (SCSI block commands, Multi-media commands, etc). AFAIK, these are commands, not APIs. So, unless I'm missing something, the API doesn't fall (or shouldn't fall) into T10. The implementation of the API *could* fall into T10, if the implementation requires an extension to either the SCSI primary or device specific commands. Otherwise, no. It's not what T10 does and is out of their scope.

Thus, any standard API should fall under SNIA's SMI-S initiative. In fact, one could make the case that thin provisioning should fall under the block service profile in SMI-S v1.2 (which BTW, cannot be altered unless INCITS doesn't ratify). SMI-S v1.3 is the current working version.

But these aren't the real issue. The real issue is whether or not Symantec should have put this API in SMI-S. (Remember it was Roger Reich from Symantec who made the initial proposal to SNIA to take on a storage management initiative, which eventually became Bluefin). IMO, I don't think they should. SMI-S, for all the good it has done (created the idea of profiles for CIM, led us to a web-services management model) has thus far, failed to meet it's original objective (storage management interoperability). Can we name one console vendor (like Symantec) that uses SMI-S to manage a heterogeneous storage environment? How many providers out there instrument ALL of the manageability on the system they were written for? Better still — how many customers rely on SMI-S to manage their environment.

Yes, standards take time (believe me, I know). But how long must we wait? SMI-S was started over 8 years ago. CIM is over 11 years old. It's high time SMI-S and CIM proved the interoperability or moved on to better territory. In fact, one can make the case that “higher causes” aren't far away. Rather than defining every intricate detail within CIM and SMI-S, why not move up the management stack and define APIs at a higher level? Rather than managing the tachometer of the fan or the RAID level of a storage pool, why not create an API that is simple and service oriented? (i.e. CreateLUN (spaceRequired, redundancyLevel) ) Let the underlying implementation remain the job of the storage vendors.

Thanks so much for the comment. I certainly appreciate this new API, and think it will do good for customers of Symantec, 3PAR, HDS, and HP. I hope other vendors also decide to implement it, and that it leads to a standard API in the future. And I very much hope that TSA is wrong about blowback from the API on non-aware systems!

Stephen

Thanks so much for the comment. I certainly appreciate this new API, and think it will do good for customers of Symantec, 3PAR, HDS, and HP. I hope other vendors also decide to implement it, and that it leads to a standard API in the future. And I very much hope that TSA is wrong about blowback from the API on non-aware systems!

Stephen

Enough about SMI-S; thin provisioning is a relatively new solution that IT organizations are trying to get their hands around. The capability in hardware is there (albeit with implementation details varying by vendor), but to truly maximize the TP value there must be server side awareness (file system and volume manager). Working with our partners, we’ve engineered a way for organizations to automatically, and non-disruptively, reclaim storage capacity. We’ve been very open with hardware providers (including EMC) about the Veritas Thin Reclamation API, and this has moved solutions for customers forward on a number of fronts (3Par being one case in point).

From a technical perspective, the concerns expressed by storage anarchist have been thoroughly considered and are handled by the Veritas Thin Reclamation API and Veritas Storage Foundation. Storage Foundation is specifically designed to deal with hardware specific functionality and the thin reclamation functionality can only be triggered to a storage controller that is known to comply with the API. There’s absolutely no risk of spill-over into controllers that do not support the Veritas Thin Reclamation API.

In considering vendor API collaboration versus a dedicated T10 approach, there’s a criterion of time to value for customers to consider. Organizations want to reduce storage costs immediately, and given the current business environment, they simply do not have the option to wait for draft T10 standards to be determined, ratified, and eventually implemented. That’s certainly a longer term goal, but realistically, for the next 18-24 months this is a way organizations can reclaim wasted storage that otherwise would be orphaned in a TP environment.

For those that are following the work of T10 closely, I would note that the latest proposal from EMC at T10 is very strongly inspired by the Veritas Thin Reclamation API…

Enough about SMI-S; thin provisioning is a relatively new solution that IT organizations are trying to get their hands around. The capability in hardware is there (albeit with implementation details varying by vendor), but to truly maximize the TP value there must be server side awareness (file system and volume manager). Working with our partners, we’ve engineered a way for organizations to automatically, and non-disruptively, reclaim storage capacity. We’ve been very open with hardware providers (including EMC) about the Veritas Thin Reclamation API, and this has moved solutions for customers forward on a number of fronts (3Par being one case in point).

From a technical perspective, the concerns expressed by storage anarchist have been thoroughly considered and are handled by the Veritas Thin Reclamation API and Veritas Storage Foundation. Storage Foundation is specifically designed to deal with hardware specific functionality and the thin reclamation functionality can only be triggered to a storage controller that is known to comply with the API. There’s absolutely no risk of spill-over into controllers that do not support the Veritas Thin Reclamation API.

In considering vendor API collaboration versus a dedicated T10 approach, there’s a criterion of time to value for customers to consider. Organizations want to reduce storage costs immediately, and given the current business environment, they simply do not have the option to wait for draft T10 standards to be determined, ratified, and eventually implemented. That’s certainly a longer term goal, but realistically, for the next 18-24 months this is a way organizations can reclaim wasted storage that otherwise would be orphaned in a TP environment.

For those that are following the work of T10 closely, I would note that the latest proposal from EMC at T10 is very strongly inspired by the Veritas Thin Reclamation API…