nielsen@saturn.ecs.umass.edu (01/03/89)
> We have a Sun 3/260 running SunOS 4.0. The tapes that I buy for the Sun > say on them "600'", which I assume means 600 feet. However, when I use > dump, and specify a size longer than 600', it does not fail until > somewhere near 1000' (at least that is what it reports). It is tough to comment on this without seeing the entire command you used. Later in this posting is some general info on 'dump', some of this info is condensed from Sun Spots postings on Jun. 30 1988 and Aug 18 1988. We shared a similar experience with tape lengths being strange. It was *due* to our using the a density of 10,000 (YES TEN-THOUSAND), the standard blocking factor, and NOT using the 'c' (for cartidge) option. Through trial and error we found that 1100 feet was a safe value. We used the 10,000 bpi density as was given on the tape. The man on dump given on the tape. The man on dump is written primarily for reel tapes, and since they write on 9 tracks serially (as opposed to the cartridge's 9 tracks sequentially), we were confused between bits per inch and bytes per inch. {A reel tape writes a byte at a time serially} Our backups AND restores were always successful... until our tape drive died. Before we determined the drive was broken, we started investigating our dump parameters more carefully and became aware that our parameters were unusual. -> A question is: Why does density effect the tape length? It *shouldn't*, but it does. -> Another question is: Is it safe to backup using the {unusual} command: % /etc/dump "$level"usdf 1100 10000 /dev/rst8 "$filesystem" IT HAS ADVANTAGES if it is safe. It had worked reliably for over a year, takes LESS THAN HALF the time, and stores about 60 Megs of data per tape. I asked SUN about this, but they never got back to me. Most of the following info is condensed/excerpted from Sun Spots postings on Jun. 30 1988 [Dan Franklin] and Aug 18 1988 [John Gilmore]: A suggested dump command is: /etc/dump "$level"ucsbf 4800 126 /dev/rst8 "$filesystem" The "c" indicates the use of a tape cartiridge u is to update the '/etc/dumpdates' file 4800 is the tape length used for 600' tapes 126 is the blocking factor with the c the density defaults to 1000 Lowering the blocking factor decreases the amount of data stored on each tape {bad} and the time required for a dump {good}. The cartridge tape drives write 9 tracks sequentially, that is why the 4800' tape length is used (9 X tape-length X 0.95 {safety factor}). [excerpted: <There are two variants of the bit format that controllers record on the <tape. One is called QIC-11, the other is QIC-24. QIC-11 is the original <Archive format (Archive Corp. started the whole 1/4" streaming cartridge <business). When a standards committee got a hold of it, they changed it <(of course) to QIC-24. In both cases, the tape contains 512-byte blocks <of data with small headers on them. For QIC-11, the block number in the <header is 8 bits; for QIC-24, the number is 24 bits. That is essentially <the only difference between the two. It was changed because in the <controller could lose track of where it was on the tape. Both formats <hold the same amount of data on a given tape. < < .... you have to specify in software [...] whether you want QIC-11 or <QIC-24 formatting. /dev/rst0 is QIC-11 and /dev/rst8 is QIC-24. ....] Eric Nielsen Mechanical Engineering Dept. University of Massachusetts at Amherst
david@wubios.wustl.edu (David J. Camp) (01/05/89)
Spots, A while ago I inquired on sun-spots about the real vs. apparent length of a tape. What I had noticed is that the length written on the tape's label (600') was less that expected by dump. I got several good answers, and this is a summary. The length of tape expected by dump is the real length of the tape times the number of tracks minus some factor for inter-record gaps. If you use /dev/rst8 you get 9 tracks, but if you use /dev/rst0 you get only 4 tracks. -David- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University Medical School Saint Louis, MO 63110
david@wubios.wustl.edu (David J. Camp) (01/13/89)
Spots, This looks pretty authoritative, so I thought you would be interested. When I switched from /dev/rst0 to /dev/rst8 I did an experiment as suggested in my original inquiry, and the tape length has not changed. If anything it is a little shorter, around 900 feet for /dev/rst8 compared to 1000 feet for /dev/rst0. I have not figured out if I am actually getting more data on the tape though. -David- Bitnet: david@wubios.wustl Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david 660 South Euclid Washington University Medical School Saint Louis, MO 63110 __________ swagman@Sun.COM (Patrick J. McEvoy (Sun Entry Systems ISV Liason)): > The length of tape expected by dump is the real length of the > tape times the number of tracks minus some factor for > inter-record gaps. If you use /dev/rst8 you get 9 tracks, but > if you use /dev/rst0 you get only 4 tracks. No. rst8 & rst0 spcify QUIC24 or QUIC11 format. There is some density difference, but mostly it is just that QUIC24 is more robust. The 9 or 4 trackness is completely dependent upon your tape drive. The 9-track drives first use the same 4 tracks as the 4-track drives, then they interleave 5 more tracks. So uo to 20 Mbytes, the tapes can be used on either kind of drive. The confusion about tape lengths is that dump expects info in terms of 1/2 tapes that have 9 vertical bits -- so a 1600 bits-per-inch tape (linearly) actually gives you 1600 *bytes* per inch. Dump then figures out how much stuff to put on the tape. If it succeeds, it goes on to the next tape even if there is room left. If it hits an EOT (end of tape) it blows up. Cartridge tapes are 450 or 600 feet times 4 or 9 tracks long. But then you have to divide by 9 (byte with parity) because the tracks are only 1 bit wide. If you have a 450, just use the "c" option on dump. If you have a 600, you have to play with the numbers. But remember dump thinks you are telling it about a single-pass, 9-bit-wide tape.
poage@ucbvax.berkeley.edu (Tom Poage) (01/14/89)
david@wubios.wustl.edu (David J. Camp) writes: >If you use /dev/rst8 you get 9 tracks, but if you use /dev/rst0 you >get only 4 tracks. If this is true, how have I been getting ~58 MB on a tape using /dev/rst0? Me thinks they both have 9-track capability. -- Tom Poage, UCDMC Clinical Engineering, Sacto., CA ucdavis.ucdavis.edu!sunny!{poage,root,postmaster,news} ucbvax!ucdavis!sunny!{poage,root,postmaster,news}
mangler@csvax.caltech.edu (Don Speck) (02/01/89)
Half-inch magtape has a usable length about 40 to 60 feet shorter than the
stated length, due to the leader and trailer. Minimum interrecord gaps
are 0.3 inches for 6250 Bpi, and 0.6 inches for 800, 1600, or 3200 Bpi.
Streamers with a 1600-Bpi 25-ips start/stop mode need 0.8 inches. In all
other cases, streamers have to reposition if the next block is not
supplied soon enough, and since this is so slow, some streamers stretch
out the minimum interrecord gap by 50% (CDC 92181 or 92185) or even 100%
(DEC TU80) in hopes of avoiding this, which is how a Sun-3/160 or VAX-750
respectively is able to stream them at all. When they reposition, the
interrecord gap is maximum length. Cache streamers write minimum
interrecord gaps, at the price of making the return value of write()
essentially meaningless.
Quarter-inch cartridges appear to have no leader or trailer, a minimum
interrecord gap of about 0.2 inches, a maximum interrecord gap of 1.6
inches, and when they reposition they leave a minimum interrecord gap,
which is probably why this action takes about 1.6 seconds.
Early Sun quarter-inch cartridge streamers had no cache. A Sun-3/160
isn't fast enough to stream one unless the blocksize is 2 KB or less,
which results in interrecord gaps averaging about 1.1 inches. In typical
use, they reposition after every block, with minimum interrecord gaps.
Later drives have a small cache, and will stream if the blocksize is not
too big for the cache. I'm not sure what this cutoff is, but it seems to
be somewhere between 10K and 63K (I've had little access to such drives).
These drives seem to always write minimum interrecord gaps, so there is no
real capacity gain from using huge blocksizes.
Interrecord gap is the one tape parameter that can't be specified to dump.
The values used by various versions are:
'c' option dens=6250 dens=other
4.1 BSD - 0.7 0.7
* 4.2, 4.3, 4.3T estimates 1.548 0.3 0.7
4.2 BSD actual 0.7 0.7 0.7
4.3 beta actual 1.6 0.4 0.8
4.3, 4.3T BSD actual 1.6 0.5 0.8
SunOS 1.1 to 3.5 1.6 0.6 1.2
(* yes, the tape usage estimate uses a separate value of interrecord
gap, which Berkeley hasn't changed to match the rest of BSD dump).
In principle, the above information should be enough to calculate the
"right" parameters to dump. Dump will compute how many tenths of an inch
per block written, truncating to an integer (a problem for high densities)
and use that to add up the length written.
If dump's hardcoded interrecord gap is wrong (usually), you can lie to
dump about the tape length, but this lie will differ depending on the
blocksize. The only way to make one length work for all blocksizes is to
lie about the density, too, dividing it by the ratio of actual interrecord
gap to dump's value (and multiplying the length by the same factor). For
example, extracting some figures from George Goble's excellent article on
Exabytes:
actual scaling fiction for dump
interrecord gap 0.015 inch * 80 = 1.2 inch
density 550700 Bpi / 80 = 6884 Bpi
length 348 feet * 80 = 27840 feet
Using this fiction, SunOS 3.5 dump will calculate a capacity of 1812 MB
for blocksize=32K, and 2004 MB for blocksize=63K. (N.B. I do not have an
Exabyte to try this on, nor a 2000 MB filesystem).