Veritas-bu

[Veritas-bu] iostat during duplication - strange

2002-04-03 13:41:38
Subject: [Veritas-bu] iostat during duplication - strange
From: Mark.Donaldson AT experianems DOT com (Donaldson, Mark)
Date: Wed, 3 Apr 2002 11:41:38 -0700
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1DB3F.30AA3C10
Content-Type: text/plain;
        charset="iso-8859-1"

So here I am, testing the I/O characteristics of my new buffer settings for
duplications.  I'm doing an "iostat" and I see the following for the two
tape drives that are source and destination for this dup.

$ sudo iostat -xtnc 5 | egrep "rmt.[01]|wsvc"
  r/s  w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
 32.0  0.0 8192.1    0.0  0.0  1.0    0.0   31.1   0 100 rmt/0
  0.0 14.0    0.0 3584.0  0.0  0.6    0.0   45.4   0  63 rmt/1
  r/s  w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
 31.2  0.0 7986.9    0.0  0.0  1.0    0.0   31.9   0  99 rmt/0
  0.0 16.8    0.0 4300.6  0.0  0.7    0.0   38.7   0  65 rmt/1
  r/s  w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
 31.0  0.0 7935.8    0.0  0.0  1.0    0.0   32.1   0 100 rmt/0
  0.0 16.4    0.0 4198.3  0.0  0.5    0.0   32.8   0  54 rmt/1

It's easy to see which is source and which is destination.  The strange
thing, consistent over about 10 minutes of this, is the nearly 2-to-1
difference between read volume (kr/s) & write volume (kw/s).  

My first thought was blocking factors for read and write were different but
the iostat man page says these columes are KBytes/sec not blocks/sec.  

Next I speculated that it was read-ahead buffering but eventually the
buffers would be full and I'd see the volume turn around - which I haven't.


I've verified that this is the only source and destination tapes in use -
the other tapes in other drives are doing other work.

tpconfig has each of these devices with the same settings, /dev/rmt/[01]cbn.
I would expect input volumes to match output volumes since the compression
is taking on the device.

So the new quandry - why doesn't the read volume match the write volume?

BTW: Sol 2.6 master/media, VxNB 3.4.1.

-----------------------------------------------------------------------
   Mark Donaldson - Sr. Systems Engineer
   Experian EMS - Denver Colorado
-----------------------------------------------------------------------

------_=_NextPart_001_01C1DB3F.30AA3C10
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>iostat during duplication - strange</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>So here I am, testing the I/O characteristics of my =
new buffer settings for duplications.&nbsp; I'm doing an =
&quot;iostat&quot; and I see the following for the two tape drives that =
are source and destination for this dup.</FONT></P>

<P><FONT SIZE=3D2>$ sudo iostat -xtnc 5 | egrep =
&quot;rmt.[01]|wsvc&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp; r/s&nbsp; w/s&nbsp;&nbsp; kr/s&nbsp;&nbsp; =
kw/s wait actv wsvc_t asvc_t&nbsp; %w&nbsp; %b device</FONT>
<BR><FONT SIZE=3D2>&nbsp;32.0&nbsp; 0.0 8192.1&nbsp;&nbsp;&nbsp; =
0.0&nbsp; 0.0&nbsp; 1.0&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; =
31.1&nbsp;&nbsp; 0 100 rmt/0</FONT>
<BR><FONT SIZE=3D2>&nbsp; 0.0 14.0&nbsp;&nbsp;&nbsp; 0.0 3584.0&nbsp; =
0.0&nbsp; 0.6&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; 45.4&nbsp;&nbsp; =
0&nbsp; 63 rmt/1</FONT>
<BR><FONT SIZE=3D2>&nbsp; r/s&nbsp; w/s&nbsp;&nbsp; kr/s&nbsp;&nbsp; =
kw/s wait actv wsvc_t asvc_t&nbsp; %w&nbsp; %b device</FONT>
<BR><FONT SIZE=3D2>&nbsp;31.2&nbsp; 0.0 7986.9&nbsp;&nbsp;&nbsp; =
0.0&nbsp; 0.0&nbsp; 1.0&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; =
31.9&nbsp;&nbsp; 0&nbsp; 99 rmt/0</FONT>
<BR><FONT SIZE=3D2>&nbsp; 0.0 16.8&nbsp;&nbsp;&nbsp; 0.0 4300.6&nbsp; =
0.0&nbsp; 0.7&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; 38.7&nbsp;&nbsp; =
0&nbsp; 65 rmt/1</FONT>
<BR><FONT SIZE=3D2>&nbsp; r/s&nbsp; w/s&nbsp;&nbsp; kr/s&nbsp;&nbsp; =
kw/s wait actv wsvc_t asvc_t&nbsp; %w&nbsp; %b device</FONT>
<BR><FONT SIZE=3D2>&nbsp;31.0&nbsp; 0.0 7935.8&nbsp;&nbsp;&nbsp; =
0.0&nbsp; 0.0&nbsp; 1.0&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; =
32.1&nbsp;&nbsp; 0 100 rmt/0</FONT>
<BR><FONT SIZE=3D2>&nbsp; 0.0 16.4&nbsp;&nbsp;&nbsp; 0.0 4198.3&nbsp; =
0.0&nbsp; 0.5&nbsp;&nbsp;&nbsp; 0.0&nbsp;&nbsp; 32.8&nbsp;&nbsp; =
0&nbsp; 54 rmt/1</FONT>
</P>

<P><FONT SIZE=3D2>It's easy to see which is source and which is =
destination.&nbsp; The strange thing, consistent over about 10 minutes =
of this, is the nearly 2-to-1 difference between read volume (kr/s) =
&amp; write volume (kw/s).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>My first thought was blocking factors for read and =
write were different but the iostat man page says these columes are =
KBytes/sec not blocks/sec.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Next I speculated that it was read-ahead buffering =
but eventually the buffers would be full and I'd see the volume turn =
around - which I haven't.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>I've verified that this is the only source and =
destination tapes in use - the other tapes in other drives are doing =
other work.</FONT></P>

<P><FONT SIZE=3D2>tpconfig has each of these devices with the same =
settings, /dev/rmt/[01]cbn.&nbsp; I would expect input volumes to match =
output volumes since the compression is taking on the =
device.</FONT></P>

<P><FONT SIZE=3D2>So the new quandry - why doesn't the read volume =
match the write volume?</FONT>
</P>

<P><FONT SIZE=3D2>BTW: Sol 2.6 master/media, VxNB 3.4.1.</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
--------</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Mark Donaldson - Sr. Systems =
Engineer</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Experian EMS - Denver Colorado</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
--------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DB3F.30AA3C10--