Thin Provisioning on Thin Ice
Written by Mike Young on May 19, 2007 at 6:37 am
Recently, I just haven’t been able to go a day without reading something about the topic of Thin Provisioning. For those of you unaware of this feature, it’s a technique for providing an application or user a prescribed amount of dedicated storage without actually permanently allocating it. For example, let’s say an application is setup and an admin wants to give it a 100Gbyte volume. Thin provisioning allows the underlying storage system to merely give it what it needs, up to a maximum of 10Gbytes. Microsoft Windows has a feature like this called Dynamic Disks. But it has other names too, like Over Subscription or Sparse File.
On the surface, this can seem like a great thing. Gee, let’s just give the app what it thinks it needs, but fool him in the end because he really doesn’t know what he wants.
Utilizing sparseness isn’t a new thing by any stretch of the imagination. But is it really an End User benefit? Let’s look at some examples of how this underlying feature can be helpful:
- An application requires 100Gbytes of iSCSI storage, so we go ahead and carve out that space. If that space is provided via a volume manager of some type and 100Gbytes of extents are merely allocated, this process could take only a few seconds to complete. If, however, the space is really a file on a file system, then it could be an entirely different story. The file has to be created and possibly filled in order to ensure that the allocated space deducts from what should be remaining in the pool. But this process could take minutes or longer to complete depending on the size. Keeping the file sparse and merely allocating the proper number of extents by making a file system call can take a couple seconds. The file is still sparse, but creation and allocation process is very quick and the admin can be done with his setup in a jiffy.
- Another possible usage, as it was recently relayed to me, is when it comes to planning storage growth IT personnel will look at how much storage they have deployed and purchase an appropriate amount of tape and other supporting infrastructure. I was told about how this overallocation leads to propagation of more over allocation. By utilizing Thin Provisioning, one has a “truer” sense of what is used and what needs to be procured for backup and replication. Yeah, okay!
- Then there’s the case of… lost my thought…
I really am not trying to dismiss the benefits of this technique. But my belief is that it really is just a technique and not a feature. If it is in fact a feature for IT personnel, then CIOs should be very concerned about the organizations they’re building as their personnel are becoming lazy in their responsibilities. The only way the becomes a feature in IT organizations is if it’s tied in on some type of a leasing plan where you only are billed for the amount of storage that is actually consumed. This is much like the processor leasing feature that Sun has utilized in their big enterprise servers where you take a multi-CPU platform and only pay more as you start utilizing more CPUs. But think about that feature for second. Again, it’s a classic case of not knowing how much you really need.
Sparseness has its place and I use it all the time. Whenever I wish to create a new iSCSI or SAS or other type of volume for an application, I always carve it out as a file. But I do this by marking the beginning and the end of the file. The file may look to be 100Gbytes in size when I run an “ls -lah”, but performing a subsequent “df” on my system may reveal I’ve only consumed 100Mbytes. To keep a running tab of what I allocate vs. what’s available, I simply make a file system allocation call to allocate the appropriate number of file system extents as I create the file associated with my virtual block device. Now, my “df” results will coincide with my “ls -lah” results and they system and all my apps are none the wiser.
What’s the benefit to me? Easy to explain. I do not believe in provisioning X% block and Y% file when I deploy storage. First of all, I’m too cheap to simply buy that much storage. Instead, I make my storage 100% file and simply create a block device on top of that file system. Generating sparse files helps me to shorten the formatting time for my block devices from minutes to seconds. And if I later find out that I need more block storage, I can simply append to the existing file or create another file-based block device and do some type of concatenation. Or if I need less block storage, I can truncate the file to something smaller than what I allocated, but greater than what I’ve actually consumed. All of these operations take just seconds to perform.
Rolling these techniques into a product is what I do. Or really, my engineering team does. I just come up with the stupid ideas and the possible prototypes. They make sure I don’t slit my throat
But it’s a technique, not a feature. If it is an end user feature, then I fail to see what the benefit is; and I learned a long time ago that “features without benefits don’t sell”.
Technorati Tags: Thin Provisioning, 3Par, Storage, Equal Logic
Comments (1)
Category: Storage, Techy Stuff
- Add this post to
- Del.icio.us -
- Digg