SRDF write performance with Larger Lun Sizes.

Your hyper sizes are 25gb or 25GB ? So how large are your symdevs ? 50GB ? 75GB ?

FYI: A hyper of slice is 1 piece of the symdev. If a disk is cut into slices, several slices or hypers from several disks combined form a symdev.

Forgive me for nagging.

The best practices paper has been updated to include reasons you might want to use striped meta volumes over concatenated ones.

Overall RAID1 will give you the best performance, followed by RAID5 (3+1 is generally better performing on thin than 7+1) and then RAID6.

You need enough TDATs spread across enough drives to handle the workload.  You may need more drives with RAID5 than RAID1 and even more if you choose RAID6.

It is quite likely the presentation you are looking for won't be posted on the EMC World site, since it had a lot of specific performance data in it.  However if it is the presentation I'm thinking of, it is already posted on the internal EMC site "SPEED" where the EMC folks that are performance gurus can download.

Thanks for the nagging.    I consider the symdev and hyper the same thing unless i make a meta . Then the symdev is the meta device and the hypers are the members of the meta.

Ok Thanks... i will have to see if one of my insiders can get a hold of it for me. 

Jason,

Thanks for the reply...  I figured that i needed to make datadevs and put them in a pool.  The problem now is to delete all the symdevs since i cant convert them.

Striped vs Concat -  If you read best practices guide they say Concat.  I did attend a session at EMC world on performance and Thin provisioning and they said

best performance was  striped for 3raid5 .   That was also based on 16 datadevs per disk.

Im waiting for those slides to be available so i can confirm what i wrote down.

Most people in EMC will consider a hyper a physical split on a disk.  With mirrored this is almost the same as a logical device, but there is two hypers that make up a RAID1 logical.  With RAID5 3+1 there are 4 hypers on 4 disks, etc.  

Split, hyper, slice.....

With RAID1 this is indeed the same size as the symdev, so that's where the confusion comes from.

But in the end you cannot address a split/slice/hyper, but you can address a symdev or the symdev that's the head of a meta.

Talking about hypers is almost as bad as talking about SAN when in fact you mean the storage array.

striped meta is heaps better with SRDF/S to mitigate write serialization, especially with hosts with no LVM such as Windows

the issue with striped metas is there is currently no way to do a native online expansion of a thin striped meta

so the current decision point today can hinge around the presence of an LVM on your hosts

I was checkng my notes from the session ..     Striped meta is better due to locality of data.  

hypers make you cringe.....  I agree its REALLY important stuff .  Im going to home to tell my 6 year old not to make the same mistake i made this morning.

I know we have had this discussion before as well RRR and I'm going to back you up here too. I cringe when folks refer to addressing hypers. A hyper is a component (building block) that can be put together with other hypers to make a device. There isa circumstance where a hyper can be made into a device without adding more hypers, but that makes me cringe too (unprotected BCVs).

These are standard definitions in EMC documentation, and while it may sound picky to some, a common language will prevent misunderstandings that could have been avoided :-)

I think the "LUN" thing is even worse for people coming in from a CLARiiON (or other vendor) background... trying to fit the Symm concepts into their existing mind set. I was one of those coming from pure CLARiiON into a new Symm environment and it took a while to get things straight so that I didn't try to treat my Symm like a big fast CX.

I think RRR will agree with me that the point isn't so much that there is a right and a wrong, but the use of a consistent "language" so that everyone can be fairly certain they are talking about the same thing. There are times when it can make a huge difference in a discussion if you are talking about two different components but both thinking you are talking about the same thing.

The definitions I choose to stick with are the ones that seem to be the most prevalent among the EMC engineers and support personnel as well as the official EMC documentation. I try to be flexible in understanding what others are referring to, but the more I can influence the use of common definitions the more time we can spend solving problems as opposed to time spent defining them in the first place.

I will apologize if the tone of my message came across as too harsh, but I won't apologize for trying to drive forward the consistent use of terms relevant to the platforms we rely on day in and day out.

> I think RRR will agree with me that the point isn't so much that there is a right and a wrong, but the use of a consistent "language" so that everyone can be fairly certain they are talking about the same thing. There are times when it can make a huge difference in a discussion if you are talking about two different components but both thinking you are talking about the same thing.

Consistent language is indeed what you'd look for, if you talk about "SAN" today and "Storage" tomorrow, people certainly WILL get confused. And if you're consistent about hypers, symdevs, SAN, storage and so on, people always know what you're talking about.

Now it's up to us to educate the rest of the world