<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 13/02/2008 05:24, Joseph L. Casale wrote:
<blockquote
cite="mid:1C8CF1EA1A5B5940B81B0710B2A4C93850BB382BA8@an-ex.ActiveNetwerx.int"
type="cite">
<blockquote type="cite">
<pre wrap="">But I really have a hunch that it is just a lot of I/O wait time due to
either metadata maintenance and checkpointing and/or I/O failures, which
have very long timeouts before failure is recognized and *then*
alternate block assignment and mapping is done.
</pre>
</blockquote>
<pre wrap=""><!---->
One of the original arrays just needs to be rebuilt with more members, there are no errors but I believe you are right about simple I/O wait time.
Going from sdd to sde:
# iostat -d -m -x
Linux 2.6.18-53.1.6.el5 (host) 02/12/2008
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdd 0.74 0.00 1.52 42.72 0.11 1.75 86.41 0.50 11.40 5.75 25.43
sde 0.00 0.82 0.28 1.04 0.00 0.11 177.52 0.13 98.71 53.55 7.09
Not very impressive :) Two different SATA II based arrays on an LSI controller, 5% complete in ~7 hours == a week to complete! I ran this command from an ssh session from my workstation (That was clearly a dumb move). Given the robustness of the pvmove command I have gleaned from reading, if the session bales how much time am I likely to lose by restarting? Are the checkpoints frequent?
Thanks!
jlc
</pre>
</blockquote>
<br>
Running iostat like this will give you utilisation statistics since
boot, which will not be inidicative of what's happening now. If you
give it a reporting interval, say 10 seconds (iostat -m -x 10), I am
guessing you will see very different data (likely high r/s, w/s, await,
and derived values).<br>
</body>
</html>