<   Previous Post  IBM to acquire Texas...
IBM Virtual Briefing...  Next Post:   >

Comentários (23)

16 comentou às

Hi, <div>&nbsp;</div> currently we are in process of replacing DS8300 (4 TB row space all on FC drives and 32 GB cache) with V7000 (19 TB raw space on SAS and SSD &amp; 16 GB cache). Is our decision for replacing enterprise class storage with mid range storage is good <div>&nbsp;</div> Regards,

17 comentou às

I have a question on per disk iops you have mentioned here. <br /> It all boils down to following: <br /> 1) rpm i.e. number of rotations per minute , <br /> 2) average rotational latency which is 1/2 of the time it takes (in ms) to complete one rotation. <br /> 3) Disk vendor published seek time , <br /> For example 7200 rpm , 7200 / 60s = 120 times per second <br /> 1s / 120 = 8.33 ms , average latency = 8.33/2 = 4.16 ms <br /> Estimated IOPS = 1 / ( ( (average read seek time+average write seek time) / 2) / 1000) + (average latency / 1000) <br /> IOPS = 1/[{(8.5+9.5)/2}/1000] + [4.16/1000] = 1/(9/1000) + (4.16/1000) = 1000/13.16 = 75 approx <div>&nbsp;</div> Similarly, 10 K RPM drive has around 140 iops per disk <br /> 15K rpm drive has around 175 iops per disk <br /> In your arcticle , per disk iops values are given as: <br /> 100-150 for 7200 rpm drives <br /> 200-300 for 10000 rpm drives <br /> 300-500 for 15000 rpm drives. <div>&nbsp;</div> How did you arrive at these numbers ? OR is it that you measured complete storage array performance iops and divided it by number of disks to arrive at per disk iops?

18 comentou às

vs <div>&nbsp;</div> While formuale can give average theoretical, the main thing I'd contest in you maths is the vendor seek time - this has the most variatiom/ Where rotational latency is fixed, each vendor can improve each generation by improving seek time. <div>&nbsp;</div> 2.5" drives have much better seek times than 3.5 due to smaller platters. Not sure where you get the seek times from - was it a desktop SATA drive - much different to enterprise class drives. <div>&nbsp;</div> As for the numbers I quoted, these are as measured on a V7000 system for single drives, cache disabled, and no RAID. <div>&nbsp;</div> i.e. single disk RAID-0 array created from one drive. Single storage pool created with this "JBOD" array in it. Single vdisk created from the storage pool - V7000 cache disabled so all reads and writes go staright through to drive. Response Curve matrix used to generate a hocket stick curve of the IOPs given concurrent load on the drive. <div>&nbsp;</div> The bottom end of the numbers assume a 10ms cut off, and the high end are when the drive reaches saturation.

19 comentou às

Thanks for your article.. <div>&nbsp;</div> One question. Is there anyway i can strip my data across after i have expand my mdisk?

20 comentou às

At this time, there is no way to expand an mdisk. You have to add another mdisk (array or such) to an existing pool. At that point you can use the alphaworks restripe tool to rebalance the volumes in thats pool.

21 comentou às

hello very good blog, which indica * Enterprise SSD n / a 146GB-400GB * <br /> only in this exact size they are or all sizes between 146 and 400? where is the logic?Deshacer cambiosAlpha <br /> ¿Esta traducción es mejor que la original?Sí, enviar traducciónGracias por los datos proporcionados. <div>&nbsp;</div> thanks

22 comentou às

Anybody has a quick and easy way of calculating the rebuild time for a specific drive in a V7000 or V3700 system ?

23 comentou às

First of all, your articles are a blessing for anyone trying to gather a better understanding of the inner workings of these appliances. Thank-you for taking the time to publish your articles. Now on to my question: I am trying to find the seek and latency times for these drives in my v7000 : HUC109060CSS60 and HUC101212CSS60. I can't seem to find that information in my searches so far.