StorageRap

Tiering is not for Chuck Norris

Separated at birth?

There have been some interesting discussions lately about storage tiering  And just because 3PAR beat most everybody else to the punch this week with our AO announcement, I think it's important to keep things in perspective - storage tiering does not solve everybody's problems. Here is my top 10 list of reasons some people don't want to embrace tiering: 

10. Chuck Norris does not need automation, automation needs Chuck Norris.

9.  The Chuck Norris of IT, Larry Ellison, says Exadata is the only tier you need.

8.  Chuck Norris & Larry Ellison will race to determine if tiering is good or evil.

7.  Heard it uses gerbils, which is unfair to guinea pigs.

6.  Chuck Norris got to Tom Georgens, he will get to you too.  

5.  Chuck Norris designed 3PAR's wide striping - who needs tiering?

4.  Chuck Norris already tunes my storage in his sleep.

3.  Larry Ellison is going to buy all the world's SSDs and corner the market.

2.  Waiting to hear if Chuck Norris will discuss tiering this week on InfoSmack. 

1.  Too busy celebrating Chuck Norris' 70th b-day today to care about tiering.

Why AO is a game changer

Yesterday, 3PAR announced Adaptive Optimization (AO), our solution for storage tiering and support for SSD flash drives. Here are the elements of this technology that I believe will have the most impact on customers and the rest of the industry.

1) Tiering works by making copies of data on lower cost, low-IOPS storage to high-IOPS storage - and back again.  Storage tiering has been associated with ILM, which assumed data is initially located on more expensive, high-IOPS storage and, as it ages and is accessed less frequently, is moved to lower-cost, low-IOPS storage. The perception that tiering implies fast to slow data migration was reinforced by Compellent with it's early entrant storage tiering technology, Data Progression.

The economic benefits of tiering are much more compelling if data is originally located on low-IOPS storage and then moved to high-IOPS storage when it becomes useful to do so. This reduces the amount of high-IOPS storage that needs to be purchased and reserves high-IOPS storage for the applications that need it the most. This model of promoting data to high-IOPS storage will replace the old model of data "trickling downhill to cheap storage."

2) Sub-volume tiering means high-IOPS storage can be reserved for high-IOPS work and effectively shared by the applications that need it the most.  AO copies data in 128 MB sub-volume regions that contain specific RAIDed volume slices. Many physical and virtual servers can have their volume's most active regions located in high-IOPS storage capacity at the same time.

Data redundancy is accomplished when AO reads data from it's source region and restripes it into a region on the target tier - using the RAID level of the target.  AO allows data to be protected by whatever RAID is appropriate for the tier and the data.  3PAR's chunklet architecture is maintained for SSDs, which means a SSDs in an InServ array can apply several different RAID levels simultaneously.  Every vendor's sub-volume tiering technology will be different, including the number of ways devices can be combined in RAID and how wide striping can be applied.

3) Tiering does not mean you have to buy SSDs to make it pay off.  Tiering is a cost-reduction technology.  One of the most obvious ways to reduce the cost of storage is to buy cheaper disks with higher capacity, such as SATA drives. 

The regions used by AO are the same on-disk structures that 3PAR uses for it's Dynamic Optimization (DO) software that re-levels volumes across disk drives in an InServ array.  A customer with all FC drives in an InServ array could take advantage of both AO and DO by increasing the capacity of an array with SATA drives, using Dynamic Optimization to redistribute their volumes across the SATA drives and then using FC drives as their high-IOPS AO tier. This way, they can continue to get the IO rates they expect, but reduce the cost of incremental capacity as they upgrade their system. 

4) The system determines what to move and how to move it. I/O density rate is a term that refers to how much data access occurs in a region over a given amount of time.  AO recognizes region candidates for tiering by their I/O density rates.  

Administrators control the AO participation for each volume by assigning them to an AO Profile and a QoS Gradient.  The profile is a short stack of device-RAID levels, such as SATA RAID 6, FC RAID 5(7+1) and SSD RAID5 (3+1). AO allows either  2 or 3 device RAID levels in the profile's stack.

The QoS gradient is a relative determinant of how quickly the volume will be acted upon.  I like to think of it as something like different viscosities for different fluids, but for storage.   AO today has three QoS gradients, performance, cost and balanced.

Back in Novemebr, Tony Asaro wrote about his discussions with HDS' storage customers regarding storage tiering.

Another discussion was around using policies to automate the process. One group was a bit concerned about automating this process but realized that, again, with PBs of data being stored that the only way to effectively implement intelligent tiered storage is via automation.  Additionally, it is not an all or nothing proposition.  You can select certain volumes and applications to implement and gain a comfort level before deploying more widely.  One of the key tenants of technology is to automate otherwise manually cumbersome processes.  We just need to get over that hurdle but we need to do so in a planned, considered and reasoned way.

By applying measured I/O density rates, AO profiles and QoS Gradients, 3PAR has taken the first major steps to automating storage tiering and removing the burden from administrators.

5) Tiering can and should scale out.  David Floyer from Wikibon wrote a good piece yesterday on our announcement where, among many things, he discussed how 3PAR is using smaller SSDs spread over more controllers:

....it spreads a small amount of SSD amongst the 3PAR engines so the IO’s aren’t all going to a single drive and sucking up a lot of bandwidth – it’s nicely balanced. Traditional implementations will use larger drive with more IO’s going to that drive. The part of the array with that drive will get more activity.

In practice we don’t think this will matter all that much because, for example, EMC’s V-Max has more bandwidth to play with than 3PAR and EMC uses its cache to transfer data between tiers to avoid bottlenecks. Nonetheless, on paper, the 3PAR implementation looks to be more efficient which means (in theory) it can do more with less flash. But nobody really knows yet.

3PAR storage arrays avoid I/O bottlenecks by incorporating tiny virtual storage elements (chunklets) and spreading the workload over as many devices and controllers as possible.  This approach differs from other vendors where smaller groups of resources are created and then combined into larger constructs that are more cumbersome to manage and tune than a single widely distributed storage span.  The same concepts apply to SSD integration, where InServ arrays accommodate multiples of many, smaller sized SSDs for scaling out high-IOPS tiers for those customers that may want to expand their use of AO in the future . 

Symantec beats FAST out the door with SSD support in Dynamic Storage Tiering

While some have wondered whether or not EMC was going to be able to get their FAST product announced this year, others have been keeping their heads down getting work done.  For instance, Symantec, who today announced their Dynamic Storage Tiering feature for SSDs in their Storage Foundation products.

Of course, many probably wonder why the heck I'm writing about this seeing how 3PAR doesn't have support for SSDs in it's products yet.  That's easy. A v-Max with FAST is going to be more of a science project than a production system that actually gets work done.  I'm more concerned about customers buying somebody else's SSD-enabled array and using it with Symantec's Dynamic Storage Tiering than I am about FAST on v-Max.

But I'm not that concerned because the SSD market has been slow to develop - even by EMC, the company that has been leading the charge (and inventory buildup).  And even though they like to point to the check boxes in the feature checklist, big wide striping (the kind that flattens disk contention problems) with a v-Max is still an exercise in storage contortionism, unlike on a 3PAR, where its the default behavior.

But all this will change over time and the cost of deploying SSDs is going to come down as enabling software for SSDs becomes available and is refined. Even EMC's software will slowly get better. Despite the performance of the SSD devices - and EMC's wishes, the race for best of breed SSD functionality is going to be much more of a marathon than a sprint.

So where's 3PAR?  We've been shipping DO (Dynamic Optimization) for 4 years and today we announced the policy advisor for automating most of the tasks that used to take admins time to work through.  Changing service levels for volumes just got a lot easier. Drive speed, RAID levels, additional drives - if you want to change them, you can - and it doesn't take weeks or months and piles of spreadsheets to figure it out.

EMC trips and kicks their supplier, STEC

Its all over the news today. STEC's stock is getting hammered because their largest customer, EMC, is delaying orders.   I feel for the folks at STEC, its difficult being a supplier to industry behemoths like EMC.  When realities don't meet expectations, things can crater in a hurry. 

There is nothing wrong with flash SSD technology, it's simply a matter that the market demand hasn't ramped yet.   Some of the EMC bloggers have chided me for my position on SSDs, but today's news pretty clearly vindicates what I've been saying all along:

• Flash SSDs are still considered expensive and are difficult to justify
• Customers can't use them intelligently or flexibly yet
• The market for customers needing extreme low latency, is not ramping that quickly

The situation is changing gradually.  Prices for SSDs are coming down, but there still needs to be a lot of work done by storage system vendors to flexibly use them - and this is going to continue to take time.  EMC has said they will release their first version of FAST this year, but almost everybody is looking at future versions of FAST to get the sort of functionality they can actually use.  Compellent's Data Progression software has the basic ability to move data on and off SSDs, but the number of SSDs that can be used per system is small and their sales are far too small to make up for what EMC has failed to deliver on.  SSDs have a bright future, its just going to take longer to flourish.

So where is 3PAR on SSDs?  We think they will be an important  technology in the future and we are working on integrating them into our products in a way that will allow customers to take advanatge of their capabilities. In other words, we're going to have them, but we're not going to sell something that costs a lot of money if our customers can't leverage them.

In the meantime we continue to sell the most efficient storage systems  that also happen to have the best implementation of wide striping on the planet, which delivers optimal mixed workload performance for our customers.

What EMC thinks of as ease of use

Scott Lowe had an interesting post on Friday about creating metaLUNs that has attracted some interesting comments, which is where the best parts are. 

Given today's computing power, there is no need for stupid software contraptions like metaLUNs, they are a side effect of a dull architecture that puts the onus on the administrator to figure out what to do.  It's easy - just figure it out! 

3PAR InServ arrays automatically wide stripe data over all the drives in the system, without headaches or "weird science".  It's very simple for administrators and the performance is excellent - without requiring an army of professional services people, the way things tend to work with arrays from the Ever Mounting Costs company.

And now for something completly different: Human Tetris!

Storage Technology Refresh? Spend a lot less in a big hurry

When your existing storage approaches the end of its affordable life, you probably wonder if there might be a better way to get the job done.  It would be great if you could spend a lot less on storage capacity and not have to do so much planning for your RAID groups, semi-wide stripes, service levels, snapshots and remote copy space.  It would be even better if you could avoid the same surprising and painful hidden professional services fees that make storage seem more like a luxury item than an infrastructure technology. Best yet, how would it feel to actually decrease your storage footprint during your next technology refresh, as opposed to watching it grow larger than you care to think about. Think you'll get those kinds of options from the Ever Mounting Costs company?

Like most I/O performance demonstrations, the video below is a bit reminiscent of watching paint dry,  but if you understand what's going on, its pretty cool.   3PAR's Thin Conversion is a block data transfer function where empty blocks coming into a thin volume on a 3PAR InServ array are identified as such and not written to the receiving thinly provisioned volume space.  The result is a significantly faster data transfer and an efficient, thin volume with high storage utilization when the transfer completes.

In this video, block data from a thick (or fat) source volume is being migrated to a new thin target volume using 3PAR's Thin Conversion technology.  The demo shows reads from the source in red and writes to the target in blue so you can see the impact of 3PAR's hardware-based zero detection technology.  During the demo, zero-detection is turned off and writes spike to a much higher level and then it is turned on again to show writes returning to zero. 

Because Thin Conversion only writes actual data on the target and does not copy empty space, it's insanely fast and because it's implemented in hardware, there isn't any performance degradation in the controller.  Also notice that the amount of storage needed on the target volume will be much less than on the source volume and storage utilization for the array will be much higher.

Thin Conversion is a great way to pare storage costs when you are considering a technology refresh. Instead of buying more new storage than you want and increasing the storage footprint in your data center, you can buy less storage, reducing your storage footprint. Thin Conversion works with both T-Class (Enterprise) and F-Class (Mid range) arrays from 3PAR and is independent of the types of drives in the system.  Check it out, you might surprise yourself at how little you actually need to spend.

Multipathing in a 3PAR Mesh Active Storage Server

I had a question on the blog last week regarding the nature of 3PAR's Mesh Active clustered controller architecture and so I put together this video in response. 

In addition to the tightly integrated cluster design, one of the most unique aspects of 3PAR's Mesh Active architecture is the way disk resources are accessed in parallel by all controllers in the system. The combination of wide striping with the Mesh Active architecture means that customers get excellent, predictable performance - even after a controller failure.

New 3P song suggests "Store heads" get their data on the cloud

Everybody has an opinion these days about Cloud Computing and Cloud Storage.  3P tells "Store Heads" in his new video below that they ought to start investigating how to do it.  The equipment used by cloud service providers matters a great deal to their success.  Technologies such as reservationless thin provisioning, full array wide striping and dynamic, load-balancing, active/active controllers make the cloud experience much more satisfying.  3PAR partners with Cloud Service providers through a program called Cloud Agile to bring 3PAR array technology to cloud computing and storage customers.  

Watch:

The not active active enough for VMware blues

Somebody asked me on Twitter the other day if our arrays allowed a pair of host HBAs to concurrently access a single LUN though two different controllers - telling me a competitor was saying we couldn't. Well, that was pretty whacked because our clustered architecture is designed specifically for that purpose. What they probably meant to say was that their own product couldn't do it. Anyway, it got the juices flowing for a new SWCSA vid!

If you are wondering how to get the most out of VMware's v-Sphere multipathing options, you need to make sure your storage array allows you to access individual LUNs through multiple controllers at the same time. 

Why would you limit yourself to one controller per LUN, like Clariion, Netapp and HDS among others when you can balance the load dynamically across multiple HBAs and controllers with 3PAR InServ arrays with mesh-active controllers. To be clear, this industry-leading clustered storage capability is designed into all our arrays, from our mid-range F Class arrays to our enterprise T Class arrays. 

The group blogging circus and FUD findings: Anarchist, Enrico, Hu and the no shows from Compellent

(Author's note:  a couple typos in the next to last paragraph have been corrected, which should make things clearer  -mf 8-08-2009)

It's funny how things work in the stoblogosphere.  The  Anarchist goes after my reservationless post and steps in a pot hole of tchit and in the process brings blogging newcomer Enrico Signoretti - a Compellent reseller from Italy - out of the woodwork to howl about the stench. 

A couple things about what Anarchist and Enrico said brought to light that people get 3PAR and Compellent confused sometimes. Mostly these are financial people - but lately Anarchist seems to be looking for a new career as a financial analyst as the long slow decline of Symmetrix sets in. Anyway, I felt compelled  to point out the differences between 3PAR and Compellent, which got Enrico's attention again and like a true defender of the faith he posted on some things he felt I mis-spun.  God, I love blogging.  And for money's worth - it is much, much richer than  twittering.

Of course, as things go, I recognized some pretty lame Compellent FUD that they have been feeding their resellers for some time now about 3PAR's hardware, which reminded me to post about it because it's actually a huge advantage for us. FWIW, I'm betting that no one from Compellent shows up to challenge it as they seem content to let their FUD-fed resellers do the dirty work for them.  Clever, but in the end it's not a nice thing to do to guys like Enrico (have them carry you FUD for you).  To be clear Enrico, you are OK with me, my gripe is not with you.

3PAR has been using Intel processors from it's inception in it's storage controllers.  There are a lot of good things about this and it's heartwarming to see EMC finally move to Intel on V-Max after all these years.  It takes them a long time to get caught up and of course, the target continues to move in front of them - despite their hollow declarations of parity.  Oh yeah!  And implementations don't matter either!

The proprietary stuff in Compellent's FUD has to do with our ASIC, which is a co-processor for storage functions.  While Intel platforms have some great advantages (that we recognized 10 years ago), there are some shortcomings to using them - like segregating different types of I/O traffic - especially small database I/O versus long sequential streams.  The ASIC in our system does this superbly, which is why our mixed application workload is so freaking good (along with our reservationless true wide striping.)  Why would you want to buy a different array for each major application - that's a waste of resources.

But why would Compellent tell their resellers that 3PAR runs on proprietary hardware, when we run on Intel with a kick-ass co-processor to handle the hard stuff?  It wouldn't be the usual disingenuous marketing tactics they like to accuse EMC of - would it?

The other thing our ASIC does is compute parity.  Why on earth would you want to tie up your main controller processor doing this?  Because you don't have the architecture to do it in a co-processor.

Which brings me to some of Hu Yoshida's recent posts. Hu has obviously been fed some things from the engineers in Odawara, Japan when he recently wrote about about the trade offs you have to make when you select your allocation size. Now I don't have much beef with Hu personally because he is a pretty good guy, but this post really only exposes the limitations of Hitachi's engineering team.  Yes, there are trade offs in every design decision, but there are are an almost infinite number of ways to pay for them.  3PAR's design inception is still way ahead of the rest of the industry because people that designed high end cluster server systems for SUN designed the 3PAR architecture. I don't want to be too snide, but it's pretty clear that Hitachi has  does not have the same sort of perspective on clustered systems design.

Whew - rant over.  I'm going for my first coffee of the day now.

Clearing up the Compellent Confusion

The storage industry can be confusing - even to insiders.  For example, people often compare 3PAR and Compellent because both companies are "newer" vendors working their way up against established competitors.  

But that's about where the comparisons end.  3PAR arrays scale to performance levels that far exceed Compellent's.  While it may be possible to attach the same number of drives to both arrays, when you push them both for total throughput, 3PAR crushes Compellent.   With 100+ drive systems, there is no comparison.  If you think you might need hundreds of drives, instead of less than 100, it's a slam dunk for 3PAR.

With less than 100 drives, our product lines overlap and that's probably where the confusion comes from because 3PAR's F-Class arrays compete with Compellent's. Our smallest F Class - the F200 scales from 16 to 192 drives and its bigger brother the F400 scales from 16 to 384 drives (with the addition of 2 more mesh active controllers).  FWIW, you won't saturate a 3PAR controller by loading too many drives on it - the F Class controllers can handle 192 15K RPM drives with overhead to spare. Realistically, its probably not fair to Compellent to compare any of their systems to one of our quad controller F400s. 

Nobody handles mixed workloads like 3PAR.  Which means customers can put many different applications on our arrays and get excellent performance from their systems at very high disk utilization levels.  Don't just take my word for it, see what our customers have said on TechValidate. (will require a login - it's not a 3PAR site).  The key to this is the fine-grained allocations of storage combined with true wide striping - not based on pools and metas and hypers and such.

Both companies have delivered important storage virtualization innovations to the industry.  3PAR didn't invent thin provisioning, but we forced the issue in the industry and now it's a mandatory feature in all enterprise arrays.  FWIW, our work in storage efficiency and utilization technologies continues and you can expect to see more from us in the future that allows customers to get the most from their capacity.  We are always happy when customers dig deeper into this technology and compare our reservationless thin storage with any other vendor's thin implementations. 

In Compellent's case, the delivery of Data Progression has been a key stimulus to the rest of the industry.  EMC's FAST technology, due in its first release late this year is a clear attempt to catch up with Compellent.   However, just as Thin Provisioning is not a 3PAR invention, the ability to move data between storage tiers is hardly a Compellent invention.  When I was at EqualLogic, the product had the ability to move data automatically between tiers of storage spanning different systems. Their evacuate and replace capabilities rely on their automated tiering technology. 

3PAR introduced it's Dynamic Optimization (DO) product in 2005, which redistributes data from one set of resources across an expanded or different set of resources. For instance, today a customer can add new drives to a 3PAR system and redistribute volumes across all the drives in the system using DO. They might do this for either capacity or performance reasons - or both. With storage capacity needs continuing to grow, it's important to be able to scale with performance and agility.  When you add new drives to a 3PAR system, their capacity is a reservationless resources that can be used by any application, on demand - including for use as snapshots for existing or new applications.

Real Partnerships for Virtual Private Arrays

Earlier this week 3PAR rolled out the Cloud Agile Program with our charter partners, Attenda, DataPipe, Terremark and Verizon Business.   The mission of Cloud Agile is to bring 3PAR's efficient and scalable enterprise storage capabilities to a wide range of customers through cloud (utility) service partners. 

One of my favorite aspects of Cloud Agile is the concept of a virtual private array, which is the same idea as a virtual private server, but applied to storage. Customers of our Cloud Agile partners will be able securely manage their own thin slices of our arrays, taking full advantage of massive wide striping and thin provisioning. 

What Google's Chrome OS means for the storage industry

Google's announcement this week about their intention to create a web-based operating system  from its Chrome technology has huge implications for storage, as well as the whole IT industry.  Inexpensive, lightweight and always-ready is the big winner in client technology.

Whether Google eventually succeeds with its Chrome strategy is immaterial now that the cat is out of the bag - everybody now understands that a user operating system doesn't have to carry legacy desktop system baggage anymore.  The cost of supporting obsolete equipment and software can be dropped and those functions replaced by utility (cloud) services. Among the obsolete stuff that can be left out are lots of storage drivers.

So what happens to data storage when user operating systems are completely web-based?  To begin with most user data will be stored for clients by the cloud applications running as SaaS web services. The question of whether those are private or public cloud services depends on a number variables including privacy concerns, single sign-on integration and application service levels.  Public service providers can leverage their resources across a larger install base, which will give them an economic advantage, but they need to be able to handle the challenges of multi-tenancy with technologies such as virtual management domains.

Service providers will build infrastructures with the most flexible, scalable products available. In an environment when almost anything can be accomplished in an Internet instant, neither clients or service providers can afford much time for initial setup and service level changes. For storage administrators, this amounts to having autonomic storage that readies all the resources before they are needed to be provisioned.

The concept of reservationless storage is important. If storage resources are connected to an array, why should it be necessary to think about which pools or meta-structures to assign them to first?  A storage admin in a web-connected world probably doesn't have the time to plan, re-plan and change logical storage structures when they are in the middle of a services demand surge. When management wants to know why service levels are causing customer problems, the last thing they want to hear is that storage had to be re-distributed because previous plans had to be changed. Thin provisioning and wide striping implementations that require pre-work and re-work won't deliver the goods.

Best practices will move from being a human-managed effort to setting thresholds and warnings for an autonomic, self balancing system.  This vision is what is pushing development efforts at 3PAR, much of it is already available in 3PAR InServ arrays today.

Flash is the least compelling storage technology in ESG survey

Terri McClure at ESG recently blogged about the what technologies are most interesting to NAS customers, according to a survey they conducted last September and October. People following the storage blogosphere may have seen references to Terri's post in blogs written by Sunshine Mugrabi from Ocarina and and Stephen Foskett from Nirvanix

3PAR is not a NAS company, so the survey wasn't a perfect fit, but the results of the survey pertain to more than NAS companies.  There was one data point that I thought was particularly interesting - flash SSDs ranked at the bottom of all the potential technologies people might buy. Instead, survey respondents were far more interested in power, cooling and space efficiencies - in general, doing more with less.

I think Flash SSDs will become more popular over time after the prices become more reasonable, but until then customers are going to continue to look first for products that help them cut costs, as opposed to adding significant costs.  Most customers today are looking for ways to meet their performance objectives while reducing their costs. That's what thin provisioning, wide striped arrays from 3PAR are designed for.

Claus, someone should smack you up for bad math! And the HBP smackups continue

Claus Mikkelsen at HDS wrote in his most recent blog post:

Having a 700% improvement in workload throughput is equivalent to having 105,000 RPM drives (very crude arithmetic and workload assumptions, but you get the point; don’t beat me up on this!).

What??  "don't beat me up on this"  Claus, what sort of lame disclaimer is that??  If you are going to write something stupid - and you know it when you are writing it, don't beg for mercy like a stoolie.  The math checkers in the storage blogosphere will find out and then decide if they want to give you a heaping load of sh%& for it. 

But I'm going to cut you slack because you are promoting wide striping, an excellent technology that doesn't get enough attention.  So, thanks.  We're really good at wide striping in 3PAR arrays and we appreciate the fact that HDS is trying to help people understand how well the technology can work - even if the explanation you provided is screwed up. While I'm at it, let me give you props for this line too:

I’ll defy anyone to manually provision in a way that will outperform the wide striping we do with HDP

A page from the 3PAR hymnal! - except you don't have to be using thin provisioning on a 3PAR array in order to get wide striping.  Automated provisioning in 3PAR arrays provides wide striping that performs much better than can be achieved with manually tuning. Not only that, but the utilization levels with 3PAR arrays are very high - especially for mixed workloads, where customers often want to store data for different applications on different RAID levels or tiers. 

With HBP (HDS Bloated Provisioning) - if application data is stored on different RAID levels you need different pools for each RAID level, which means you have to divide your disk resources between pools, which means your wide stripes aren't as wide and the performance advantages of wide striping are diminished. The other problem with using multiple pools is that utilization tends to be lower because disk resources are leveraged unevenly across different subsets of applications.

Nigel Poulton, who is a pretty good guy for a dyed-in-the-wool HDS cheerleader, and I have been videoing back and forth about HBP and 3PAR's thin provisioning differences.  I seem to recall him saying that you could setup an HDS array with a single pool.  Really Nigel - would that be s serious recommended best practice? All data stored in one RAID level?

Tony Asaro, in his blog,  quoted Nigel as saying:

For a start it maps perfectly with the internal workings of the USP V and VM.

Which was my point - Hitachi's engineer's did it to make it easier for themselves as opposed to fitting it to customer requirements.  Which leads me to Nigel's metadata fixation where he assumes that all metadata processes obey the same immutable rules of coding. They don't. That's because processes that are core design concepts usually are more efficient than bolt-on afterthoughts.