ghg@ecn.purdue.edu (George Goble) (10/20/90)
New Exabyte drives will have the capability of hi speed positioning. There currently exists an "EXB-8200-SX" which is an EXB-8200 with an addtional chip to count servo tach pulses. Although, not optimum for Unix, there may be hope in making use of it for dump/restore. As currently implemented, one must first use a "showblock" scsi command, which returns a 10 byte quantity, to identify the current position on the tape. As documented, one is supposed to "leave a trail of crums" (do showblock's as the tape is written) and save these indicies in a "directory" someplace. When a "findblock" command is executed, and given the 10 byte position info, the drive will hi speed seek to that exact remembered spot in something like 90 seconds (on a 2.3GB tape). This does work, and it is amazing to see an Exabyte GOING FORWARD at 75X read speed! The bad news is, that the Unix world probably wants to be able to "mt fsf N" and "mt fsr N" to work at this speed and stop on filemarks and designated records, with no prior info. With 1 & 2 GB filesystems becomming common, one needs to be able to do high speed seeks on the tape, from INSIDE RESTORE (or tar/cpio? ugh!) I have done some experimenting with making up a "fake" showblock 10 byte position, and attemted to use it as a "rough" means of high speed positioning. The EXB-8200 series drives do not have the "file number" encoded in the internal data headers (I tried, but failed to convince Exabyte to include the file number before the first drives were built). One can run the drive out to some spot on the tape, and sync it back up, and read data where he landed. One cannot determine which file he is in, unless it is first encoded by the user in his data. (you can bet this will be fixed in the 8500) One would need a slight mod to dump, to take a command line arg (the file number where the dump will go on the tape), and just stuff that in an unchecksummed part of each file header dump writes out. For example: #machine 1 dump 0fubsdN /dev/nrst0 100 6000 54000 1 / dump 0fubsdN /dev/nrst0 100 6000 54000 2 /usr dump 0fubsdN /dev/nrst0 100 6000 54000 3 /a dump 0fubsdN /dev/nrst0 100 6000 54000 4 /b #machine 2 dump 0fubsdN /dev/nrst0 100 6000 54000 5 / dump 0fubsdN /dev/nrst0 100 6000 54000 6 /usr dump 0fubsdN /dev/nrst0 100 6000 54000 7 /a . . . The "N" arg would take the file seq number and stuff that into the file headers. restore would need more hacking to be able to issue "concocted" findblock commands, doing a binary search to home in on the desired file on a multi filesystem, (multi machine or even multi platform) dump tape. A restore for a single or a small group of files (not a "restore R"), would start at BOT, and issue all the high speed positioning ioctls. Another approach I have thought of, would be to have the kernel level driver execute showblocks, at fixed intervals, say 10MB, and at all filemarks of tape written. These 10 byte indicies would be stored in the kernel (10Kbytes or less), and be extracted by an ioctl when the tape was done, and possibly written into a "directory" on the front of the tape or kept online elsewhere. The advantage of this, is that it uses "as documented" SX high speed positioning, and the file number is known at any spot on the tape. Dump would not need to be modified to have the "N" flag as above. Hacks to restore would be pretty much the same, as one now has "tick marks" every 10 MB, and at EOFs to use in positioning. Disadvantages would be that the tape needs to be written on an -SX drive. Method one only requires an -SX drive for the restore operation, not the dump. Also, with method two, one has to drag around the extra baggage of the "directory", edit and maintain it. This just increases the complexity, and provides more oppertunities for something to break or be a source for bugs. The first method, requires the tape be bulk erased before use (Radio Shack "High power video eraser", cat. no. 44-233A works fine). Method #2 knows where the end of recorded media is by looking at the last dir entry for the trailing EOF. I know this is crude and device dependent, but it may be better than nothin'. What do you think? Ready for fire, I have a tank of Halon-1211 ready. --ghg Geo. Goble, Engr Comp Network, Purdue U. pur-ee!ghg ghg@purdue.edu
cheeks@edsr.eds.com (Mark Costlow) (10/26/90)
In article <1990Oct20.134852.2161@ecn.purdue.edu>, ghg@ecn.purdue.edu (George Goble) writes: |> |> New Exabyte drives will have the capability of hi speed positioning. |> There currently exists an "EXB-8200-SX" which is an EXB-8200 with an |> addtional chip to count servo tach pulses. |> Just ordered one. Sounds cool. |> Although, not optimum for Unix, there may be hope in making use of |> it for dump/restore. As currently implemented, one must first use |> a "showblock" scsi command, which returns a 10 byte quantity, to |> identify the current position on the tape. As documented, one is |> supposed to "leave a trail of crums" (do showblock's as the tape is |> written) and save these indicies in a "directory" someplace. |> Out of curiosity, what kind of performance hit does one take when doing "showblock"s all the time while writing? Does the drive continue to stream, or does it have to stop and reposition? |> |> Geo. Goble, Engr Comp Network, Purdue U. pur-ee!ghg ghg@purdue.edu Mark -- cheeks@edsr.eds.com or ...uunet!edsr!cheeks