No subject


Sat Oct 14 20:46:50 EDT 2006


cd /
tar -cf $bkdir/monthly.tar ./ $bkoptions
tar -cf /dev/st0 ./ $bkoptions

I don't know why you are chasing down the directory tree twice.  That would
be very slow.  After you have created the file on disk, why not just use that
copy "squirted" onto the tape with dd?

I would have done this instead:

cd /
tar -cf $bkdir/monthly.tar ./ $bkoptions
dd if=$bkdir/monthly.tar of=/dev/st0

at worst in restoring you would:

dd if=/dev/st0|(cd $bkdir ; tar xf -)

even if tar xf /dev/st0 did not work (and it should)

On Ultrix we found that doing a tar onto a streaming tape drive went REALLY
SLOW.  The streaming tape drive would write data so fast that tar could not
keep up.  Sometimes the tape buffer would be empty and the streaming tape would
write null blocks for a while, waiting for more data, but wasting a lot of
tape.  If it did not get any, the tape would stop streaming, back up, wait for
the buffer to fill, get up to speed and start streaming again.  At best it
wasted tape, at worst it made backup PAINFULLY (REALLY PAINFULLY, LIKE HAVING
A ROOT CANAL) SLOW.

We found that having multiple buffers in the tape read and write i/o buffer ring
made this go faster, but this required changing a bunch of commands to make
them all know about multi-buffering.  Instead of that we just changed "dd"
so "dd" knew how to multi-buffer, with the option to tell it how many buffers
to allocate.  Then we did out backups like this:

tar cf - ./ | dd bufferno=SOME-FREAKING-LARGE-NUMBER
                  buffersize=ANOTHER-LARGE-FREAKING-NUMBER of=/dev/tape

or something like that, and the tape drive was relatively happy.  Backups went
from taking overnight to 10 minutes.  Really.

By the way, when we did the tar by itself with the streaming tape, often
the tape lost position halfway through, and IF it was able to re-position
itself, the tar could continue.  Sometimes it could not re-position itself,
and (worse yet) sometimes the tape drive THOUGHT it had re-positioned itself.
But if *you* had to stop and back up about 30,000 times writing out 95
Megabytes of data, *you* probably would lose *your* positioning too.  I know
I did one dark night in Dublin as I was going pub-crawling......

Tapes, you have to love them, but most of the time you would just like to burn
them.

md
-- 
Jon "maddog" Hall
Executive Director           Linux International(R)
email: maddog at li.org         80 Amherst St. 
Voice: +1.603.672.4557       Amherst, N.H. 03031-3032 U.S.A.
WWW: http://www.li.org

Board Member: Uniforum Association, USENIX Association

(R)Linux is a registered trademark of Linus Torvalds in several countries.
(R)Linux International is a registered trademark in the USA used pursuant
   to a license from Linux Mark Institute, authorized licensor of Linus
   Torvalds, owner of the Linux trademark on a worldwide basis
(R)UNIX is a registered trademark of The Open Group in the USA and other
   countries.




More information about the gnhlug-discuss mailing list