3PAR’s Thin Un-Provisioning is Slightly Less Bad
Posted on Sep 02, 2008 by Stephen
3PAR just introduced their third-generation storage hardware, bringing a novel feature to the world of thin provisioning: Hardware-assisted “zero-detection” to convert standard storage to thin provisioning. Although only certain special-case users will benefit from this technology, it’s nice to see someone working on one of the pitfalls of the technology – that it’s really hard to convert from “fat” to thin, let alone to un-provision storage.
What’s Wrong With Thin Provisioning?
As I have explained in my storage seminars, thin provisioning is the opposite of what storage management professionals should be doing: Instead of managing usage, we just throw up our hands and say “you want 500 GB? Fine, you’ve got it!” while all the while only provisioning a fraction of that space. It’s a lie, and is thus bound to catch up with us sooner or later, and probably at just the wrong time.
People use disk space like money – their needs tend to expand to use up all they can get. Tell the users that you just added another 8 TB to the file server and watch their usage spike. Tell a database manager that they need to buy 20 TB and watch as their tablespaces magically start using 19. It’s human nature, and fighting this impulse to consume is precisely what management is all about. Traditional thin provisioning (or “virtual provisioning” in EMC-speak) does exactly this – it “tells” the downstream users of a storage resource that they have more capacity than is actually assigned to them and then grows capacity as it is used. To say that it is controversial is an understatement.
In certain instances, including Drobo and VMware growable disks, this can be beneficial since it’s a pain for most end-user OS configurations to resize a volume after the fact. In these special cases, I concede that thin provisioning is the right way to go. The same could be said for deduplicating or compressed storage – these simply have to be thin provisioned, since the actual allocation is completely abstracted by the compression algorithm. Thin provisioning can also help (slightly) for the OS volumes of virtual servers. But mainstream enterprise users have storage, server, and application managers, so they shouldn’t resort to “tricks” like thin provisioning – instead, they should manage their storage!
But the worst thing about thin provisioning is that it can’t un-provision storage. Let’s say a user uses your thin-provisioned file server as a temporary landing zone while switching to a new laptop. Or your database folks load their LUNs up with SQL dumps after an outage. Or your application folks fill up their test servers prior to going into production. Predictably, that thin-provisioned storage will expand, using up real disk capacity, to take the load (presuming enough capacity is available). The problem arises when they delete this temporary data – the storage array has no way of knowing that those blocks are no longer in use, so it cannot un-provision them. Suddenly your 500 GB thin-provisioned LUN is really taking up 400 GB even though it only has 20 GB of actual data on it, and you feel like a chump. Time to go manage your storage…
Zero-detection helps a little
Now back to 3PAR. Their new T-class InServ storage array has a special ASIC designed to attack a small chunk of the un-provisioning problem. It scans allocated storage, looking for blocks filled with zeros, and de-provisions them. This is nice – it’s a great tool to convert traditional storage to thin-provisioned storage. It’s also the first practical un-provisioning approach I’ve heard about, and might yield some capacity improvements for already-provisioned LUNs in certain special cases, though I’m not sure 3PAR is aiming for this market.
See, it’ll only work for zeroed-out storage, which is sadly extremely rare in the world of storage. It will detect capacity that has never been used, but most filesystems simply change their pointers when a file is deleted – leaving the data just where it was. 3PAR’s effort won’t work in this case. Even decommissioned servers often leave their LUNs full of old data, a security risk to be sure, and not a case that 3PAR could deal with, either.
The only way to make this work for already-used storage would be to add another step to the decommissioning process – zero out LUNs that are no longer in use as a way to send a signal to the storage array that it can un-provision that storage. But of course, we could also just send an email to the storage administrator to de-allocate the LUNs, leaving us in a much better position since we no longer have unused LUNs sitting on the storage array. Maybe we could modify the filesystem to zero out unused storage. Anyone have the source code for NTFS?
Seriously, though, this is a practical step in the right direction. We need better communication between applications, operating systems, and storage in order to enable lots of beneficial features. 3PAR is trying to enable some communication, and I applaud them for that. Just don’t expect too much.
-
http://emailtoid.net/i/c27bca2a/871f51e7/ Marc Farley
-
http://emailtoid.net/i/c27bca2a/871f51e7/ Marc Farley
-
http://blog.fosketts.net/2008/09/15/greenbytes-embraces-and-extends-zfs/ greenBytes Embraces and Extends ZFS | Stephen Foskett, Pack Rat
-
Pclifford
-
Pclifford
-
http://blog.fosketts.net sfoskett
-
http://stephen.fosketts.net Stephen
-
Nick Triantos
-
Nick Triantos
-
http://blog.fosketts.net/2008/10/16/symantecs-thin-api-step-direction/ Symantec’s Thin API Is A Step In The Right Direction – Stephen Foskett, Pack Rat
-
Josh Arieli
-
josh_909