Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ads.com!sparkyfs!zwicky From: zwicky@sparkyfs.istc.sri.com (Elizabeth Zwicky) Newsgroups: comp.unix.admin Subject: Re: Dumping to an exabyte tape drive Keywords: Exabyte dump args Message-ID: <32608@sparkyfs.istc.sri.com> Date: 4 Sep 90 21:38:56 GMT References: <1990Aug29.143657.20588@siesoft.co.uk> <1990Sep1.143812@suned1.nswses.navy.mil> <877@iiasa.UUCP> Reply-To: zwicky@pterodactyl.itstd.sri.com.UUCP (Elizabeth Zwicky) Organization: SRI International, Menlo Park, CA 94025 Lines: 49 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