Return to BSD News archive
#! rnews 3516 bsd Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.misc,comp.unix.solaris,comp.unix.bsd.bsdi.misc Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!news.kei.com!newsfeed.internetmci.com!uwm.edu!lll-winken.llnl.gov!ames!eos!kronos.arc.nasa.gov!logan From: logan@kronos.arc.nasa.gov (Logan Shaw) Subject: Re: ideal parameters for backup tape Message-ID: <1996Sep16.073636.10614@ptolemy-ethernet.arc.nasa.gov> Sender: usenet@ptolemy-ethernet.arc.nasa.gov (usenet@ptolemy.arc.nasa.gov) Nntp-Posting-Host: kronos-ethernet.arc.nasa.gov Organization: NASA/ARC Computational Sciences Division References: <323954B8.167EB0E7@innet.be> <51e1gk$cv2@agate.nbnet.nb.ca> <51ghpe$qh1@luva.lb.bawue.de> <51gugv$818@agate.nbnet.nb.ca> Date: Mon, 16 Sep 1996 07:36:36 GMT Lines: 51 Xref: euryale.cc.adfa.oz.au comp.unix.admin:47430 comp.unix.questions:87753 comp.unix.misc:25128 comp.unix.solaris:82734 comp.unix.bsd.bsdi.misc:4883 In article <51gugv$818@agate.nbnet.nb.ca>, Lance Cavener <cavenerl@nbnet.nb.ca> wrote: >On stardate 15 Sep 1996 11:20:46 +0200, migieger@luva.lb.bawue.de >(Michael Giegerich) sent holographic email and wrote: >>>>I need to backup my files using (ufs)dump. The problem is that I don't >>>>know which parameters are ideal. Can someone help me? I'm not 100% sure this is an issue with more DAT tape drives under certain OSes, but I do know that using plain old 8mm tapes under SunOS, setting a proper blocking factor is by far the MOST important parameter you can give to "dump". (Solaris seems to have special magic to attempt to stream data to the tape quickly, so it may not be an issue there, but in SunOS it's a real issue.) I have found that using the maximum blocking factor possible (126, or 63k, for 8mm Exabyte drives) as opposed to the default blocking factor (which on SunOS dump is something tiny like 4, or 2k) makes a HUGE difference in how fast the backup goes. Personally, I think the device driver ought to worry about this FOR you, but that's not the way it works on certain operating systems. For the record, I typically use the following: dump 0usf 9999999 /dev/nrst8 /the/file/system > Well, don't you have to tell dump the tape length in feet and its >density so dump can calculate the tapes meggage? If you find that number of tapes message valuable, then yes. I personally don't care, and in fact I'd rather not have that feature, since it's possible it will assume your tape is full when it's not. (What would be so terribly wrong about having it write() until write() fails and then having you change the tape?) > (Unix can be dumb >sometimes.. They should just have a command that you TELL dump the # >of megs :P) As if you can even know -- there are retries, and file marks, and tape length, and data transfer speed (some tape drives supposedly leave empty spaces so they will not have to stop the motor when the data temporarily stops), and compression, and "dump" command overhead, and so on, all of which are really pretty hard to predict accurately. As a result, I believe the capacity of a tape drive has about as much to do with how many megabytes you'll be able to put on it before it runs out as a watts per channel amplifier rating has to do with when you'll hear distortion. - Logan -- Logan Shaw, Unix Systems Administrator "everybody / loves to see / justice done / on somebody else" (Bruce Cockburn)