[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
|
|
|