I think the XIV array needs a good deep dive to answer the questions you pose and many others I have too around the RAID reliability and rebuild. Watch this space, I’m trying to sort something.

Chris

If you write 1KB of data in an empty XIV volume, 17GB of hard capacity is automatically reserved for that volume, even if it’s thinly provisioned. You can provision by number of blocks on the XIV, which limits what the host can actually see, but chunks of storage are allocated to the volume in 17GB chunks.

The biggest downside I’ve noticed with XIV thin provisioning is you can’t even allocate more logical volume capacity than a fully-loaded XIV can physically handle!

Take 0 page reclamation, its effectiveness is limited to the point at which data is migrated into thin. Once the migration is complete 0 page has very little use because filesystems typically do not write blocks full of nulls, this is not for example what happens when a file is deleted.

In addition any filesystem fragmentation or striping of metadata across volumes will reduce utilization unless the TP system uses very small block sizes.

With most current filesystems the point of maximum effectiveness from a TP perspective is when the data has been migrated into TP assuming 0 page reclamation or if you have used Symantec Smartmove. After that point it is inevitable that blocks which do not contain nulls but which are not being used by the filesystem will build up, the proportion of these to the used blocks depends on how efficient the FS is at optimizing its layout and the workload.

inevitably you need a mechanism which can recover blocks which do not contain nulls but which are not used by the filesystem. this is not 0 page and needs to be implemented at the host level with support from the TP system.

I know this doesn’t relate to the article but I felt like adding my 10 cents anyway

Similar to HDS’ Zero Page Reclaim feature, it reclaims emptied space, but via an automated background scrubbing mechanism. Also, I believe it is unique (I could be wrong) that the XIV does not allocate any capacity in the first place, if the filesystem writes a long string of zeroes. HDS, in contrast, would write the zeroes and consume the space until you initiate the Zero Page Reclaim operation. XIV would have never written those zeroes to begin with. This is perhaps a small but interesting difference…

The XIV also solves two of your other potential objections to thin provisioning – performance and protection from rogue hosts writing lots of data.

Of course, every volume on an XIV system is striped across every disk in the entire system, thereby eliminating any potential performance impact caused by thin provisioning. XIV also has the concept of Storage Pools, which are nothing more than logical constructs. You can run thin provisioned volumes in one pool, and fat volumes in another pool if you like….and you can ensure that that volumes in one pool are never affected by rogue volumes in another pool. To take it a step further, XIV also has a logical way to deal with the problem of depleted capacity in a pool. Before taking the drastic step of locking all volumes in the pool from any further write activity, it can methodically (based on priority and creation time) start deleting snapshots in order to free up additional space in the pool. Not sure how the other systems mentioned would handle this…?

Thanks for all the additional comments. As I wrote the post I think I was up to 1000+ words. Unfortunately some text has to get chopped and I did abbreviate in places. Thanks for the additional comments, I am planning to write more of a White Paper for TP; I’ll be sure to add your thoughts.

Regards
Chris

Good feedback, thanks for the comment.

Chris

Good point, thanks. I think storage on VMware (especially the TP aspect) is definitely an idea for another post.

Chris