fpb@schlitz.ittc.wec.com (Frank P. Bresz) (09/01/90)
In article <1990Aug29.143657.20588@siesoft.co.uk> duncan@siesoft.co.uk (Duncan McEwan) writes: >I'm not sure that this is the most appropriate group for this query, but I >guess it will reach most of the people who will be able to answer it. >I have just started using an exabyte tape drive to do dumps of our file >systems. Could someone please tell me the appropriate values to give >to dump (tape length, density, inter-record gap (is this relevent for this >encoding format?)) to allow dump to fully utilise each tape. >For now I am kludging it using a bogus tape length of ~200000 feet (estimated >by knowing that dump will write approx 64MB onto a 5400 ft streamer cartridge), >but I would like to know the correct values. In particular, how much *can* >you fit on a single 90 minute tape, and how long are the tapes? >I will summari[zs]e to this group any replies by email that aren't also posted >here. >Duncan On A Sun I use : dump 0ufsd /dev/nrst2 6000 54000 /dev/id000a However I just got done dumping eleven partitions onto a single tape with the following results: DUMP: estimated 8526 blocks (4.16MB) on 0.00 tape(s). DUMP: estimated 19870 blocks (9.70MB) on 0.01 tape(s). DUMP: estimated 59778 blocks (29.19MB) on 0.02 tape(s). DUMP: estimated 143480 blocks (70.06MB) on 0.06 tape(s). DUMP: estimated 179618 blocks (87.70MB) on 0.07 tape(s). DUMP: estimated 259772 blocks (126.84MB) on 0.10 tape(s). DUMP: estimated 395520 blocks (193.12MB) on 0.16 tape(s). DUMP: estimated 546268 blocks (266.73MB) on 0.21 tape(s). DUMP: estimated 748986 blocks (365.72MB) on 0.29 tape(s). DUMP: estimated 806824 blocks (393.96MB) on 0.32 tape(s). DUMP: estimated 895238 blocks (437.13MB) on 0.35 tape(s). I checked the tape to see if it appeared valid and it did so I am stuck. The MB totals total out to less than what is supposed to fit on a tape 2.3GB so I figured it was OK. I would like to know also what settings are appropriate. -- Frank P. Bresz | Westinghouse Electric Corporation \ / fpb@ittc.wec.com | ITTC Simulators Department \/\/ uunet!ittc!fpb | Those who can, do. Those who can't, simulate. ---- (412)733-6749 | My opinions are my own, Westinghouse doesn't want them. Fax: (412)733-6444 | Besides I don't earn enough to render an official opinion.
jht@suned1.nswses.navy.mil (James H Tibbs) (09/02/90)
I used these arguments for an Exabyte on a Sun3 running 4.0.3 with the
standard
Sun drivers being used;
dump 0ubsdf 64 12000 43000 /dev/rst1 "file-system"
With these args about 1.9GB will fit on a tape before "write errors"
are encountered. This 1.9GB figure matches what dump "thinks" it can
fit
on a tape with the given args. According to the vendor who sold our
unit,
the blocking, size, and density parameters originated from Sun.
Is anyone else out there using an Exabyte with Sun drivers which can
recognize the end of the tape?
The above parameters have proved reliable as I have rebuilt a number
of
trashed disks/file systems ( :-( ) backed up on Exabytes.
--
Jim Tibbs, System Administrator; UNIX/VMS/Networking
Dept. of the Navy (NSWSES), Port Hueneme CA. 93043, Code 4A05
Work#: (805) 982-7185 (A/v 551), Home#:(805) 984-6529
jht@suned1.nswses.navy.mil jht@suned1.UUCP
Any statements / opinions made here are mine alone, not the Navy's.linegar@bcars85.bnr.ca (Derick Linegar) (09/02/90)
fpb@schlitz.ittc.wec.com (Frank P. Bresz) writes: >In article <1990Aug29.143657.20588@siesoft.co.uk> duncan@siesoft.co.uk (Duncan McEwan) writes: >>I'm not sure that this is the most appropriate group for this query, but I >>guess it will reach most of the people who will be able to answer it. > [....] >On A Sun I use : >dump 0ufsd /dev/nrst2 6000 54000 /dev/id000a >However I just got done dumping eleven partitions onto a single tape with >the following results: [....] This was discussed at some lenght in comp.sys.sun a while back, and to summarize, the options I use for dump to make maximum use of a exabyte tape drive is: /usr/etc/dump 0ucbsdf 56 5190 4100000 /dev/whatever file-system Now it doesn't use the all the 2.3 Gigabyte of space, but it is close enough for me not to worry about that. -derick- -- #include <disclaimer.h> Derick Linegar, Internet Systems 4P27, Bell-Northern Research BITNET: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: ...uunet!bnrgate!bcars85!linegar Ottawa ONT. K1Y 4H7
wnp@iiasa.AT (wolf paul) (09/04/90)
In article <1990Sep1.143812@suned1.nswses.navy.mil> jht@suned1.nswses.navy.mil (Jim Tibbs) writes: ) ) dump 0ubsdf 64 12000 43000 /dev/rst1 "file-system" ) And in article <linegar.652252313@bcars85> linegar@bcars85.bnr.ca (Derick Linegar) writes: ) ) /usr/etc/dump 0ucbsdf 56 5190 4100000 /dev/whatever file-system ) And in article <FPB.90Aug31172357@schlitz.ittc.wec.com> fpb@schlitz.ittc.wec.com (Frank P. Bresz) writes: ) )dump 0ufsd /dev/nrst2 6000 54000 /dev/id000a ) These figures seem quite inconsisten. Which is correct? Would someone at SUN care to comment, ideally the person who wrote their drivers? A Standard Tape has a density of 6250 bpi and a length of 2300 feet Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet Derick Linegar specifies 4100000 bpi and a length of 5190 feet Frank Bresz specifies density of 54000 bpi and a length of 6000 feet -- Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe PHONE: +43-2236-71521-465 FAX: +43-2236-71313 UUCP: uunet!iiasa.at!wnp INTERNET: wnp%iiasa.at@uunet.uu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET * * * * Kurt Waldheim for President (of Mars, of course!) * * * *
zeke@shamash.cdc.com (Robert Scott) (09/05/90)
In article <877@iiasa.UUCP>, wnp@iiasa.AT (wolf paul) writes: > In article <1990Sep1.143812@suned1.nswses.navy.mil> jht@suned1.nswses.navy.mil (Jim Tibbs) writes: > > Stuff deleted. > > These figures seem quite inconsisten. Which is correct? > Would someone at SUN care to comment, ideally the person who wrote > their drivers? > > A Standard Tape has a density of 6250 bpi and a length of 2300 feet > > Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet > > Derick Linegar specifies 4100000 bpi and a length of 5190 feet > > Frank Bresz specifies density of 54000 bpi and a length of 6000 feet > > -- These numbers are really only used by the DUMP program to determine length of tape for volume and "time to finish" estimates. The actual device driver will correctly write to the device regardless of what you specify in DUMP, but the dump parameters affect how much of the tape you actually use. We are using a Delta Microsystems driver here on Sun OS 4.01. I quote from the Delta Microsystems SS-2000T User's Guide (attributed, but not used by permission): Using dump with a 2000T drive is essentially the same as using dump with any other tape device, except that you get a lot more information on each tape. Because of the difference in bit density between the 2000T and a normal 9-track drive, and because dump uses the 9-track drive as its reference in calculating the tape length, the tape length you provide for the 2000T must be the effective tape length (as if it were a 1600 bpi 9-track tape capable of storing the same number of megabytes as the 2000T tape). Formula for computing the tape length parameter: size = (((512*blocking factor)+1920)/blocking factor) * ((total Kbytes on tape - 2048)/10667) The blocking factor is how many 512 byte buffers (the standard buffer size for dump) should be used in 1 tape record (which by default is 1024 bytes for Delta). So BF is 2,4,6... (default of 2). Optimum for Delta is BF=124, or 62 Kbytes/block. Total kbytes per tape is straight from a table as follows (for Sony P6 tapes, for domestic U.S.): 15 minute tape: 258 Meg 30 minute tape: 516 Meg 60 minute tape: 1032 Meg etc.... Example for a full dump command to a Sony P6-120 tape using optimal block size: dump 0fbs /dev/device_name 124 103400 partition_name Hope this helps. Zeke -- ~~~~~~~~~~~ From the Shrine of the "Last Gasp of ETA Systems" ~~~~~~~~~~~~~ Extra zesty disclaimer: MINE! MINE! ALL MINE! <chortle snort froth drool> Robert K. "Zeke" Scott internet: zeke@eta.cdc.com Control Data Corp, Supercomputer Support Group
zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) (09/05/90)
In article <877@iiasa.UUCP> wnp@iiasa.UUCP (wolf paul) writes: >These figures seem quite inconsisten. Which is correct? >Would someone at SUN care to comment, ideally the person who wrote >their drivers? >Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet >Derick Linegar specifies 4100000 bpi and a length of 5190 feet >Frank Bresz specifies density of 54000 bpi and a length of 6000 feet OK, so I don't work for Sun and I didn't write their drivers, but since this actually has nothing to do with Sun's generic SCSI driver, that's probably just as well. Basically, dump takes these numbers, multiplies the number of feet by 120 to get tenths of inches, munges that some to compensate for interrecord gaps, and multiplies the result by the bytes-per-tenth of inch to get the number of bytes that will fit on the tape. This works fine for cartridge tapes, and 1600 bpi half-inch. Beyond that, life gets bad, for several reasons. 1) Dump does not ever actually check for EOT; it believes that tapes are the length it calculates, and attempts to write that much. If that's more than will fit, you will get a write error. 2) Dump's concept of how to munge the number of feet in the tape to compensate for interrecord gaps is pitifully inaccurate. By the time you get to 6250 bpi tape, you are already putting enough on the tape that the accumulated error mounts up. Thus, people with 6250 bpi tape drives frequently end up having to claim that 2500 foot tapes are really only 2300 feet long in order to keep dump from writing off the end. On an exabyte, the error is even more significant. 3) Dump doesn't allocate enough space internally to cope with the genuine density of an exabyte; nobody thought tapes would get that dense at the time. So part of the trouble here is that telling dump the truth won't work, several times over; dump can't cope with the truth, and even if it could, its idea of an interrecord gap is wildly off and so it would get wrong how many could fit. So why do people use different lies? Different blocking factors; different device drivers; different versions of dump (OSU's fast dump redoes the interrecord gap calculations and bumps the shorts to ints and the ints to longs, bypassing problems 2) and 3)); different guesses, for that matter. As long as your largest filesystem is smaller than an exabyte, and also small enough that dump thinks it will fit, it really doesn't matter. If it won't fit, play with the parameters... Elizabeth Zwicky
fpb@ittc.ittc.wec.com (Frank P. Bresz) (09/05/90)
In article <32608@sparkyfs.istc.sri.com> zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) writes: >In article <877@iiasa.UUCP> wnp@iiasa.UUCP (wolf paul) writes: >>These figures seem quite inconsisten. Which is correct? >>Would someone at SUN care to comment, ideally the person who wrote >>their drivers? >>Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet >>Derick Linegar specifies 4100000 bpi and a length of 5190 feet >>Frank Bresz specifies density of 54000 bpi and a length of 6000 feet >OK, so I don't work for Sun and I didn't write their drivers, but >since this actually has nothing to do with Sun's generic SCSI driver, >that's probably just as well. >Basically, dump takes these numbers, multiplies the number of feet by >120 to get tenths of inches, munges that some to compensate for >interrecord gaps, and multiplies the result by the bytes-per-tenth of >inch to get the number of bytes that will fit on the tape. This works >fine for cartridge tapes, and 1600 bpi half-inch. Beyond that, life >gets bad, for several reasons. [...] Stuff deleted >So part of the trouble here is that telling dump the truth won't work, >several times over; dump can't cope with the truth, and even if it >could, its idea of an interrecord gap is wildly off and so it would >get wrong how many could fit. So why do people use different lies? >Different blocking factors; different device drivers; different >versions of dump (OSU's fast dump redoes the interrecord gap >calculations and bumps the shorts to ints and the ints to longs, >bypassing problems 2) and 3)); different guesses, for that matter. As >long as your largest filesystem is smaller than an exabyte, and also >small enough that dump thinks it will fit, it really doesn't matter. >If it won't fit, play with the parameters... > Elizabeth Zwicky I was stating what I used because I found it didn't give me great results. These numbers were listed in my ARTECON manual I received with the tape drive and also in the SunOS4.1 man pages (See end of post, I hope a verbatim quote from the manual doesn't get me in trouble). I have since switched to Derick's set of numbers but the following results ensued. DUMP: estimated 8802 blocks (4.30MB) on 0.00 tape(s). DUMP: estimated 22876 blocks (11.17MB) on 0.01 tape(s). DUMP: estimated 59102 blocks (28.86MB) on 0.02 tape(s). DUMP: estimated 143484 blocks (70.06MB) on 0.04 tape(s). DUMP: estimated 179616 blocks (87.70MB) on 0.05 tape(s). DUMP: estimated 213900 blocks (104.44MB) on 0.06 tape(s). DUMP: estimated 395718 blocks (193.22MB) on 0.12 tape(s). DUMP: estimated 545608 blocks (266.41MB) on 0.17 tape(s). DUMP: estimated 730660 blocks (356.77MB) on 0.22 tape(s). DUMP: estimated 806998 blocks (394.04MB) on 0.24 tape(s). DUMP: estimated 894876 blocks (436.95MB) on 0.27 tape(s). Hand computed totals DUMP: estimated 4001640 blocks (1953.92MB) on 1.20 tape(s). So while it is closer there is still a posibility of dump stopping before the tape is truly full. As you can tell from this listing I am getting close. I guess I can just bump up the feet a touch more to see what happens. As per Elizabeth I shall just keep lying until dump finally hears the lie it wants to hear. P.S. This tape also has a complete index at the head and tail end of the tape, so there is even a touch more data there. SunOS4.1 Man Page on 'dump' says: d bpi Tape density. The density of the tape, expressed in BPI, is taken from bpi. This is used to keep a running tab on the amount of tape used per reel. Default den- sities are: 1/2" tape 1600 BPI 1/4" cartridge 1000 BPI 2.3-Gbyte 8mm tape 54,000 BPI s size Specify the size of the volume being dumped to. When the specified size is reached, dump waits for you to change the volume. dump interprets the specified size as the length in feet for tapes, and cartridges and as the number of 1024 byte blocks for diskettes. The fol- lowing are defaults: 1/2" tape 2300 feet 60-Mbyte 1/4" cartridge 425 feet 150-Mbyte 1/4" cartridge 700 feet 2.3-Gbyte 8mm 6000 feet diskette 1422 blocks -- Frank P. Bresz | Westinghouse Electric Corporation \ / fpb@ittc.wec.com | ITTC Simulators Department \/\/ uunet!ittc!fpb | Those who can, do. Those who can't, simulate. ---- (412)733-6749 | My opinions are my own, Westinghouse doesn't want them. Fax: (412)733-6444 | Besides I don't earn enough to render an official opinion.
wnp@iiasa.AT (wolf paul) (09/05/90)
In article <25394@shamash.cdc.com> zeke@shamash.cdc.com (Robert Scott) writes: > > Example for a full dump command to a Sony P6-120 tape using ^^^^^^ Could someone explain these tape designations? Over here, I cannot find P6 tapes, only P5. We are using TDK P5-90 tapes, the genuine Exabyte "EXATAPE" cartridge which was packaged with our SUN-supplied drive does not have any "P" designation, but is labelled, "112m". I understand that the capacity (at least on 8mm video machines) of these tapes is related to the AC power frequency, i.e. 60 Hz in North America, and 50 Hz in Europe; is this what the P6 and P5 designations stand for? Does this difference in capacity also apply to Exabyte-type data storage devices? What would be a convenient way under UNIX (SunOS) to actually determine the capacity of any such tape? -- Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe PHONE: +43-2236-71521-465 FAX: +43-2236-71313 UUCP: uunet!iiasa.at!wnp INTERNET: wnp%iiasa.at@uunet.uu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET * * * * Kurt Waldheim for President (of Mars, of course!) * * * *
ghg@ecn.purdue.edu (George Goble) (09/05/90)
>And in article <FPB.90Aug31172357@schlitz.ittc.wec.com> fpb@schlitz.ittc.wec.com (Frank P. Bresz) writes: > >) >)dump 0ufsd /dev/nrst2 6000 54000 /dev/id000a >) > >These figures seem quite inconsisten. Which is correct? >Would someone at SUN care to comment, ideally the person who wrote >their drivers? > >A Standard Tape has a density of 6250 bpi and a length of 2300 feet > >Jim Tibbs specifies a density of 43000 bpi and a length of 12000 feet > >Derick Linegar specifies 4100000 bpi and a length of 5190 feet > >Frank Bresz specifies density of 54000 bpi and a length of 6000 feet > I can probably take the blame for "6000 54000". We did lots of the early Exabyte work on Suns (and turned our drivers over to Sun back in the 3.4/3.5 days). For both Gould's and Suns the older dump/restore used "b 1" to mean 1024 bytes, not 512 as it does today. Back then, we used "dump 0fbsd /dev/nrst0 50 54000 6000 /filesys" and if filesys was 220 MB, it would give an estimate of "0.1 tapes". Now we changed the 50 to 100 on the suns but have not checked the accuracy for awhile.. this was 2-3 years ago. In reality, the Exabyte (8200) is 550000 BPI and 347 feet long, but those numbers cause overflow in dump. The EXB-8500 is 2X the "density" of the 8200 and will make these problems more severe. Jim Kahn is the person who works on the "st" driver for non Sparc Suns at Sun. --ghg
ghg@ecn.purdue.edu (George Goble) (09/05/90)
In article <882@iiasa.UUCP> wnp@iiasa.UUCP (wolf paul) writes: >In article <25394@shamash.cdc.com> zeke@shamash.cdc.com (Robert Scott) writes: >> >> Example for a full dump command to a Sony P6-120 tape using > ^^^^^^ > >Could someone explain these tape designations? Over here, I cannot >find P6 tapes, only P5. We are using TDK P5-90 tapes, the genuine >Exabyte "EXATAPE" cartridge which was packaged with our SUN-supplied >drive does not have any "P" designation, but is labelled, "112m". > [stuff deleted] > >What would be a convenient way under UNIX (SunOS) to actually >determine the capacity of any such tape? "P5-90" tapes are the 112m tapes, the longest you can get. They are slightly longer than the American P6-120. A P5-90 (Sony) holds approx 2.45 to 2.5 GB on the EXB-8200. A P6-120 holds 2.32 GB. This assumes your driver can write past LEOT to PEOT (physical EOT). On the EXB-8500, this difference will be much more pronounced, 4.6GB to 5.0GB. We had bad luck with TDK 3 years ago during initial Exabyte testing (25% rewrite rate), but maybe they are better now. Sony & Fuji came out best. Do you know of anyplace to get Sony P5-90's in the USA? or can somebody in AU export them to USA (qty = several thousand) at a reasonable price? I just picked up our last tape order (qty 1000, $5.47 each) from a local audio store (Good Vibes), Sony P6-120MP's. --ghg
sfy@dmp.csiro.au (Shane Youl) (09/06/90)
We are running Solbourne's here, and their current release of OS/MP based on
Sun OS 4.0.3 has a /etc/media file which can be used by dump to determine
tape characteristics. Here are the relevant entries for Exabytes.
#
# TAPE/DUMP MEDIA DATA BASE:
#
# name density passes length irg error ntrec xrate
#
# units bytes/"/ times '->ft inner % 1K Kb/sec
# pass over "->inch record of blocks/
# tape or tape record
# to stream
# EOT gap
# 1/10"
#---- EXABYTE MEDIA (P6)
X_256 466033 1 48' 0 4 63 500
X_512 466033 1 91' 0 3 63 500
X_1024 466033 1 176' 0 3 63 500
X_1536 466033 1 261' 0 3 63 500
X_2048 466033 1 346' 0 3 63 500
P6-15 466033 1 48' 0 4 63 500
P6-30 466033 1 91' 0 3 63 500
P6-60 466033 1 176' 0 3 63 500
P6-90 466033 1 261' 0 3 63 500
P6-120 466033 1 346' 0 3 63 500
#---- EXABYTE MEDIA (P5)
P5-15 466033 1 69' 0 3 63 500
P5-30 466033 1 128' 0 6 63 500
P5-60 466033 1 246' 0 3 63 500
P5-90 466033 1 366' 0 3 63 500
Hope this is of some help.
--
____ _____ ____ ____
Shane Youl / \ / / / \ / \
CSIRO Division of Mineral Products / /_____ / /_____/ / /
PO Box 124 Port Melbourne 3207 / / / / \ / /
AUSTRALIA \____/ _____/ / / \ \____/
Internet : sfy@dmp.CSIRO.AU
Phone : +61-3-647-0211 SCIENCE ADVANCING AUSTRALIAp576spz@mpirbn.mpifr-bonn.mpg.de (S.Petra Zeidler) (09/07/90)
In article <882@iiasa.UUCP> wnp@iiasa.UUCP (wolf paul) writes: >What would be a convenient way under UNIX (SunOS) to actually >determine the capacity of any such tape? dd if=/dev/zero of=/dev/rstwhatever ibs=256k obs=8k (or multiples of 8k) as an EXAbyte writes 8*1k simultaneously; furthermore it speeds up later writing if the tape has been written over once :) (the EXA does faulty-spots-marking; with us (Europe) 2.1 GByte will always fit, 2.3 GByte many times) greetings, spz --- spz@specklec.mpifr-bonn.mpg.de or spz@mpirbn.uucp or universe!local-cluster!milky-way!orionis-arm!sol!earth!uunet!unido!mpirbn!spz = S.Petra Zeidler | ... in the midst of your laughter and glee, Auf dem Huegel 69 | you will softly and suddenly vanish away, 5300 Bonn 1, FRG | and never be met with again.
dricejb@drilex.UUCP (Craig Jackson drilex1) (09/08/90)
In article <882@iiasa.UUCP> wnp@iiasa.UUCP (wolf paul) writes: >In article <25394@shamash.cdc.com> zeke@shamash.cdc.com (Robert Scott) writes: >> >> Example for a full dump command to a Sony P6-120 tape using > >Could someone explain these tape designations? Over here, I cannot >find P6 tapes, only P5. We are using TDK P5-90 tapes, the genuine >Exabyte "EXATAPE" cartridge which was packaged with our SUN-supplied >drive does not have any "P" designation, but is labelled, "112m". The tapes are labelled differently because the capacity of a given number of meters of tape depends on the video system being recorded. The U.S. and Japan use the NTSC color video system. Europe uses either the PAL or the SECAM color video system. (I think one is basically British in origin, and one French.) The PAL system, in particular, uses 625 lines/frame and 25 frames/second. NTSC uses 525 lines and 30 frames. However, there are even greater differences in the way color is recorded. (I'm told that PAL color is much better.) These differences seem to add up to the fact that you can get 120 minutes of NTSC video on less tape than is required to hold 90 minutes of PAL video. The tape manufacturers want to express the length in minutes, not feet or meters, therefore the tapes are labelled differently on different continents. I suspect that "P5" and "P6" mean something to a tape standards committee, but for our purposes they simply indicate which time/length calculation to use. >What would be a convenient way under UNIX (SunOS) to actually >determine the capacity of any such tape? Our Exabyte vendor (Delta Microsystems) included a table giving all of the capacities.... >Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe >INTERNET: wnp%iiasa.at@uunet.uu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
wnp@iiasa.AT (wolf paul) (09/08/90)
In article <15425@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >>What would be a convenient way under UNIX (SunOS) to actually >>determine the capacity of any such tape? > >Our Exabyte vendor (Delta Microsystems) included a table giving all of the >capacities.... Any chance that you could post that table or a close approximation thereof? Thanks! -- Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe PHONE: +43-2236-71521-465 FAX: +43-2236-71313 UUCP: uunet!iiasa.at!wnp INTERNET: wnp%iiasa.at@uunet.uu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET * * * * Kurt Waldheim for President (of Mars, of course!) * * * *
wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) (09/10/90)
[...] >>Basically, dump takes these numbers, multiplies the number of feet by >>120 to get tenths of inches, munges that some to compensate for >>interrecord gaps, and multiplies the result by the bytes-per-tenth of >>inch to get the number of bytes that will fit on the tape. This works >>fine for cartridge tapes, and 1600 bpi half-inch. Beyond that, life >>gets bad, for several reasons. [...] > So while it is closer there is still a posibility of dump stopping before > the tape is truly full. As you can tell from this listing I am getting > close. I guess I can just bump up the feet a touch more to see what > happens. As per Elizabeth [Zwicky] I shall just keep lying until dump > finally hears the lie it wants to hear. Trouble is, if you find the `lie dump wants to hear', it still can't work reliably, because the (equivalent of) inter-record gaps are variable length on the Exabyte. If partial track (1 track=8192 bytes) is written, and more data is not ready, the Exabyte will write the rest of the tape blank before waiting for more data. Thus, insofar as the timings for dumps of various files (due to fragmentation, numbers of files, file lengths, etc.) are unpredictable in detail, the size of the tape needed is also. I can't remember off the top of my head if the Exabyte writes more blank tracks when data is insufficient. Certainly it eventually, painfully slowly, stops, backs up and waits for more data before starting up. In any case, choosing a blocking that's a multiple of 8k will mitigate this loss, so I can't understand why a blocking factor of 126 (63k) is often recommended. A blocking factor of 56k=112 should be better. I think you'd better concede the last 10% or so, as long as dump can't deal with EOT. And even if it could, I once had a nasty surprise when restore broke because a multi-volume dump (9-track in this case) did't start at the beginning of the tape. Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa
braun@dri.com (Kral) (09/10/90)
In article <439@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: > >I think you'd better concede the last 10% or so, as long as dump can't deal >with EOT. And even if it could, I once had a nasty surprise when restore >broke because a multi-volume dump (9-track in this case) did't start at the >beginning of the tape. > So the $64k question now is: why can't dump properly deal with end of tape? It's not like it's a new technology or something. Another (I suppose this one is only an $8k question): I'm not sure what you mean about the multi volume set above? How did dumps behavior cause the multi volume dump to start not at BOT? -- kral * 408/647-6112 * ...!uunet!drivax!braun * braun@dri.com What a man desires to know is *that*. But his means of knowing is *this*. How can he know *that*? Only by the perfection of *this*. - Arthur Waley, "The Way and its Power"
hackwort@dg-rtp.dg.com (Brian Hackworth) (09/11/90)
In article <776PKVH@dri.com>, braun@dri.com (Kral) writes: |> In article <439@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: |> > |> >I think you'd better concede the last 10% or so, as long as dump can't deal |> >with EOT. And even if it could, I once had a nasty surprise when restore |> >broke because a multi-volume dump (9-track in this case) did't start at the |> >beginning of the tape. |> > |> |> So the $64k question now is: why can't dump properly deal with end of tape? |> It's not like it's a new technology or something. |> |> Another (I suppose this one is only an $8k question): I'm not sure what you |> mean about the multi volume set above? How did dumps behavior cause the multi |> volume dump to start not at BOT? |> This whole discussion points out two serious flaws in the BSD dump: 1. It doesn't handle end-of-tape. You're right, this isn't new technology. It is fairly hard to add to dump, though, due to the way the program is designed. 2. Adding new devices, especially high-capacity cartridge drives, is difficult because you must figure out how to trick dump into giving correct estimates. For DG's version of dump, we have rewritten BSD dump to address these issues (and others) by (a) recognizing and sanely handling EOT, and (b) providing a table of dump devices which lists a name for the device, the blocking factor, and the capacity (such as "150M" or "2.2G"). Together, this allows you to add one line to one file describing the advertised capacity of the tape. If, because of IRGs or bad media, the actual capacity of some of the tapes is less than the advertised capacity, it's not a catastrophe because dump handles the EOT correctly. So, to answer the questions: For $8K: some sites may choose to put more than one dump on a single 8mm tape. This makes a lot of sense for dailies and even weeklies. As a result, any given dump file may not start at the beginning of the tape. For $64K: some versions of dump do deal with end of tape. I think they all should. -- Brian Hackworth Data General Corporation hackworth@dg-rtp.dg.com 62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!hackworth Research Triangle Park, NC 27709 (919) 248-6143
klg@flash.UUCP (Kevin L. Gross) (09/12/90)
In article <776PKVH@dri.com> braun@dri.com (Kral) writes: >In article <439@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: >> >>I think you'd better concede the last 10% or so, as long as dump can't deal >>with EOT. And even if it could, I once had a nasty surprise when restore >>broke because a multi-volume dump (9-track in this case) did't start at the >>beginning of the tape. >> > >So the $64k question now is: why can't dump properly deal with end of tape? >It's not like it's a new technology or something. The way I heard it is that the EOF gap (filemark) used by dump is a physical length of tape. On a nine-track, that length of tape for the EOF (and, I suppose the EOT) is small relative to the amount of data one could place there, if one wasn't using it for a filemarker. That same physical length of tape on an 8mm tape takes up 10MB or more of possible data storage because of the extreme cramification (technical term meaning TIGHT! ;-) Although other data, specifically that from Eakins Assoc., makers of the SPERAD (Scsi to PERtec Adapter board) interface, say that the filemarkers are the equivilent of 2.2 MB, however, the dump program may be using a much larger file mark than the filemark SPERAD considers normal. (So sayeth Sequent anyway) Possibly that is what is fixed in Sequent's version of an 8mm compatible dump program called hdump, that costs an arm and a leg to purchase, which is why I'm still using dump. Hence, when you dump to 8mm tape the way I do, with about 17 filesystems, you only get about 1.8 GB per tape instead of the advertised 2.3 GB. I'm not exactly sure of the amount I lose per filemarker, but I do know if I try to put more than 1.8 GB on the tape, I get a hung tapedrive because it ran out of tape. (BTW, anyone know how I get it to request a second tape without running dump at the console? I run it via crontab script in the early AM.) Right now, I am backing up about 1.68 GB + 170 MB (filemarks) = 1.85 GB. (Uh, oh, I think I better archive some stuff. ;-) If I try to backup more data/filesystems, say 20, I probably need to subtract about 10MB per filesystem and another 10 MB for grins, from 2300 MB, leaving me with the number of MB I can safely backup, 2090 MB. Take this with a grain of salt, my figures are probably off. Actually, I have been using 1.8 GB as the max, which was suggested to me by various PWSK (People Who Should Know). BTW, I use: /etc/dump ${LEVEL}udbsf 6250 32 9200 /dev/rmt12 on my Sequent system for local and remote dumps where ${LEVEL} = 0-9. -- -Kevin L. Gross Systems Mgr. klg@Summation.WA.COM As long as the systems are up, my employers don't care what I think "Obviously, I am dealing with inferior mentalities." - Daffy Duck
prc@erbe.se (Robert Claeson) (09/12/90)
In a recent article braun@dri.com (Kral) writes: >So the $64k question now is: why can't dump properly deal with end of tape? >It's not like it's a new technology or something. "cpio" in System V Release 3 deals correctly with EOTs. "dump2" in DG/UX does it too. Standard "dump" don't (but DG/UX includes good 'ole "dump" as well for backwards compatibility). -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer (ask him).
ghg@ecn.purdue.edu (George Goble) (09/12/90)
In article <1088@flash.UUCP> klg@flash.UUCP (Kevin L. Gross) writes: > >Although other data, specifically that from Eakins Assoc., makers of >the SPERAD (Scsi to PERtec Adapter board) interface, say that the >filemarkers are the equivilent of 2.2 MB, however, the dump program may >be using a much larger file mark than the filemark SPERAD considers normal. >(So sayeth Sequent anyway) > >Hence, when you dump to 8mm tape the way I do, with about 17 filesystems, >you only get about 1.8 GB per tape instead of the advertised 2.3 GB. I'm >not exactly sure of the amount I lose per filemarker, but I do know if I >try to put more than 1.8 GB on the tape, I get a hung tapedrive because >it ran out of tape. > LONG EOF markers (default) are about 2.2MB. Exabyte has an LEOT warning before the PEOT (physical eot).. Older F/W has this about 235 or 240 MB from the end of tape. This coupled with "dribbling in" the data, so the drive wastes blocks starting/stopping, can easily result in only 1.5GB. The worst data rate is one that makes the drive "almost stop", it writes the pad blocks, but more comes in, so it keeps going, writes more pads, etc. Faster or slower aggregate rates (streaming or drive stopping) are much better.. worst start/stop loss is 100-200 MB on a whole tape. Newer (4$25 or later MX F/W), has LEOT only 30MB or so from PEOT, not 240 MB. A smart driver can write thru the LEOT. Each write returns a SCSI check (warning), but the write works. --ghg
dricejb@drilex.UUCP (Craig Jackson drilex1) (09/14/90)
In article <776PKVH@dri.com> braun@dri.com (Kral) writes: >In article <439@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: >>I think you'd better concede the last 10% or so, as long as dump can't deal >>with EOT. And even if it could, I once had a nasty surprise when restore >>broke because a multi-volume dump (9-track in this case) did't start at the >>beginning of the tape. > >So the $64k question now is: why can't dump properly deal with end of tape? >It's not like it's a new technology or something. The traditional reason why Unix programs do not deal properly with end-of-tape is because Unix tape drivers do not deal properly with end-of-tape. The problem is that end-of-tape is reported as an error indication on a write; frequently, the same block can later be read with no error indication. (This is an issue in the design of the driver; if tape interchange is an issue, it is an issue in the design of all relevant drivers.) I think that cartridge tapes may be different than nine-track drives in this regard. (There is a separate problem with Unix tape drivers and end-of-tape; ANSI labels require writing several records *after* the tape mark is seen, and the block over the mark is valid. However, this is not an issue for dump, which does not use ANSI labels.) (The above comment brought to you by the new-text vs included-text rules.) -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
dave@imax.com (Dave Martindale) (09/14/90)
In article <439@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt,OIR) writes: > >In any case, >choosing a blocking that's a multiple of 8k will mitigate this loss, so >I can't understand why a blocking factor of 126 (63k) is often recommended. >A blocking factor of 56k=112 should be better. Yes, a blocking factor of 8k should minimize part-track writes. But this only matters if, in fact, the host can't keep the tape supplied with data. The 8200 drive only writes 246 kb/sec, and the Berkeley-style multi-buffered "dump" can easily supply that when reading data from a decently fast disk when the system is otherwise not busy (typical of overnight dumps). If you're not worried about keeping up to the tape, then setting the blocksize to 126 gives you the largest writes that are still a multiple of 1k, which minimizes system overhead and time spent transferring stuff on the SCSI bus. The 8500 drive will change all this, since the transfer rate is twice as fast. But then, the track size is likely to be something other than 8K too.