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

Comentários (22)

16 AbdulQadir comentou às Link permanente

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 virtualstorage comentou às Link permanente

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 orbist comentou às Link permanente

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 Scobby comentou às Link permanente

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 orbist comentou às Link permanente

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 EndtoEnd comentou às Link permanente

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 anyters comentou às Link permanente

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