Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcomsv!resonex!zenon From: zenon@resonex.com (Zenon Fortuna) Subject: Re: Tar and wt driver, was: FreeBSD and Archive SC499 Message-ID: <1994Jan21.100717.23176@resonex.com> Organization: Resonex Inc., Fremont CA References: <1994Jan20.061425.27881@news.csuohio.edu> Date: Fri, 21 Jan 1994 10:07:17 GMT Lines: 31 In article <1994Jan20.061425.27881@news.csuohio.edu> stever@csuohio.edu (Steve Ratliff) writes: > I've been tinkering around with why tar was so slow in backing >up to the wt driver in FreeBSD. The conclusion that I have reached is >that the default blocking size of 20 512byte blocks is way to small for >tar to keep the tape drive streaming very well. It is actually painful >to watch it grab 10K off the hdd and then write 10K to tape and rewind to >update the tape header. > On my system the magic incantation to get it to stream really >well is: >tar -cvb 512 -f /dev/rwt0 [filesystem_to_backup] > > The optimum blocking value may vary under system loading and >from system to system. I would suggest that you start with "-b 64" >and work your way up by powers of 2 until it streams well for you. > >I hope this saves some people the agony of a six hour backup of >/usr/X386 that I endured before I figured this out. :) > Another way is to pipe the tar (or cpio) output to the dd with bigger block size, e.g. tar cvf - [list_to_backup] | dd ibs=512 obs=128k of=/dev/rwt0 The above output_block_size set to 128k may be too large for some systems, but if works great under HP-UX and DAT drives. One can try 16k as more moderate size and test it increasing the size until the drive streams. Of course on the way back one reads such a tape as follows: dd if=/dev/rwt0 bs=128k | tar tvf -