Is your thin provisioning too thin?

Hu Yoshida, vice president and chief technical officer of Hitachi Data Systems

Since there is no accurate way to predict how much capacity they will need, users always request more storage than they expect to need as a standard practice.

Thin provisioning is a storage feature that allows a storage system to share a pool of storage capacity with many users by "thinly" provisioning their request for capacity with only the physical capacity that is actually used versus the capacity that was requested.

This takes the guesswork out of provisioning storage and makes more efficient use of storage capacity by eliminating the waste of allocated but unused capacity. Since allocated but unused capacity is the biggest reason for the low utilisation of storage capacity, storage vendors are rushing to implement this capability.

The common approach to thin provisioning is to chop up the storage capacity into chunks, and allocate the physical storage in increments of chunks or groups of chunks as it is required. This requires additional overhead to keep track of the chunk assignments versus normal storage provisioning. It also requires management of the holes that these chunks come from. When you are allocating chunks to different users with different input and output requests you get fragmentation of the storage pool, and at some point these fragments have to be cleaned up or the pool becomes full of unusable fragments. The smaller the chunks the more overhead is required. One vendor uses a 4KB chunk. Another vendor provides a choice of chunk sizes from 32KB to 256KB. This approach to thin provisioning can create even more complexity and fragmentation, and has a significant impact on performance and throughput, especially if the overhead occurs in the data path.

The Hitachi approach is significantly different. Our chunking unit is a 42MB page which is striped across the width of a thin-provisioned storage pool. By this I mean that if the storage pool consists of 32 disks, the 42MB page is striped across all 32 disks. This enables all the disk arms to support the input and output that goes against this page.

The Enterprise Strategy Group tested this in its labs, comparing the performance of a random access workload with 8KB block size on 8 spindles in a RAID 10 configuration, against 32 spindles in four RAID 10 groups and saw a 716-per-cent improvement in throughput, with a 118-per-cent faster response time at the start point.

 Why did we choose a 42MB page rather than a 4KB, 32KB, or even a 256KB chunk? Those small chunk sizes don't stripe well across the width of a large thin-provisioning pool. By using a uniform page size that spans the width of the storage pool we also minimize fragmentation. We believe that volumes today are much bigger than they were 10 or even five years ago. With 500GB and 1TB disks today, who is allocating volumes in KB or even MB sizes? Some file systems have a 2TB limitation, which was fine 10 years ago, but is too limiting today. Even at the disk media level, there is a movement to increase the traditional 512-byte sector to a 4-KB sector for increased density, performance and availability. Not only is a 42MB page more relevant to today's volume sizes, it also requires less overhead to provision one 42MB page than an equivalent 10,500 chunks of 4KB each. 

Hitachi's thin-provisioning overhead is masked because we store the provisioning information in a separate mirrored cache or control store, rather than in the data cache. That means the overhead for provisioning is done outside the data path.

So as more storage vendors join the thin provisioning ranks and look to see how 'thin" they are and how it affects performance and manageability, Hitachi's thin provisioning will be criticised for being "fat", with a 42MB page size versus the conventional wisdom of 4KB or 32KB chunks. Instead of following the crowd with small chunks, we chose to use this page size so that we could reduce overhead, simplify the provisioning process and increase performance by wide striping across the width of the thin-provisioning pool.