Veritas-bu

[Veritas-bu] Inline tape copy performance

2007-03-06 13:51:13
Subject: [Veritas-bu] Inline tape copy performance
From: jstephens at ti.com (Stephens, John)
Date: Tue, 6 Mar 2007 12:51:13 -0600
There is a known issue with inline copy on a DSSU.   There is an 13 to
20 second delay between each image to be relocated, but not the
fragments, so write big images.  You can see it if you use the infamous
"iostsat -xn 1 | grep rmt" command.  Only way around it is to upgrade to
6.0MP4 where this issue is supposed to be fixed, but we have not tested
it yet since we are not using 6.0 in production.  Here is a copy of our
case response from Veritas.
 
------------------------------ CASE
290-069-042-------------------------------------------------------------
--
Note Added: Aug 12, 2005 21:09:22 GMT
 
Abstract/Summary: working as designed 
Detail: ISSUE: DSSU Relocation is slower after we upgraded
SOLUTION: DSSU relocation is working as designed. Enhancement request
414638 was submitted for design change.
TROUBLESHOOTING:
testing results for 5.0 MP2:
<http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-0
6>
http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-06
<http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-0
6/50MP2/> /50MP2/
The long gap at the beginning is during the tape mount/position.
After the first image starts writing, there is a 13 second gap between
images. This is the time taken to check position/write empty
header/check position, write new header, begin reading. 
testing results for 5.1 MP3:
<http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-0
6>
http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-06
<http://rosspt.veritas.com/evidence/ros/42/290-069-042/testing/rosv240-0
6/51MP3/> /51MP3/
This test is backing up the same data to the same /dssu directory. Same
box/same drives. The only difference is now I've installed 5.1 MP3.
There is the same second gap between images.
>From internal testing, 5.0 MP2 and 5.1 MP3 are behaving the same.
One suggestion to speed up their relocation process would be to have
multiple dssu locations. The gaps between images are for position
checks/writing empty header on terminating duplication and then position
check/new image header on next duplication. With multiple copies, this
needs to occur for all copies so speed will be slower than just one
copy.
 
REFERENCE: Enhancement 414638
----------------------------------------------------------------------
 
 
Regards,
John
 
John D Stephens
jstephens at ti.com
 

________________________________

From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Johnson,
Eric
Sent: Tuesday, March 06, 2007 12:00 PM
To: Santos, Tarso D; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Inline tape copy performance



I get 20-30MB/sec with the inline copy from our DSSU. Without the inline
copy, the speed is 40-50MB/sec. So yes, we see the 50% speed hit. Not
sure why.

 

Eric

 

________________________________

From: Santos, Tarso D [mailto:tarso.santos at sun.com] 
Sent: Tuesday, March 06, 2007 12:49 AM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Inline tape copy performance

 

Hi all, 

I am trying to understand how ITC works, Does it split the IO at the
media server or requires more client streams to generate the multiple
copies?

I have a customer which has a problem similar to this one: 
http://www.arcknowledge.com/gmane.comp.sysutils.backup.veritasbu/2005-12
/msg00502.html
<http://www.arcknowledge.com/gmane.comp.sysutils.backup.veritasbu/2005-1
2/msg00502.html>  

And would like to know your experience on ITC. 

Thanks in advance, 

Tarso 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20070306/f8d664e4/attachment.html