Those are two of the most dire opinions about thin provisions I've heard. Not wrong, but definitely the negative side of the story.
Some of the importing things they did not point out I'd like to add.
-Thin provisioning on a P4000 SAN is like a light switch, turn it off and on all you want, volume by volume. So no need to dread making this decision, you can change your mind anytime.
-Thin provisioning works on any app. As far as space savings go the worst case scenario with thin provisioning is you use up just as much space as if you had just made it full provisioning. That is really rare too.
-Thin provisioning exposes no risk at all unless you overprovision the SAN. The P4000 utilization graph actually changes if you do overprovision and points this out. Until you have allocated and exposed more storage then exists in the SAN you have no exposure to the possibility of running out of space for new writes.
-You'll get alerts as you approach the capacity limit of the SAN. You'll actually get many as snapshot schedules will alert that they could not take the next snapshot as you get close enough to the end because there is not enough space. If you are not paying any attention to alerts or warnings in the UI then you are exposing yourself to more issues, and more common ones, then just thin provisioning, you would not even know when disks fail.
-When you see these alerts you can do much more than just purchase more storage. The quick reactions to do before that are things like deleting some un-needed snapshots, lower the replication level of a volume, make a full volume thin (that frees up unused pages for everybody else), or delete a volume (assuming you really don't need it). Most customers seem to just delete some snapshots, and change their schedules to keep less copies around, until they can get more storage.
Because you did ask. A more complete description of what does happen would be this.
If you do thin provision volumes, and over allocate the SAN, and ignore all warnings and alerts, and don't free up space, and actually write the SAN down to having zero pages available to allocate, this will happen...
-All fully provisioned volumes will be unaffected (that's the point of fully provisioning them)
-Snapshot and replication schedules will not run because there is not space for additional snapshots. Also, every one of them will be throwing alerts, many of them usually do before the SAN is actually out of space too. It depends on the size of the snapshots.
-Thin provisioned volumes would remain online and reads would continue to succeed.
-SCSI writes to thin provisioned volumes would fail until pages are freed up using one of the aforementioned ways.
The exact affect at the server level of the SCSI writes failing depends on the app and OS.
Any app that bothers to zero out its data space would not be affected, even on thin provisioned LUNs. An example of this is a VMware VM that eager zeroed its disk, such as a fault tolerant VM.
An app or OS that did not zero out its data first would probably error, crash, blue screen, or if it's a VM it might power off.
Hope that helps.
Adam C, LeftHand Product Manger
