IBM XIV Thin Provisioning

Thin provisioning on an IBM XIV is pretty hot, but there are some gotchas. Thin provisioning lets you actually allocate more space in LUNs to your hosts than you have in physical storage. So, if you have a lot of filesystems or volume groups that have a lot of free space, that’s cool. Where on other storage systems you would burn the whole space allocated by the LUNs, you’re only allocating (physically) as much as you’re really using. It’s easy to burn yourself, so you have to monitor your free space in the XIV “Storage Pools”. When a Storage Pool fills up, the volumes go to Read-Only mode until you resize the pool.

Now, here’s a catch. You can define the LUN to any size, but when the first I/O hits, the system allocates 17GB to the LUN regardless of size. So, you define a 8GB LUN (for giggles) on a thinly provisioned Storage Pool. When the first I/O hits (like you actually turned on the host, or ran cfgmgr, or did a scan for new hardware) 17GB will be reserved out of the Storage Pool. And, it burns this free space in 17GB increments. 18GB burns 34GB free space, ect…

Now, the system tries to keep you from doing stupid things like this. If you specify the size of the LUN in GB, it will automagically round up to the nearest 17GB chunk. But, if you specify in 512 byte blocks (because we all think in 512 byte blocks, right?), the LUN will appear to the host as the exact size specified. And, it still burns the 17GB free space.

So, at a minimum the actual physical space you need for a thinly provisioned Storage Pool is:
17GB X [# of LUNs]