|
[Veritas-bu] Fragment Size
2002-05-15 13:01:07
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_01C1FC32.1AF235D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Richard , if you have to write a 2Go file (fragment set to 2 Go) to a =
tape
and you encounter EOT (End Of Tape), before the end of write ...
I assume that Netbackup have to rewrite all the fragment but maybe it's
possible to split a fragment??
I think that Larry should know how this works.
F@brice
-----Message d'origine-----
De : Richard Hellier [mailto:rlh AT lsil DOT com]
Envoy=E9 : mercredi 15 mai 2002 18:51
=C0 : veritas-bu AT mailman.eng.auburn DOT edu
Objet : Re: [Veritas-bu] Fragment Size
We run with a fragment size of 2G and, AFAIK, backup speed is not
impacted at all (or significantly, at least). The gain comes when
doing
a restore as the process can skip across whole fragments before =
reaching
the area of the tape containing the material to be restored.
With a zero fragment size (i.e. don't fragment), the tar images
are written as a single monolithic block which is slower to scan
through.
I didn't understand Fabrice's point about end of tape -- I don't
see how running "off the end" is better / worse if using fragments or
not.
Can someone enlighten me on this point?
Cheers,
Richard.
------_=_NextPart_001_01C1FC32.1AF235D0
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] Fragment Size</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Richard , if you have to write a 2Go file (fragment =
set to 2 Go) to a tape and you encounter EOT (End Of Tape), before the =
end of write ...</FONT></P>
<P><FONT SIZE=3D2>I assume that Netbackup have to rewrite all the =
fragment but maybe it's possible to split a fragment??</FONT>
</P>
<P><FONT SIZE=3D2>I think that Larry should know how this works.</FONT>
</P>
<P><FONT SIZE=3D2>F@brice</FONT>
</P>
<P><FONT SIZE=3D2>-----Message d'origine-----</FONT>
<BR><FONT SIZE=3D2>De : Richard Hellier [<A =
HREF=3D"mailto:rlh AT lsil DOT com">mailto:rlh AT lsil DOT com</A>]</FONT>
<BR><FONT SIZE=3D2>Envoy=E9 : mercredi 15 mai 2002 18:51</FONT>
<BR><FONT SIZE=3D2>=C0 : veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Objet : Re: [Veritas-bu] Fragment Size</FONT>
</P>
<BR>
<P> <FONT SIZE=3D2>We run =
with a fragment size of 2G and, AFAIK, backup speed is not</FONT>
<BR><FONT SIZE=3D2>impacted at all (or significantly, at =
least). The gain comes when</FONT>
<BR><FONT SIZE=3D2>doing</FONT>
<BR><FONT SIZE=3D2>a restore as the process can skip across whole =
fragments before reaching</FONT>
<BR><FONT SIZE=3D2>the area of the tape containing the material to be =
restored.</FONT>
</P>
<P> <FONT SIZE=3D2>With a =
zero fragment size (i.e. don't fragment), the tar images</FONT>
<BR><FONT SIZE=3D2>are written as a single monolithic block which is =
slower to scan</FONT>
<BR><FONT SIZE=3D2>through.</FONT>
</P>
<P> <FONT SIZE=3D2>I didn't =
understand Fabrice's point about end of tape -- I don't</FONT>
<BR><FONT SIZE=3D2>see how running "off the end" is better / =
worse if using fragments or</FONT>
<BR><FONT SIZE=3D2>not.</FONT>
<BR><FONT SIZE=3D2>Can someone enlighten me on this point?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Cheers,</FONT>
</P>
<P><FONT SIZE=3D2>Richard.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1FC32.1AF235D0--
|
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Veritas-bu] Fragment Size, Carlos Perales
- [Veritas-bu] Fragment Size, Brochart, Fabrice
- [Veritas-bu] Fragment Size, White, Steve
- [Veritas-bu] Fragment Size,
Brochart, Fabrice <=
- [Veritas-bu] Fragment Size, Sparks, Klenton
- [Veritas-bu] Fragment Size, Shahar.Shaynis AT ecitele DOT com
- [Veritas-bu] Fragment Size, Max.Booth AT ubsw DOT com
|
|
|
