I’m planning to take a look at thin provisioning. Seems plenty of vendors are talking up the technology but I am trying to gauge where the trade-offs lie. Reads one of my messages this week. Please scroll down or click for more.One article I read likened it to the airline industries approach to overselling flights in the anticipation that some people won’t show up. In the case of the thin provisioning, the writer says, there’s a risk that a storage admin may run out of storage due to incorrect forecasting of storage needs. Is that a flaw in the technology, or does it just mean that companies using thin provisioning need to plan better? Any insights you can provide would be very helpful.Well, thin provisioning is not a new topic nor uncharted territory, but I’ll be glad to give you an overview. You may also want to check other blogs, for example Tony Asaro’s at the Enteprise Strategy Group. That analogy with airline reservations fits well thin provisioning, but only up to a point. A dirty little secret of the storage world is that most storage requirements are grossly overestimated, often by an order of magnitude or more. It’s not that storage admins are incompetent but often someone else, for example the database admin or the developer, calls the shots on how much capacity a project needs. So you have a typical situation where there is authority (“I’ll tell you how much storage I need”) without responsibility (“it’s not my job to optimize the amount of storage we buy or run”). In addition, estimating the capacity requirements for a new project is not easy and people tend to overestimate to be on the safe side. Case three: Taking back excess storage after the new project is in production and the requirements are finally clear, is rarely done, so like a diamond, an overallocation of storage is forever.Thin provisioning gives the storage admin the ability to provision the application server with the amount of space requested, say 100 GB, but taking away from the storage pool only a fraction, say 20 GB, if that’s the amount “thin provisioned”. The objective of thin provision is not to forecast future use correctly, but to stretch the current capacity and cover requirements totaling a much larger amount of storage. In many cases, the thinly provisioned amount, plus adjustments for normal data growth, gives enough capacity throughout the life of the application. Nevertheless, each company should find out what’s their real data growth rate and add more capacity according to that trend. If they don’t do those adjustments correctly, at some point one of the applications will run out of space, which is never a pretty thing to live through.However, I don’t buy that incorrect forecasting is a risk associated only with thin provisioning. Storage capacity needs to be closely monitored regardless if doing fat or thin provisioning. If an admin runs out of space with thin provisioning, he or she would have botched also with fat provisioning, IMO. Anyway, when done correctly thin provisioning is a big money saver because a purchase or a lease can be delayed until really needed, and will cover only the increment suggested by the growth trend. For a small company thin provisioning may not make much of a difference, because the granularity of their purchases can’t go below a certain level ( you can’t buy a third of a storage enclosure, for example). For larger companies that buy millions of dollars of storage, thin provisioning is too good an opportunity to pass on because in addition to the financial aspects (later disbursement e and so on) they also save kilowatts/hr or at least push back in time the demand.Hope this helps, but you know where to find me if it doesn’t…