[1466] in linux-scsi channel archive
Re: Disk array latency theory (was: EATA performance issues)
daemon@ATHENA.MIT.EDU (Ingo Molnar)
Tue Feb 25 06:15:10 1997
Date: Tue, 25 Feb 1997 12:13:37 +0100 (MET)
From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
To: Dario_Ballabio@milano.europe.dg.com
cc: linux-raid@vger.rutgers.edu, linux-scsi@vger.rutgers.edu,
lma@varesearch.com
In-Reply-To: <199702250827.JAA19306@milano.europe.dg.com>
On Tue, 25 Feb 1997 Dario_Ballabio@milano.europe.dg.com wrote:
> T T n-1
> / / nt n
> E(Ln) = | tdP = | t ----- dt = ---- T
> / / n n+1
> 0 0 T
>
>
> So, for example for RAID 1 (mirroring with 2 disk images), n = 2 and
> the average latency is (2/3)T.
> When increasing n, E(Ln) -> T, so when using a real RAID configuration
> one should always expect a full revolution latency, instead of the
> half revolution of a single disk.
one sidenote: you are assuming that tyical access is syncronized. In Linux
there are seldom cases where access is 'syncron' (in the sense that a
request is issued and the caller waits for that request to be completed).
thus you should weight the above function with a typical workload
function, which in turn is nicely distributed for most filesystem access
types, and thus the random effect of usually nonpredictable head positions
is evened off by filesystem clustering, request ordering and the asyncron
readahead daemon.
so the typical operation on the array is a series of highly asyncron
simple operations, plus some kind of sync event at the end. In this case,
divide rotational latency by M, where M is the typical length of an
'operation batch'.
in Linux, write batches are unlimited normally (some kind of limit is
defined by NR_REQUEST), reads too (although upper layers do more waits on
reads than writes, for obvious reasons).
the Linux RAID-1 driver does all things asyncron too, requests issuers
must explicitly wait for a request, they do not get blocked. (there is a
load-dependent number of RAID-1 kernel threads around to handle such and
error recovery issues)
-- mingo