[Veritas-bu] iostat during duplication - strange
2002-04-03 15:04:36
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_01C1DB4A.C749F420
Content-Type: text/plain;
charset="iso-8859-1"
I am demultiplexing during duplication - but I thought that multiplexed
backups were interwoven fragments. Shouldn't I be reading one image's
fragment, skipping over another, then reading another appropriate fragment?
(you know: "mt fsf #")
Your comments suggest that data within fragments is from multiple clients?
If this is the case, I may have the answer to my slow duplications - I have
to read through piles of junk to cull out what I want to duplicate.
-----Original Message-----
From: Ballowe, Charles [mailto:CBallowe AT usg DOT com]
Sent: Wednesday, April 03, 2002 12:41 PM
To: 'Donaldson, Mark'
Subject: RE: [Veritas-bu] iostat during duplication - strange
are you maybe de-multiplexing durring duplication?
-----Original Message-----
From: Donaldson, Mark [mailto:Mark.Donaldson AT experianems DOT com]
Sent: Wednesday, April 03, 2002 12:42 PM
To: Veritasbu (E-mail)
Subject: [Veritas-bu] iostat during duplication - strange
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_01C1DB4A.C749F420
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>RE: [Veritas-bu] iostat during duplication - strange</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I am demultiplexing during duplication - but I =
thought that multiplexed backups were interwoven fragments. =
Shouldn't I be reading one image's fragment, skipping over another, =
then reading another appropriate fragment? (you know: "mt =
fsf #")</FONT></P>
<P><FONT SIZE=3D2>Your comments suggest that data within fragments is =
from multiple clients?</FONT>
</P>
<P><FONT SIZE=3D2>If this is the case, I may have the answer to my slow =
duplications - I have to read through piles of junk to cull out what I =
want to duplicate.</FONT></P>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ballowe, Charles [<A =
HREF=3D"mailto:CBallowe AT usg DOT com">mailto:CBallowe AT usg DOT
com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 03, 2002 12:41 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Donaldson, Mark'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Veritas-bu] iostat during duplication =
- strange</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>are you maybe de-multiplexing durring =
duplication?</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Donaldson, Mark [<A =
HREF=3D"mailto:Mark.Donaldson AT experianems DOT com">mailto:Mark.Donaldson@exp=
erianems.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 03, 2002 12:42 PM</FONT>
<BR><FONT SIZE=3D2>To: Veritasbu (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: [Veritas-bu] iostat during duplication - =
strange</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>So here I am, testing the I/O characteristics of my =
new buffer settings for</FONT>
<BR><FONT SIZE=3D2>duplications. I'm doing an "iostat" =
and I see the following for the two</FONT>
<BR><FONT SIZE=3D2>tape drives that are source and destination for this =
dup.</FONT>
<BR><FONT SIZE=3D2>$ sudo iostat -xtnc 5 | egrep =
"rmt.[01]|wsvc" </FONT>
<BR><FONT SIZE=3D2> r/s w/s kr/s =
kw/s wait actv wsvc_t asvc_t %w %b device </FONT>
<BR><FONT SIZE=3D2> 32.0 0.0 8192.1 =
0.0 0.0 1.0 0.0 =
31.1 0 100 rmt/0 </FONT>
<BR><FONT SIZE=3D2> 0.0 14.0 0.0 3584.0 =
0.0 0.6 0.0 45.4 =
0 63 rmt/1 </FONT>
<BR><FONT SIZE=3D2> r/s w/s kr/s =
kw/s wait actv wsvc_t asvc_t %w %b device </FONT>
<BR><FONT SIZE=3D2> 31.2 0.0 7986.9 =
0.0 0.0 1.0 0.0 =
31.9 0 99 rmt/0 </FONT>
<BR><FONT SIZE=3D2> 0.0 16.8 0.0 4300.6 =
0.0 0.7 0.0 38.7 =
0 65 rmt/1 </FONT>
<BR><FONT SIZE=3D2> r/s w/s kr/s =
kw/s wait actv wsvc_t asvc_t %w %b device </FONT>
<BR><FONT SIZE=3D2> 31.0 0.0 7935.8 =
0.0 0.0 1.0 0.0 =
32.1 0 100 rmt/0 </FONT>
<BR><FONT SIZE=3D2> 0.0 16.4 0.0 4198.3 =
0.0 0.5 0.0 32.8 =
0 54 rmt/1 </FONT>
<BR><FONT SIZE=3D2>It's easy to see which is source and which is =
destination. The strange</FONT>
<BR><FONT SIZE=3D2>thing, consistent over about 10 minutes of this, is =
the nearly 2-to-1</FONT>
<BR><FONT SIZE=3D2>difference between read volume (kr/s) & write =
volume (kw/s). </FONT>
<BR><FONT SIZE=3D2>My first thought was blocking factors for read and =
write were different but</FONT>
<BR><FONT SIZE=3D2>the iostat man page says these columes are =
KBytes/sec not blocks/sec. </FONT>
<BR><FONT SIZE=3D2>Next I speculated that it was read-ahead buffering =
but eventually the</FONT>
<BR><FONT SIZE=3D2>buffers would be full and I'd see the volume turn =
around - which I haven't.</FONT>
</P>
<P><FONT SIZE=3D2>I've verified that this is the only source and =
destination tapes in use -</FONT>
<BR><FONT SIZE=3D2>the other tapes in other drives are doing other =
work.</FONT>
<BR><FONT SIZE=3D2>tpconfig has each of these devices with the same =
settings, /dev/rmt/[01]cbn.</FONT>
<BR><FONT SIZE=3D2>I would expect input volumes to match output volumes =
since the compression</FONT>
<BR><FONT SIZE=3D2>is taking on the device.</FONT>
<BR><FONT SIZE=3D2>So the new quandry - why doesn't the read volume =
match the write volume? </FONT>
<BR><FONT SIZE=3D2>BTW: Sol 2.6 master/media, VxNB 3.4.1. </FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------- </FONT>
<BR><FONT SIZE=3D2> Mark Donaldson - Sr. Systems Engineer =
</FONT>
<BR><FONT SIZE=3D2> Experian EMS - Denver Colorado </FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------- </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1DB4A.C749F420--
|
|
|