are IOPS increased while using the WIL ?

Question

I'm trying to do some calculation on IOPS within a Clariion and the write penalty (2) for RAID1 (4 for RAID5) is clear to me, but what if the LUN is participating in replication ? Wil the write to the Write Intend Log count as an IO as well ?
I can imagine not since the WIL is only a bitmap which is in memory as well. Can somebody please clarify this for me ?

I also know this write penalty is slightly different on DMX, especially with the new enginuity. Does anybody know if this is also the case for the newer FLARE codes ?

And finally something about Clones: again on DMX with the 72 code there's something like Asynchronous Copy On First Access, so the immediate penalty on access is almost gone. Is something like that also introduced on Clariion yet ?

All this should be taken into account when calculating the IOPS and therefor the spindel requirements.

calle2 · Accepted Answer

Hi guys,I couldn¿t help but to notice your interesting conversation and I would like to add my two pence worth to the mix¿According to my notes from my EXCELLENT EMC CLARiiON performance course by Steve Stead: ¿The Write Intent Log (WIL), will, if used, always be updated when the primary image changes. This imposes the cost of an extra write, and adds additional latency to the host I/O.¿I hope this helpsCarl

mpi2 · Answer

Hy,I also can't imagine that the bitmapping process count as an IO... but I don't know.Another thing to consider for calculation: add the percents of the disk crossings to iops calc. best regardsManfred

RRR · Answer

That's a good one: counting misalignment as extra IOps ! The problem with this is that you can't tell how much extra IOps there will be, because it depends on the block size. For 4kB blocks the extra IOps will be 12,5% (4kB / 32kB = 1/8).
And if you can't have full stripe writes because of this, worst case it doubles the number of I/Os, because misalignment then generates 2 full stripe writes instead of one..... Worst case of course.

mpi2 · Answer

You are right, but I do not mean the crossings due to misalignment.If the access pattern of the application is clear why not?

RRR · Answer

I'm not sure what you mean.... If everything is aligned and you know the IOps behaviour of your application, IMHO this should be enough to start a calculation. Disk crossings are a natural fenomenon due to the fact that data is spread accross multiple disks and full stripe writes are the writes that determine the number of IOps that will take place. In a misaligned setup however there will be more I/Os taking place than in an aligned setup.
And besides that: a disk crossing by itself is an electronical switch / delay measured in micro seconds and cannot be taken into account in the whole IOps calculation.

So what percentage should I add to my calculation due to disk crossings ? I think zero.

mpi2 · Answer

Even if your LUN is aligned you have disk crossings as you stated normal phenomenon.
You are right it normally suffice if you know the iops and the behavior of your app.
if you doing 4k writes and somebody is spitting you a 2k IO between (can happen everytime, can't?), then you'll have disk crossings -> this is what I mean. (maybe it is anyway wrong..)

I thought being accuratly when doing a calculation:
Here is what i'm thinking.
Application: 1000 IOps 4k random (most of them) 30% writes 70% reads R 1/0
Disk Crossings maximum.(4k/64k=6,25%)

300 writes/sek --> 600 writes/sek to disk + %diskcrossing(6,25) = 637,5

R5 :
--> 1200 writes (parity write cannot cause disk crossing and so->) 600 writes +diskcrossing% = again 637,5 + parity 600 = 1237,5

Maybe it is a big error in reasoning...

RRR · Answer

Your I/O capacity is based on the number of spindels of a certain type (10k of 15k) and what your storage can handle is the sum of IOps per spindel.

My problem with your "story" is that you state that a disk crossing is an extra I/O, while in fact IMHO it doesn't matter where this I/O is placed: on the next block, track, or even another disk.
I suppose you could try to measure this and drill down in the number of IOs and do the math. Based on that I would like to believe you, other wise I must say I'd rather stay with the general rule of thumbs about read IOs and write penalties.

mpi2 · Answer

Hy RRR,First thank you for the interessing discussion.The Clariion track called 'Element Size' measured in Blocks is default 128 =64k.An earlier Flare version (i think prior Flare 19 ) you had the chance to change the element size to 32k or higher (i think up to 256k...).best regardsManfred

RRR · Answer

Is a Clariion track 32kB or 64kB ? Does this change with a certain Flare code ? I always thought it was 32kB while for DMX2 it's 32kB and DMX3 64kB.

dynamox · Answer

Ah yes, you're right. I remember this 128 value (Ihaven't touched a Clariion in ages.... being stuckhere with a few DMX's...) that's a blessing

RRR · Answer

I had telephone calls and even on site visits from an EMC Performance guru and we discussed the disk crossing issue.... but I'm still not sure about this. I'm simply lost there....

After an hour or two on the phone with him I decided it's probably best to stik with the best practice - known - values and perhaps reconcider those when it's going to be a tight setup with a customer who really sits on his money and really really reallly wants to get the most out of every penny he's paying.... But then again: for every few hours of me, he could also buy an extra spindle.... hehehehe

RRR · Answer

Ah yes, you're right. I remember this 128 value (I haven't touched a Clariion in ages.... being stuck here with a few DMX's...)

RRR · Answer

Blessing ? Ok... for sure... but still you can see developments going on where technology from Clariion migrates to DMX For example snapshots, virtual lun technology in the software section and the DAE's in the hardware section..... Clariion isn't all that bad.

RRR · Answer

I've had the same course with Steve Stead, but in my memory and in all my notes I can't find any hint saying that you need to take an extra IO into account when you're using the WIL. If you could translate a WIL biitmap I/O to a true I/O, I'm sure Steve would have mentioned this.
I'm asking this question because I'm just not sure what to do with this. Perhaps it's even an option to simply send an email to him. I think I will do just that. Thanks for reminding me !

CLARiiON

are IOPS increased while using the WIL ?

Was this post helpful?