Jon Tate – Dispute it we must…

ORIGINALLY POSTED 10th September 2013

18,915 views on developerworks

“To err is human; to forgive, divine.” Alexander Pope.

Well we are mixing up poetry and Star Wars here today (or tomorrow, if it is already tomorrow where you are), and finish it off with a cryptic message.

Anyway, let’s cut to the chase here: a long time ago, in an IBM Redbook far, far away (December 2011), in an effort to get out timely information to the field, the first draft (which was a pre-review version), of the IBM Redbook Implementing the IBM Storwize V7000 V6.3, SG24-7938-01, contained the following statement in error:   

Thin-provisioned volumes require additional I/O operation to read and write metadata to the internal disks or to the back‑end storage, which adds additional load to the IBM Storwize V7000 nodes. We therefore do not recommend the use of these volumes for high performance applications, or any workload with a high write I/O component.”

However, this is not a true statement and during the review process it was corrected in the final version of this IBM Redbook.

All ‘fine-grained’ implementations, like Thin Provisioning, require the recording of metadata to provide the virtual to physical mapping. At some point this metadata may have to be read or written, and so additional I/O may be required. This is the same for any vendor’s implementation.

The SVC/Storwize implementation includes intelligent caching of metadata to minimize the need to read and write from disk, and hence can be, and is, constantly being used worldwide very effectively with high-performance, Tier-1 data. In fact IBM has published independent performance benchmarks from the Storage Performance Council organization which show essentially the same performance results for the IBM SVC product (which has the same OS base as the Storwize storage family) with and without Thin Provisioning.

Without thin provisioning, SVC code 4.2: 272,505.19 SPC-1 IOPS  –  See:

With thin provisioning, SVC code 4.3: 274,997.58 SPC-1 IOPS  –  See::

So why do we mention this? Well apparently, there is some FUD being spread around by one of our competitors that has latched on to our errata that we are more than happy to correct, well, corrected almost two years ago now ! 

It’s a bit of a sauce really, as we say in the UK.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: