phil@cxbne.cx.oz (Phil Chadwick) (02/05/90)
In article <1529@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: > > To John: I've found that that the dump program will sense the end of the > tape and ask you to switch properly, but will not correctly estimate the > amount of tape it's going to use, if the parameters are off. Question: do > you find on large filesystems that the number of tapes that dump estimates > that it will use it accurate? > > I've found that 570/25000 will produce estimates that are slightly too low. > E.g., dump estimates that it will use .98 tapes, and actually uses slightly > more than 1 tape (it *does* sense end of tape and request the next). Dump works by figuring out how many blocks it can fit on a tape - i.e. given tape length, density and block size, dump calculates how many blocks it can write on the tape, then proceeds to count the blocks as it writes them. When the count is exhausted, the tape is switched. If there is insufficient tape to write the calculated number of blocks, dump reports a "write error" and asks if you want to restart the tape (and will do so indefinitely, as long as the tape supplied is "too short"). If dump initially estimates that it requires 0.98 tapes and actually uses one and a bit, then dump has simply underestimated the number of blocks required to be written to tape. This is quite common, and I seem to recall that the BSD manual for dump(8) mentions the likelyhood of an underestimate. Phil Chadwick. Comperex, Brisbane. ACSnet: phil@cxbne.cx.oz ARPA: phil%cxbne.cx.oz@uunet.uu.net UUCP: ..!uunet!murtoa!cxbne!phil
gopher@extro.ucc.su.oz.au (John McQueen) (02/06/90)
In article <1529@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >|>>In article <1644@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >|>>>(2) Can someone tell me the right length/density parameters for using >|>>>QIC-120 tapes with dump? > >|>In article <35223@mips.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >|>>We use (real size * ~95%) for size, so ~570 feet, and 16000 for density. > >| In article <1990Jan31.011355.14288@metro.ucc.su.oz.au> gopher@extro.ucc.su.oz.au (John McQueen) writes: >|>I just checked our script - we use length=600 and denisity=30000. >|>Our dumps work fine - why the big difference in density?? > >From article <35264@mips.mips.COM>, by rogerk@mips.COM (Roger B.A. Klorese): >| Well, we may well be underusing our tapes. Let me do some testing... > >To John: I've found that that the dump program will sense the end of the >tape and ask you to switch properly, but will not correctly estimate the >amount of tape it's going to use, if the parameters are off. Question: do >you find on large filesystems that the number of tapes that dump estimates >that it will use it accurate? We have operators that do our dumps, so I'm not sure. I just set ours up so that it works. > >I've found that 570/25000 will produce estimates that are slightly too low. >E.g., dump estimates that it will use .98 tapes, and actually uses slightly >more than 1 tape (it *does* sense end of tape and request the next). > I noticed on 6250 tape that dump gave me an estimate of .9? tapes and went over 1.? in the end. Another thing is the estimated time to completion seems to go up every time you change a tape. >So I would say that 600/30000 is too high, 570/25000 is a bit too high, >570/16000 is too low. Let's hear from others. Good tests are file systems >big enough to end up using just a bit more than one tape. Ok the question is how much data can you fit on a QIC-120 tape? I was informed that the amount of data is about 150MB. So a quick calculation reveals that at 600 ft the density is about 21000. At 570 ft the density is about 23000. So your figures seem right to me. Another question for people, is what are the correct s and d values for exabyte's? (we just got one last Friday). (Not that it matters too much you can fit about 4 filesystems to a tape anyway!!) John McQueen From: gopher@extro.ucc.su.oz.au (John McQueen) Newsgroups: comp.sys.mips Subject: Re: QIC-120 tapes with dump (was Re: /proc and other questions) Summary: Expires: References: <35264@mips.mips.COM> <1529@uakari.primate.wisc.edu> Sender: Reply-To: gopher@extro.ucc.su.oz.au (John McQueen) Followup-To: Distribution: Organization: University Computing Service, Uni. of Sydney, Australia. Keywords: In article <1529@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >|>>In article <1644@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >|>>>(2) Can someone tell me the right length/density parameters for using >|>>>QIC-120 tapes with dump? > >|>In article <35223@mips.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >|>>We use (real size * ~95%) for size, so ~570 feet, and 16000 for density. > >| In article <1990Jan31.011355.14288@metro.ucc.su.oz.au> gopher@extro.ucc.su.oz.au (John McQueen) writes: >|>I just checked our script - we use length=600 and denisity=30000. >|>Our dumps work fine - why the big difference in density?? > >From article <35264@mips.mips.COM>, by rogerk@mips.COM (Roger B.A. Klorese): >| Well, we may well be underusing our tapes. Let me do some testing... > >To John: I've found that that the dump program will sense the end of the >tape and ask you to switch properly, but will not correctly estimate the >amount of tape it's going to use, if the parameters are off. Question: do >you find on large filesystems that the number of tapes that dump estimates >that it will use it accurate? We have operators that do our dumps, so I'm not sure. I just set ours up so that it works. > >I've found that 570/25000 will produce estimates that are slightly too low. >E.g., dump estimates that it will use .98 tapes, and actually uses slightly >more than 1 tape (it *does* sense end of tape and request the next). > I noticed on 6250 tape that dump gave me an estimate of .9? tapes and went over 1.? in the end. Another thing is the estimated time to completion seems to go up every time you change a tape. >So I would say that 600/30000 is too high, 570/25000 is a bit too high, >570/16000 is too low. Let's hear from others. Good tests are file systems >big enough to end up using just a bit more than one tape. Ok the question is how much data can you fit on a QIC-120 tape? I was informed that the amount of data is about 150MB. So a quick calculation reveals that at 600 ft the density is about 21000. At 570 ft the density is about 23000. So your figures seem right to me. Another question for people, is what are the correct s and d values for exabyte's? (we just got one last Friday). (Not that it matters too much you can fit about 4 filesystems to a tape anyway!!) John McQueen -- ________________________________________________________________________ John Scott McQueen | gopher@extro.ucc.su.oz.au University Computing Service, H08 | Phone: +61 2 6923495 University of Sydney, NSW 2006, Australia | FAX: +61 2 6606557
bin@primate.wisc.edu (Brain in Neutral) (02/07/90)
From article <1990Feb5.235525.18017@metro.ucc.su.oz.au>, by gopher@extro.ucc.su.oz.au (John McQueen): > I noticed on 6250 tape that dump gave me an estimate of .9? tapes and > went over 1.? in the end. Another thing is the estimated time to > completion seems to go up every time you change a tape. I have noticed the latter phenomenon, too. Perhaps it's figuring the wait time while the tape is being changed into the "velocity" at which the dump is proceeding, and gets a "too-slow" estimate... Paul DuBois Internet: dubois@primate.wisc.edu UUCP: rhesus!dubois FAX: 608/263-4031
roe@sobeco.com (r.peterson) (02/08/90)
From article <1990Jan31.171701.18960@smsc.sony.com>, by dce@smsc.sony.com (David Elliott): > > On this same subject, has anyone calculated Exabyte sizes? I usually > just give some huge numbers that figure to more than 1GB, and ignore > what dump tells me. > We're running exabytes on our M-120. It took a bit of fudging the device driver, and a rom upgrade from exabyte, but we can actually get 2.0GB (average) on an exabyte cart. They are supposed to be good for 2.3GB, but error correction and file marks eat some tape. You will probably be much better off _not_ using dump. Single file restores can take up to 3 hours from a tape this way - much better to use something like bru, and use multiple savesets. BTW - to mips: nice job with the PALS and the exabyte rom change - more pull than we have here at Sobeco. We get about 230KBS after modifying the driver for buffered mode. -- One makes strong assumptions delving Roe Peterson into the beginning of the universe... roe@sobeco.com - Stephen Hawking, Cambridge uunet!sobeco!roe