Re: IOPS from RAID units

s.bridge@xxxxxxxxx wrote:
Literature from storage suppliers show performance claims of over 1000
random IOPS.
If they are really random over an array, are they not limited by the
seek time ?
So an average seek time of 8.2 ms for a SATA disk would imply a
maximum of 122 seeks per
second. So how can you claim over a 1000 random IOPS ?

Aside from the considerations already mentioned, there is the fact that contemporary disks can reorder (most) requests in their queues to expedite aggregate throughput. If request queues are allowed to become fairly lengthy, this can more than double the I/O rate from what a serial request stream would see (i.e., a disk that could service 80 small random requests per second in a serial stream could service close to 200 if allowed to reorder a few dozen requests in its queue, and the fastest current disks which can handle about 180 serial small random requests per second could service close to 400 under such ideal - for this particular benchmark - conditions).

'Short-stroking' a disk (using only a small, contiguous fraction of its capacity to hold the relevant data) can improve performance a bit more: current disks (very roughly - you can actually calculate this by examining the relationship of average seek time, defined as being 1/3 of the way across the entire disk surface, to maximum seek time from start to end of the disk) accelerate the head for only about 1/6 of the distance of a full-stroke seek, decelerate it for another 1/6 of the distance at the end of the seek, and coast the rest of the way, which just happens to minimize nominal 'average' seek times. So (neglecting head-settling time at the end of the seek, though it rapidly becomes non-negligible as seeks get shorter) if you limit the data to, say, 1/12 of the disk surface, then the *worst-case* seek for data on that disk will be only half the duration of the *average* seek on a full disk (and the *average* seek time for that data on the disk will be less than 30% of the average seek time on a full disk).

Unfortunately, you can't combine these two approaches very effectively: short-stroking is great for serial small random requests, and queue optimization is great for parallel small random requests (at least as long as the long individual service times can be tolerated: that's the price one pays for per-disk throughput in this case), but queue optimization does nothing for serial request streams and while short-stroking does help parallel request streams the major reduction it makes in average seek time means that there's a great deal less that queue optimization can accomplish (though it can still help reduce the rotational latency component significantly).

- bill
.

Relevant Pages

  • Re: [PATCH 7/13]: PCI Err: Symbios SCSI driver recovery
    ... Any queued requests stay queued until they are fulfilled. ... file system corruption because any inconsistent state on the disk ... be generic bugs, rather than PCI error recovery related bugs. ... even though it is still pending in firmware ...
    (Linux-Kernel)
  • Re: File Fragmentation
    ... That is because you are picturing a single unbuffered thread of control as running the o/s, while the opposite is the case: the o/s gives the illusion of a unique thread of control to each of (consults ... Requests that fall through the buffer search unsatisfied are queued for the disk from ALL processes, and are satisfied from time to time as the o/s decides. ... The way we as users look at files, you are right, there is no next fragment if the file system does its job well. ...
    (comp.os.linux.misc)
  • Re: which PC
    ... address pointers, all of which can slow the file system, ... of disk seeks over longer areas". ... The disk certainly wouldn't and would rearrange the requests back into the ... You can't avoid fragmentation if the file system is nearly full. ...
    (rec.photo.digital)
  • Re: Random file I/O regressions in 2.6 [patch+results]
    ... If the 2.4 and 2.6 disk accounting statitics are to be believed, ... Given that 2.6 is issuing less IO requests it should be performing faster ... throughput despite this is that the disk is performing writeback caching ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)