We have SRDF customers that are currently running on older DMX arrays using METAS that are in increments of 8gb. Our new VMAX array has larger drives
so the HYPER sizes are 25 gb. When im desiging SRDF i want to make sure i have as many hypers as possible due to the limit of '1 write pending per hyper' . I have the choice of wasting storage to get the same amount of hypers or i could pool hypers ( datadevs) in to thin pool and prealloc ( thick provision) the hypers in small increments , possible the 8gb again. Should i not worry about this because 74 code has better SRDF performance?
What are other customers doing?
Solved! Go to Solution.
second option is widely used in this situation
so put the hypers into the thin pool as TDATs and then create smaller TDEVs, the SRDF/S write serialization is against the TDEV and not TDAT
next question... concat or striped metas right?
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.
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.
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.
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 :-)
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.
oh geez I called them hypers as well in my post
I actually try and avoid the term hypers when I talk with customers, I try and find out what term they are used to using for such an object, as commonly they have come from another vendor disk array terminology
lun is a fun one to cause confusion as well
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