pa1081@sdcc13.ucsd.edu (pa1081) (02/06/90)
I would like to do central administration on our SGI's by backing
them up and doing all tape operations through our alliant FX/80
which has a 1/2" tape drive. When I called sgi customer support,
they informed me that this would not be possible (due to byte swaps
and such).
The question is, does anyone know of a way or public domain routines
that allow tape operations over the network between SGI Personal
IRIS's and 4.3bsd systems like the Alliant? Please let me know....
Steve Diggs
{uunet, ucsd}!photon!stevelamy@cs.utoronto.ca (Jean-Francois Lamy) (02/06/90)
pa1081@sdcc13.ucsd.edu (pa1081) writes: >The question is, does anyone know of a way or public domain routines >that allow tape operations over the network between SGI Personal >IRIS's and 4.3bsd systems like the Alliant? Please let me know.... Tar and friends should be easy, since you can always resort to tar cf - blah | rsh remote -n 'dd of=/dev/ninetracktape obs=126b' where the options to dd allow you to byteswap to your heart's content and reblock to a reasonable size. Strike one for customer support. With respect to rdump, the problem is that SGI's file systems are not BSD, so you need a version of dump that understands EFS. It is easiest to use a different output format than the normal 4.3BSD, and have a restore program that reads that format (the program be compiled on non-SGI machines to restore SGI partitions elsewhere). The person who wrote it here mumbled something about being able to generate straight 4.3BSD format at some cost in programming and overhead, but his current dump and restore are good enough for our purposes (a couple dozen diskful machines from n manufacturers dumped over the net to a pair of exabytes -- heck, even Apple supports rdump :-) We can't give away what we have here because of the terms of our source license, but one would hope that eventually SGI will come to its senses and support what is a common practice in organizations where it is unfeasible to have "everyone expected to manage their own diskful workstation". The official party line appears to be "bru to a private tape drive". If that's not what you want, by all means tell SGI. At least we're not alone :-) My sinuses are congested and my head is going to explode, Jean-Francois Lamy lamy@cs.utoronto.ca, uunet!cs.utoronto.ca!lamy Department of Computer Science, University of Toronto, Canada M5S 1A4
wood@acf4.NYU.EDU (David Wood) (02/07/90)
The other option which has been mentioned here before is to get a hold of gnutar. We use it here and were able to recover from a pretty much fully wiped out disk. You can pick up the compressed tar with anonymous ftp from cmcl2.nyu.edu (128.122.128.2) in pub/iris/sgigtar.tar.Z. I forget, the binary may already be included. If it is, it was compiled on a 4D/80GT under 3.1B. We haven't had to recompile under 3.2 though. Good luck. ------------------------------------------------------------------------- David Wood wood@acf2.nyu.edu New York University ...!uunet!cmcl2!wood 212-998-3029 "Brain. Brain. What is brain?" Kara the Eymorg, "Spock's Brain", Stardate 5432.3 -------------------------------------------------------------------------
sgf@cs.brown.edu (Sam Fulcomer) (02/08/90)
In article <7032@sdcc6.ucsd.edu> pa1081@sdcc13.ucsd.edu (pa1081) writes: >I would like to do central administration on our SGI's by backing >them up and doing all tape operations through our alliant FX/80 >which has a 1/2" tape drive. When I called sgi customer support, >they informed me that this would not be possible (due to byte swaps >and such). Huh? Why? What do they think byteorder(3N) does? Accessing a remote bsd-tape from an SGI is a lot more straightforward than reading random foreign tapes on local drives. eg, tar cf - /unix | rsh sun dd of=/dev/rst0 rsh sun tf /dev/rst0 rsh sun dd if=/dev/rst0 | tar tf - tar cf - /unix | rsh sun tar tf - all work thanks to byteorder(3N). What's the problem?