sharp@usceast.UUCP (Harry Sharp) (07/02/90)
Greetings!
We here at University of South Carolina have purchased an Exabyte
tape drive for doing network backups. Unfortunately, we purchased
it for a workstation that we were *supposed* to get, but the Dean
has seen things differently. We need desparately to verify the machine
works, but our only SCSI box with the correct type of port is one
of our Personal Irises. We have the cable and the little darling
powers up correctly, but it doesn't seem to want to play with the
SGI. We have been told that SGI has not "qualified" the Exabyte for the
Personal Iris. Anybody know why?? Anybody from SGI wish to defend this
position??
Harry Sharp
Assistant to the Director for Research Computing
sharp@usceast.cs.scarolina.edu
--
[=============================================================================]
USMail : Dept of Mathematics, USC, Columbia, SC 29208
E-mail : gatech!hubcap!usceast!sharp sharp@usceast.cs.scarolina.edu
GO COCKS! You can't lick our cocks! University of South Carolinaolson@anchor.esd.sgi.com (Dave Olson) (07/02/90)
sharp@usceast.UUCP (Harry Sharp) writes: | We here at University of South Carolina have purchased an Exabyte | tape drive for doing network backups. Unfortunately, we purchased | it for a workstation that we were *supposed* to get, but the Dean | has seen things differently. We need desparately to verify the machine | works, but our only SCSI box with the correct type of port is one | of our Personal Irises. We have the cable and the little darling | powers up correctly, but it doesn't seem to want to play with the | SGI. We have been told that SGI has not "qualified" the Exabyte for the | Personal Iris. Anybody know why?? Anybody from SGI wish to defend this | position?? We haven't qualified it due to the tradeoff between resources and perceived demand. The PI has somewhat more extensive SCSI diagnostics at powerup than the other 4D machines, and the Exabyte consistently fails them. The failure is caused by Exabyte not supporting some of the commands used; in itself this is OK, but the way they reject them is non-standard. In any case, this is non-fatal. Simply continue after the failed diagnostics message. Also be sure that all the terminator resistors are removed if you are using it internally, and are installed if using it externally. Once the system is up, you will need to run 'cd /dev; ./MAKEDEV tape' After that, your /dev/*tape* entries will have links appropriate for the Exabyte. You need IRIX 3.1G or later. If you have 3.2, there may be problems putting multiple archives on the same tape if you use bru or tar (it will sometimes rewind when it shouldn't, overwriting your earlier archives). This problem is fixed in 3.3 -- Dave Olson Life would be so much easier if we could just look at the source code.
merritt@iris613.gsfc.nasa.gov (John H Merritt) (07/02/90)
In article <9815@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: [Discussion of 8mm on PI] > >If you have 3.2, there may be problems putting multiple archives on the >same tape if you use bru or tar (it will sometimes rewind when it >shouldn't, overwriting your earlier archives). This problem is fixed >in 3.3 I'm running 3.2 and my solution is: tar cBf - file | dd of=/dev/nr8mm bs=10240 I let dd handle writing and reading of the device and I position with 'mt' commands. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #
olson@anchor.esd.sgi.com (Dave Olson) (07/03/90)
merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: | In article <9815@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: | | [Discussion of 8mm on PI] | | > | >If you have 3.2, there may be problems putting multiple archives on the | >same tape if you use bru or tar (it will sometimes rewind when it | >shouldn't, overwriting your earlier archives). This problem is fixed | >in 3.3 | I'm running 3.2 and my solution is: | | tar cBf - file | dd of=/dev/nr8mm bs=10240 | | I let dd handle writing and reading of the device and I position with | 'mt' commands. Yes, this will work around the problem, as the problem occurs in an ioctl that tar uses, and it can't use it if it's output isn't a tape. I would recommend for performance reasons using bs=128k, instead of 10k. This GENERALLY reduces the amount of repositioning required on the Exabyte, and therefore improves throughput. Your system, may of course do better with other values... You may also want to consider using a larger block size than the default (10k) with tar, for the same reason. I am a bit hazy on the fix to the problem, but I seem to recall that if you just specify a block size to tar, that the multiple archives per tape problem will not be seen (i.e., the problem occurred when trying to determine the blocksize to use). -- Dave Olson Life would be so much easier if we could just look at the source code.