<   Previous Post  A place to call my...
SVC Questions &...  Next Post:   >

Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Permalink

Barry,Presumably the numbers that you have quoted are the maximums for each type of drive. If one were using them for OLTP type of work you would not be able to run them so fast as the response times would be too great. What would you suggest are the useable IOPS per drive type?

2 localhost commented Permalink

This could get confusing, yet another Barry joining the mix :)<div>&nbsp;</div> As for useable IO/s - the numbers above do reflect a rough useable maximum op rate. I don't claim to be an expert in the physical drive mechanics and algorithms, but from what I've read and been told over the years a drive will actually respond best when its kept busy. The rule of thumb being that a drive works optimally when it has an outstanding queue of around 5 to 8 operations. Therefore loading up a drive close to these limits should be possible and may actually give much better performance than a drive that is idling with just a few operations.<div>&nbsp;</div> Going beyond this queue depth will however sometimes have the opposite effect.

3 localhost commented Trackback

BarryW,<div>&nbsp;</div> I wanted to follow up with two questions to this post. My first question tacks on to your 'queue-depth' statement. I understand that SATA drives don't support queues, and FC drives support a queue depth of 16. I'm pretty sure I got this info from the IBM Redbook, "DS4000 Best Practices and Performance Tuning Guide". Can you explain this a bit further.<div>&nbsp;</div> Secondly, I wanted some clarification on backup. You said that if you plan to backup your IO-intense application (running on FC drives) to SATA, that performance would be degraded. I'm confused because I had backup data pinned as more of a throughput-type of workload, not transactional / IO intense.<div>&nbsp;</div> Could you please help me understand a bit better?Thanks,John

4 localhost commented Permalink

John,<div>&nbsp;</div> While its true that some older SATA drives may not have had any 'on disk' queuing, most SATA drives available today (supporting NCQ Native Command Queuing) do have some queing ability within the drive themselves. Whether a controller actually makes use of NCQ to re-order operations is another matter.<div>&nbsp;</div> So my comments regarding backup are aimed at the advanced Copy services such as FlashCopy and to a greater degree Metro/GlobalMirror. FlashCopy, while yes background copy operations are usually large sequential transfers, and can make use of the comparable MB/s SATA capabilities, if you are performing host I/O (random small transfers in most cases) this will cause 'grain-splits' of smaller random chunks. Meanwhile the drives are doing the larger transfers and so in general the host I/O maybe affected. <div>&nbsp;</div> For replication services, like Metro/GlobalMirror any additional latency introduced by the secondary site will be transfered to the primary site - even in asynchronous cases when buffer space is exhausted. As this is being driven by host I/O rates, likely to be smaller random transfers you are going to be impacted by the slower SATA secondary disks.<div>&nbsp;</div> Hope this helps clarify.