As is true with most technologies, there are some things to keep in mind when you deploy thin provisioning -- and they dont necessarily include the knee-jerk concern about over-provisioning yourself out of actual disk space. Between the reporting that is available and responsible administration practices, the capacity emergency scenario rarely, if ever, raises its head. Instead there are other things that storage administrators should think about -- including expectations for how thin provisioning works in conjunction with data lifecycle practices.
One such area is block space reclamation, or rather, the lack thereof. The idea behind block space reclamation is to return blocks of storage that are no longer occupied by data so that they can be used again (reclaimed) and assigned to other volumes.
Let's say you create a 500-GB thin volume and things start off as predicted using 10 percent of that capacity, or 50 GB. Good! That's what thin is for -- it saved you 450 GBs or so right off the bat. Way to go.
Over several years, let's assume the volume grows and the used capacity approaches the expected 500 GB. As part of normal lifecycle processes you archive 100 GB of data that is more than three years old to a disk archive or even tape. Good for you! The volume that was thin when it started is now the size it would have been if you had created a fat volume originally. The capacity purchases you made over the years cost less per GB than if you hard-provisioned all the capacity up front. Of course, if the capacity only grows to 350 GB instead of 500 GB, then you would never have had to spend any money on 150 GB of unnecessary capacity. Any way you slice it, it's an excellent lifecycle story.