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
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.
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.