E20-324 VideoILT questions module 4 and 5, please help

Hi Andre,

Thank you for your reply.  I still can't figure out the 2 ratios for 512B.

Q1 . How did they get , 1:160 ( 1x64kib, 3x8kib) and 1:384 ( 3x 64 kib) ?

Why does 1:384 have a (3x 64 kib ) ?

If it is 64 KB,  what should the ratio be ?

Q2 .  For the 100 sequential 256kib,  why 100 x 4 x 4 ?  If it causes 4 COFW why multiply by 4 twice ?

Appreciate your help, as it is challenging trying to figure out things in a videoILT . 

Thank you once again.

If the COFW writes are 1x 64 kB and 2x 8 kB for a total of 80 kB [160 blocks], then the ratio of host write size [512B = 1 block] to COFW writes is 1 block:160 blocks = 1:160. If the COFW performed 3x 64 kB writes it would be 1 block: 384 blocks [192 kB = 3x 64 kB]. COFWs now perform 1x 64 kB and 3x 8 kB [or, very occasionally, 3x 64 kB] so the ratios would be 1:176 and 1:512. For a 64 kB host write [128 blocks], the ratio is 128:176 = 8:11. If the COFW map writes were 64 kB, the ratio would be 128:512 = 1:4. The ratios were for illustration only, are not mentioned in any other EMC documentation, and will not be found in the exam.

For the sequential I/Os, note that a COFW performs 4 writes to the RL. The host I/O size is 256 kB, which is 4 chunks in size, so each host write causes 4 COFWs. The total number of writes is therefore 100 host writes x 4 COFWs per host write x 4 writes per COFW = 100 x 4 x 4. If the question asked how many COFWs are performed, the answer is 100 x 4 per second.

Hi Andre,

Thank you so much for your clear explanation.

Best regards,

Paul

Hi Andre,

There is an example 2 on page 20 of module 5 ,which I am not sure if there is calculation error

"  200 sequential 4kib writes/s to the src lun

RLP sees 200/16x64 kib/s of new data initially - 0.8MB/s  "

Q1.  How should I explain 16 x 64.  For sequential I/O, COFW performs 4 writes so we take 4 x 4Kib writes/s = 16

so if it is 8kib/s writes, then it should 4x8kib = 32

Is this right way to explain it ?

We multiply by 16 x 64kib/s because each chunk is 64kib ?

Q2.  If you do the math , it should be 0.19531 kib/s or 0.000190 MB/s

How did they get 0.8MB/s ?

Thank you for your help.

They key phrase here is 'new data' - we're only looking at data [64 kB chunk] writes, and not the writes to the map area. Because this is sequential I/O with a write size of 4 kB [as I explained before], we do only 1 COFW for every 16 host writes. That's why the term '200/16' is present. The 64 is the size of the chunk - 64 kB - so the initial data rate is 200/16 x 64 kB/s = 12.5 x 64 kB/s = 800 kB/s.

Don't confuse kB/s with kb/s.

In your Q2 answer, you've made a mistake with operator precedence - the division appears first, so should be performed first, and then the multiplication should be performed. In other words, 200/16*64 = (200/16) * 64 and NOT 200/(16 * 64).

Hi Andre,

Thank you once again.  Your help and guidance is really invaluable. 

I have  questions on Mirror View/S extents, my questions are after the given solution.

On page 33 of the course lab 7 , there is a Mirror view /S question:

" Q.  ABC Corp has 2 VNX systems used for MirrorView/S. They are connected by a 15 Mb/s

dedicated link, and their data has a 2:1 compression ratio. The 4 primary mirror LUNs,

each 64 GB in size, have a throughput total of 1,000 8 kB IOPs with a R/W ratio of 3:1.

After the mirrors become fractured, the customer requires them to be fully

synchronized within 2 hours. "

The given solution is as follows :

" LUNs are 64 GiB, therefore extent size is 128 KiB. LUNs perform a total of 250 writes/s. Link is 15 Mb/s, and data is

compressible by 2:1, therefore effective link speed is 30 Mb/s [3 MB/s]. Of this, 250 writes/s x 8 KiB = 2,000 KiB/s is

used by host traffic, leaving 1,000 KiB/s available for synchronization traffic.

1,000 KiB/s for 2 hours is 1,000 KiB/s x 7,200s = 7,200,000 KiB [round to 7200 MiB], therefore the mirrors can fall 7,200

MiB behind, and still synchronize in 2 hours. When a mirror is fractured, each write touches an extent – a new extent

for random writes – so the number of writes [same as the number of extents] is 7,200 MiB / 128 KiB = 57,600 extents.

At a rate of 250 writes/s, it takes 57,600 / 250 seconds [230.4 seconds] to dirty 7,200 MiB of data. The mirrors can

therefore be fractured for a maximum of 230.4 s, or just under 4 minutes.

If the data was sequential, it would take 128 KiB / 8 KiB [extent size divided by write size] to dirty an extent before

moving on to the next. The number of writes is therefore 16 times as great, and the maximum allowable fracture time

also 16 times as great, or 3,686.4 s – just over an hour.

If mirrors are fractured for 9 minutes, a total of 9 x 60 x 250 [writes/s] x 128 KiB [extent size] = 17,280,000 KiB = 16,875

MiB is marked dirty. To transfer this in 7,200 s requires 16,875 / 7,200 = 2.34 MiB/s. Add to this the 2,000 KiB/s [call it 2

MiB/s] for host traffic, for a total of 4.34 MiB/s.

If mirrors are fractured for 60 minutes, the amount of data marked dirty is 60 x 60 x 250 x 128 KiB = 112,500 MiB.

To synchronize this in 2 hours requires 112,500 / 7200 = 15.6 MiB/s to which must be added the 2 MiB/s for host traffic,

for a total of 17.6 MiB/s "

My questions :

I am confused with extents because I read that 256 Gib = 128 Kib, 1kib per extra 2Gib.

Q1 .  From the above lab question : " LUNs are 64 GiB, therefore extent size is 128 KiB" -  How is 128 KiB is obtained ?

  "When a mirror is fractured, each write touches an extent – a new extent "

for random writes – so the number of writes [same as the number of extents] is 7,200 MiB / 128 KiB = 57,600 extents "

Q2. For random writes, why is the number of writes = number of extends ?

Q3. Is there any difference for sequential writes ?

Q4 .  From Module 5, page 111 - extent size is 256 blocks (LUN size is 256 GiB) = 128 KiB  - Again how is 128 KiB obtained ?

Q5. Is there a default extent size ?

Q6.  Are clone extents the same as the mirror view extents  ?

Thank you.

The easiest way to calculate MirrorView/S and Clone extent sizes is to use the size of the LUN in GB as the extent size in blocks, as I've posted elsewhere. There is a minimum extent size of 128 kB, though, so any LUN smaller than 256 GB still has an extent size of 128 kB. There is no default extent size - it depends on the size of the LUN. That should answer Q1 and Q4-Q6.

When we deal with random writes, we assume worst-case conditions. That means that for snapshots every write touches a new chunk, and that for Clones and MirrorView/S mirrors, each write touches a new extent. For sequential writes, it takes a certain number of writes before a new extent is touched. If my extent size is 128 kB, and my sequential write size is 8 kB, then I'll do 16 writes on one extent before moving to the next. The important ratio is therefore that of extent size to I/O size.

Thanks for the explanation.

If we use the size of the LUN in GB as the extent size in KB, for a LUN size of 2 TB we will have 2048 GB.

2048 GB will give us 2147483648 KB , which is not the answer in your reply to someone's posting.

Your replied 2048 GB  = 1024 KB as the extend size.

Q1.  Is this how you obtained 1024 KB ?

For 256 GB, extent size is 128 KB. thereafter every additional 2GB is 1KB

For 2TB,

2048 - 256 = 1792 GB

1792GB / 2 = 896 KB,   hence total is 896 + 128 = 1024 KB.  Is this the correct way to do it ?

Q2.  Please give me an example of random writes, and how you assume a worst case scenario.

Thank you.

I made a mistake in my reply, and have now corrected it. The LUN size in GB is the extent size in blocks, with a minimum of 128 kB.

An example of random writes? Many applications perform random writes. For example, in an email application used by a large number of users, writes to the database [or store, whatever it may be called] will typically be random because the location of user mailboxes will be scattered all over the LUN used for that store. The worst case sceanrio simply means that we assume that each new write touches a new extent - which is typically not what is seen in real-world environments. Put another way, the worst-case scenario assumes no locality of reference, and no rewrites.

My apologies, I was asking for random write examples for worst case scenarios in terms of  extent sizes that you mentioned earlier.

Is this a worst case scenario using 7200MiB/ 128KiB ?

" 1,000 KiB/s for 2 hours is 1,000 KiB/s x 7,200s = 7,200,000 KiB [round to 7200 MiB], therefore the mirrors can fall 7,200

MiB behind, and still synchronize in 2 hours. When a mirror is fractured, each write touches an extent – a new extent

for random writes – so the number of writes [same as the number of extents] is 7,200 MiB / 128 KiB = 57,600 extents "

If the extent size is in blocks 2048 GB, converted to blocks would  = 4294967295 blocks.

That is why I was asking you if my calculation method  to obtain 1023 KB was correct

Thank you

Yes, that's an example of the calculation performed as part of a worst-case scenario.

For a LUN of 2048 GB, the extent size is 2048 blocks = 1024 kB. As I mentioned, take the LUN size in GB, and use that number as the number of blocks in an extent.

Hi Andre,

I came across Lab 3 Part 1 - Analysis of NAR001.nar

" step 2

LUNs 500 and 501 are active. At around 48 minutes into the run, the write‐aside value

for LUN 500 is changed from 2048, the default, to 255 "

I can't find any ' write-aside value' in step 2 mentioned above.  What should i be looking for ?

Refer to the graph below : The only thing that I see that is close to the value 255 is the write size but it can't be at 48 minutes into the run (around the time stamp 8:46 ?) as it is a linear line.   I must be looking at wrong metric.

Thank you once again

The LUN write-aside value, as discussed in the class, can be viewed and modified only with the CLI, and therefore only on a live system. Unisphere Analyzer does not show this value, which is why it was specified as part of the exercise. There's no metric related to write-aside.

If you weren't told that the write-aside value had been changed, you could also conclude [from looking at the NAR] that write cache had been disabled for the LUN. That, of course, could only be true if the NAR showed no write cache hits, and no forced flushes, for that LUN.

Great discussion, guys!!