1.000: happy anniversary, baby!

Today marks the 1-year anniversary of this blog.

My my, where did the time go?

I guess I was a bit optimistic with my chosen numbering scheme, as I allotted 3 digits for the post number, but I managed to craft only 78 posts. Not sure if that's good or bad - surely there are several readers who would have preferred that I'd done a few less posts (or a few less posts about their products, perhaps ).

All in all, I think not a bad start.

Oh sure, I've left a few loose ends, and I've opened the door on a few topics that I never quite got into. Hopefully it has still been been interesting to you, and maybe you even had a good chuckle every once in a while. To be sure, your comments, criticisms and feedback has been much appreciated, and I hope that I can expand the conversations in the coming year.

In fact, I'd really like to hear from you about what topics you'd like me to explore. And I mean that, whether you are a customer, prospect, competitor, work colleague, industry analyst, peer, friend, journalist, or someone who just happens to find my blog interesting - I wanna know what you wanna know...

So please, write a comment to this post with your questions and/or topic proposals, and I'll see about working them into my agenda, and maybe I'll hit more than 100 posts in my second year.

Many thanks to all of you! You've made the first year of storage anarchy better than I could have imagined!

ttfn!

Comments

[Tony Pearson (IBM)]

Happy Blogoversary, BarryB!

[Barry Whyte]

Happy Anniversary. Its been a fun year, maybe too much heel-nipping, but fun all the same, here's to the next 12 months.

I have so many questions, but they'd all come across as 'aggressive' or such.

I've learned a lot in my 9 months of blogging, like in some case Clarrion will outperform Symmetrix and for the same reason just why EMC doesn't submit to SPC but as I said, that wouldn't be FUD...

Anyway, peace man, and here's to the next 12 months of banter.

[the storage anarchist]

Thanks, guys - wouldn't have been half as much fun without your participation.

[Len Devanna]

Congrats Barry... Where does the time go?

[David Meiri]

Congrats for the anniversary!

One topic I'd like to hear about is the idea of DCOS - Data Center Operating System, that takes as input customer requirements and does all the rest (from provisioning to replication to troubleshooting) by itself. The need is obvious, but how to get there is far from clear.

Oh, and you never write about IBM. I'd like to hear more about their products. What are they up to? :-)

David.

[Piyush]

Hi Barry

Congrats on completing an year blogging. I'd love to see some posts on the future of data storage and its impact on existing technologies; for example IBM racetrack, the holographic memory being introduced by InPhase in May, nanotechnology, etc

[Nigel]

Congrats Barry.

I once heard it said that most young people spend too much time trying to be better than others and the likes. And it wasnt until most people reached the age of 50 that they stopped caring about what other people did and thought. Once they reached 50 and stopped caring about others they really started to live life to the full.

So....... may be next year will see a little less aiming for the rest.

Nonetheless a great blog.

BTW are you going to tell us what page size you guys decided on for your virtual provisioning?

[the storage anarchist]

Oh, I stopped worrying about what others thought a long time ago. But perhaps I'll be a less crotchety.

Or maybe not :)

As to the extent size, all you really need to know is that it is perfectly aligned with the Symmetrix allocation and pre-fetch algorithms. Minimum performance impact and space wasted on allocation, and maximum benefit for sequential I/O (the predominant use case for on-demand use of VP). And for databases, VP supports pre-allocate which will further optimize wide striping while essentialliy eliminating the risks of over-subscription for mission-critical applications.

With all that, does the actual number of bytes really matter?

[Barry Whyte]

It does matter when you can likely poke fun at the 42MB allocation on USP. Lazymans approach.

[the storage anarchist]

Yes, well, there is that, BarryW. Just didn't feel right to poke fun after Nigel outright chastised me (again) for picking on folks too much.

But I will confirm that the size of Symmetrix VP thin extents is indeed far less than Hitachi's convenient kludge of 42MB.

[Nigel]

Interesting comments Barry. Unsure how much to read into it (perfectly alligned etc..).

Anyhow, it does make one wonder why the secrecy... worried that other might poke fun at your allocation size?

There is something to the open and honest approach. Those who hide things generally have a reason why.

[the storage anarchist]

Nothing to hide, really.

Actually, I do have a reason for not posting the number: precisely as you say - the president of 3PAR has already attempted to discredit EMC's implementation based on its allocation size. And while I wholly support his attack on Hitachi, I see no reason to provide unecessary fuel for him to attack VP.

The fact is, the "right" size is based on many more factors than 3PAR would prefer to simplify it down to. It's not only about space utilization - considerations include mapping table sizes, prefetch algorithms, lookup times, cache management strategies, replication integration, and perhaps even future plans for the technology.

Bottom line - what's "best" for 3PAR isn't necessarily "best" for Symmetrix, CLARiiON or anyone else, for that matter...so debating the number really isn't worth the effort (or the aggravation).

[Barry Whyte]

For once I agree! Its all down to what suits the underlying device - and again we can but agree that HDS have taken the easy route and simply expand by their virtualization allocation unit. A bit terse, but Hu thinks its good.

[the storage anarchist]

OK - so you brought it up (sorta).

Hitachi (and Hu) claim that their Dynamic Provisioning works with externally virtualized storage.

NOT.

Own it. Use it daily. Got the latest microcode upgrades just this week. Licensed for everything.

No dice.

DP can't see external storage. Nada. Nothing. Kaput.

What's more? TSM (the vaunted "non disruptive migration utility") - can't select DP volumes. Internal OR external.

So much for the integrity of Hu's recent posts.

FWIW, I actually asked Hu about this in a comment to his blog this week...as usual, no response. Seems reality isn't all that important when you're competing for second place...

[Barry Whyte]

Interesting. I've given up even attempting to reply to his posts since he only accepts comments that agree with his viewpoint. Not really in the spirit of blogging, I call it "blinketing", no peripheral vision!

[Nigel]

"Own it. Use it daily. Got the latest microcode upgrades just this week...."

Its all coming out now. I knew you were a closet USP fan!!

Also, your probably not doing something properly for HDP to see the external storage ;-P

BTW. If you're desperate I'm pretty sure I could sort it out for you ;-)

[Brutus]

Congratulations for your first year of blogging!
And since you asked for new subjects let's talk a little bit about some new "enhancements" in performance in 5772 and 5773 microcode levels:
I'm not sure if I'm well understanding the new "LUN migration" feature: it seems that EMC added this feature just to help themselves in situations where optimizer itself will fail: you cannot change the protection/layout of devices you can only move hypers from one disk(s) to another(s).
So if you didn't ever used the really bad choice of stripping everything on all disks and separated them with disk groups or other methods what can possible be improved with LUN Migration?
And also if you take into account the fact that you need to have a valid Optimizer License (not so cheap) it results that the new feature only help EMC to solve it's own storage/software performance issues - when optimizer take too much time or it's too ineficient in moving hypers from one group of disks to another.
It would make more sense to have a feature implemented like in Clariion case when you can use lun migration to change the disk layout in order to improve performance.
Please tell me if I'm wrong.

[the storage anarchist]

Changing the disk layout to improve performance is the purpose of Symm Optimizer, and in this mode, SO won't move a hyper onto a different (eq. from a 15K drive to a 10K rpm drive).

Virtual LUN Migration is intended to allow you to relocate the LUN (hypers) into a different tier of storage.

Changing RAID protection type is currently not supported, and that admittedly is a limiting factor. Yet many customers find it quite useful for the LUNs that they most frequently wind up needing/wanting to relocate.

Until changing RAID protection type is supported, host-based migrations are the best option. Host-based migrations are also required by every other vendor's platforms today that supports both "thin" and "fat" provisioning...Open Migrator is an ideal soultion for that kind of migration (as well as changing RAID type and moving from internal server storage to an external array).

Thanks!