ghg@ei.ecn.purdue.edu (George Goble) (12/21/88)
As far as reading back old tapes goes, I can still read back OK, tapes I made in July 1987. Anything before that, is not compatible with the current Exabyte format. Signal levels at the head preamp output (TP3, right most test point on top of R/W card) are comparable to recently made tapes (within 5-10%). We have seen only 4 or 5 "bad" tapes (out of 300-400 tapes), Sony P6-120MP, purchased from "consumer" wholesale houses. The bad tapes had a wrinkle in them and got hard write errors. One of them wrote ok, and failed on read back, the wrinkle being eaten away by the rotary heads. (another good reason to always read it back) I don't know of anybody who had only 5 bad magtapes out of 6600-8800 1/2 inch reels. In v7n46 I wrote: >Say, you have a tape with 3 tar files on it and want to save the first >file, and you want to begin writing over the 2nd file. > >Normally you would "mt fsf 1; tar cf /dev/nrst0 .." > >for an Exabyte: > >"mt fsf 1; mt bsf 1; mt weof 1; tar cf /dev/nrst0 .." > >will work. The regular filemark consists of an erased zone 3.8" long >(needed to begin a write). In this case, the first filemark is >rewritten in place, which creates an erased zone AFTER it, clearing the >way to write more on the tape. The erase head is not helical. [Above is true for Ciprico and our own (and some other) Sun 3.X drivers] Warning: The above sequences and in general positioning on a "stock" (st.c) SunOS 4.0 and 4.0.1 device driver will not work (Ciprico rfsd.c driver should work fine). st.c driver has no concept of "front" or "back" sides of a filemark. Only "safe" positioning operation for Exabyte (st.c) on SunOS 4.0/4.0.1 is "mt fsf X" FROM THE BOT. Anything else will probably abort or leave the tape positioned incorrectly (I saw a "mt bsf 1" rewind the tape when 10 files out!) It is also possible to write a "directory" on the front of a dump tape (also works with most magtapes), AFTER the dump is done. This way one can store the command file which made the dump, along with the actual log of the dumps on that tape. Sometimes one will have some filesystems abort (when dumped over a network) due to machines crashing and/or network problems. Most of the time, these can just be appended on the end of the tape. One initially writes a file of 10 Megabytes of zeros on the front of the tape, then writes the dumps on. One then rewinds, then uses a slightly modified tar command to write on the directory. The mod to tar is just to execute a "mtioctl REWIND" before exiting, so the device driver close routine does not write a filemark after the directory. If a filemark were written, the tape would have two filemarks with the same sequence number, which would confuse the Exabyte (will still work though). You have room to tar on about 2 MB of whatever you want in the directory area. To access the dump files, ones does a "mt fsf 1" to skip over the directory and the blank area. One cannot "read" past the directory, as an erased tape error (blank check) will occur. The huge capacity of Exabyte also lessens dump hassles in other ways. We do level 0 dumps on large Gould systems every two weeks, and level 9s everyday, no level 1-8s are needed, which makes restores a cinch. These are heavy use (lots of undergrads) machines, which have some filesystems with 50% of their files touched after 2 weeks. I put 4 Gould NP1s, 4 Gould PN9080s, and a CCI 6/32 on 5-1/2 Exabyte tapes, level 0. The above systems' level 9s all fit on 1/2 to 3/4 of one tape (dumped to a Sun 3/50 in my office) For Suns (staff and grad students only), and other research machines, we have noticed the level 0s can be run every 4-6 weeks, with 9s everyday. Restores are simple, just do the level 0, and the most recent level 9 tape. Exabyte level 9s are highly resistant to "blowouts", where some special research project or massive undergrad final projects, etc, will touch 200 Megabytes or more in one day on a single filesystem. A 200 meg blowout can wreak havoc with conventional backup schedules (requires more tapes, keeping track of them, etc) An Exabyte sails along, taking maybe 15 mins longer to dump the filesystem with the blowout, and it all still fits on one tape. I also have changes to the SunOS 4.0 SCSI tape driver (si.c, st.c) pretty much done to make the Exabyte usable again. Mostly fixes file positioning and not being able to read past EOF problems. It has been tested only on a 3/50 at this point. Will post the diffs someplace if there is any interest in it. George Goble, Engineering Computer Network, Purdue U, W. Lafayette IN 47907 (317) 494-3545 Arpa: ghg@purdue.edu uucp: {backbone}!pur-ee!ghg