krowitz@mit-kermit.UUCP (David Krowitz) (06/10/87)
Hmmm ... let's see ... first of all, you need to rewind and retension the
cartridge tape on the Apollo before writing on it. You can do this with
'/com/wbak -dev ct -reten'. Then use the command 'tar cvbf 1 /dev/rct8' to
write the tape. /dev/rct8 is the correct device to use on the Apollos, the
'b 1' is required on the Apollos when writing to a cartridge tape in order
to get the blocksize correct. The cartridge tape has a fixed blocksize (or
so I am told) and the default blocksize of 20 will cause your data to be
lost. This is required even if you are reading the tape back onto another
Apollo. Once the tape is written, you should be able to read it back on
a Sun or an Apollo (or any other machine which uses the QUIC-24 format) with
the command 'tar xvf /dev/whatever_your_machine_refers_to_the_drive_as'
-- David Krowitz
mit-erl!mit-kermit!krowitz@eddie.mit.edu
mit-erl!mit-kermit!krowitz@mit-eddie.arpa
krowitz@mit-mc.arpa
(in order of decreasing preference)bc@wbcs.UUCP (Barry Caplin) (03/04/89)
Hi,
We've got an iris and are trying to get files back and
forth with the apollos. I've tried to write a cassette
using tar... tar cbf 1 /dev/rct8 <pathname>
and read.. tar xf /dev/rct8 <pathname>. For some reason
this is not working. I've also tried using /dev/rct12 and no dev
(to the mag tape drive). In each case I get the error message
tar: cannot open /dev/rct8 (or /dev/whatever).
Is it me or is it tar? The nodes are running 9.6 here (not that
I think it would matter). We're thinking of maybe running an sio
line from the iris to the apollo and using kermit but we'll only
have the iris for a few more days.
Any ideas?
Barry
Please e-mail and I will summarize.
Thanks.
--
"The bus came by and I got on that's when it all began..."
Barry Caplin or @: Boeing Computer Service
UUCP: ..{uunet}!ncrwic!wbcs!bc PO Box 7730 - M/S K79-51
CompuServe: (72707,1120) Wichita, KS 67277 316-526-9564lnz@LUCID.COM (Leonard N. Zubkoff) (03/07/89)
Have you tried doing rbak -dev ct -rewind prior to the tar? That command is often needed to initialize the tape library (TFP). Leonard
wesommer@ATHENA.MIT.EDU (Bill Sommerfeld) (03/07/89)
Have you tried doing rbak -dev ct -rewind prior to the tar? That command is often needed to initialize the tape library (TFP). For those of you who prefer to do it without resorting to Aegis-isms, "mt -f /dev/rct8 rew" also works. - Bill
pfuetzner@zgdvda.UUCP (Matthias Pfuetzner) (05/05/89)
I've got a question concerning TAR under SR9.2 and SR9.7: 1.) Why is the device for the cartridge tape /dev/rmt/c0d0h and not /dev/rctX or /dev/rstX or /dev/rmtX as on SUNs or other UNIX machines? 2.) Is there any possibility to TAR to tape WITHOUT doing a rbak -dev ct -rewind before each tar f /dev/rmt/c0d0h ? (Without the rbak command I always get the message: tar: cannot open /dev/rmt/c0d0h !!) 3.) Is there any possibility to SPEEDUP cartridge tape actions? Writing about 8 Mbyte to cartridge tape on a standard Sun 3/60 takes about 8 minutes (/dev/rst8), reading them bak with tar on an APOLLO (DN 3000, DN 580) takes about 90 minutes (no jobs on the machine, no jobs on the network!!) So if anybody can give me any hints I'd be very very glad!! Thanks in advance, Matthias Pfuetzner pfuetzner@zgdvda.uucp ...mcvax!unido!zgdvda!pfuetzner
weber_w@apollo.COM (Walt Weber) (05/08/89)
In article <503@zgdvda.UUCP> pfuetzner@zgdvda.UUCP (Matthias Pfuetzner) writes: >I've got a question concerning TAR under SR9.2 and SR9.7: >1.) Why is the device for the cartridge tape > /dev/rmt/c0d0h >and not > /dev/rctX ..... Both are present, assuming that the installation of Domain/IX was done by our installation tools. It sounds like you are accessing the SysV device special file and not the BSD. You should be able to use /com/edmtdesc to look at c0d0h and create a duplicate as /dev/rct8 or /dev/rct12. But I'm suspicious about how the BSD device entries got deleted, and wonder what else might be missing from your system. >2.) Is there any possibility to TAR to tape WITHOUT doing a > rbak -dev ct -rewind >before each > tar f /dev/rmt/c0d0h ? >(Without the rbak command I always get the message: >tar: cannot open /dev/rmt/c0d0h !!) Last time I looked (more than 8 months ago) the -rewind was only necessary when a ctape is inserted in the drive; are you changing tapes? >3.) Is there any possibility to SPEEDUP cartridge tape actions? >Writing about 8 Mbyte to cartridge tape on a standard Sun 3/60 takes >about 8 minutes (/dev/rst8), reading them bak with tar on an APOLLO >(DN 3000, DN 580) takes about 90 minutes (no jobs on the machine, no >jobs on the network!!) Conventional wisdom (a.k.a. "folklore") is that writing to disk will always take longer than reading, since new files need to have space "found" for them, rather than chasing pointers to existing blocks as in the read operation. An increase of slightly over 11x "feels wrong", and since we (as users) always want it faster, less expensive, and available now, can you tell me how long it takes to WRITE that same 8Mb to disk (under a new pathname) on your 3/60? And how long does it take us to write those files from the DN3000 to ctape? ( No sense fixing one tire if we've got two flats :-) > Matthias Pfuetzner ...walt... -- Walt Weber Apollo Computer (508) 256-6600 x8315 People's Republic of Massachusetts -The views expressed herein are personal, and not binding on Apollo-
dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (05/09/89)
In article <431a057f.10b48@apollo.COM> weber_w%apollo.uucp@eddie.mit.edu (Walt Weber) writes: >In article <503@zgdvda.UUCP> pfuetzner@zgdvda.UUCP (Matthias Pfuetzner) writes: >>I've got a question concerning TAR under SR9.2 and SR9.7: > >>3.) Is there any possibility to SPEEDUP cartridge tape actions? >>Writing about 8 Mbyte to cartridge tape on a standard Sun 3/60 takes >>about 8 minutes (/dev/rst8), reading them bak with tar on an APOLLO >>(DN 3000, DN 580) takes about 90 minutes (no jobs on the machine, no >>jobs on the network!!) > >Conventional wisdom (a.k.a. "folklore") is that writing to disk will always >take longer than reading, since new files need to have space "found" for >them, rather than chasing pointers to existing blocks as in the read operation. >An increase of slightly over 11x "feels wrong", and since we (as users) always >want it faster, less expensive, and available now, can you tell me how long >it takes to WRITE that same 8Mb to disk (under a new pathname) on your 3/60? >And how long does it take us to write those files from the DN3000 to ctape? >( No sense fixing one tire if we've got two flats :-) Pre-sr10 streams I/O to/from cartridge tapes is one big flat tire! ;-) Utilities like /com/wbak, /com/rbak, & /systest/ssr_util/cptape do not use streams I/O to get to ctape, they use an unreleased interface, the "ct_$" calls. Their performance is OK, about 1 Megabyte/minute. Utilities like /com/rwmt & tar use the streams I/O system, and their performance is hurting, about 0.1 Megabytes/minute. For example: # DN300 node, 4 Mbytes memory, 150 Mbyte disk # # # AEGIS8-DOMAIN/IX kernel, revision 9.7.0.4 , Tuesday, May 31, 1988 4:51:23 pm. # $ ld -a file # # sys type blocks current # type uid used length attr rights name # # file obj 4791 4884620 P pgndwrx file # # $ rwmt -w -dev ct -f 1 -unlab -raw -rf f -rl 512 -bf 1 file # # Run time to transfer from disk to tape with streams I/O: 25.2 minutes. # # $ cptape -dev ct -read tape.cpy # # Run time to transfer from tape to disk with "ct_$" I/O: 3.8 minutes At sr10.1 there is a big improvement in streams I/O speed for ctapes. It's now almost as fast as the "ct_$" system. Taking the same node that was used in the previous case, running it under sr10.1, and transfering the same file, we get the following results: # Domain/OS kernel(8), revision 10.1.0.2, January 4, 1989 10:48:48 am # # $ rwmt -w -dev ct -f 1 -unlab -raw -rf f -rl 512 -bf 1 file # # Run time to transfer from disk to tape with streams I/O: 5.5 minutes. # # $ cptape -dev ct -read tape.cpy.2 # # Run time to transfer from tape to disk with "ct_$" I/O: 3.6 minutes So the bottom line is, if you want to use tar with cartridge tapes use sr10 or be prepared to do a lot of waiting. Dave Funk
achille@cernvax.UUCP (achille) (05/10/89)
In article <8905090651.AA01180@icaen.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU (David B. Funk) writes: >Utilities like /com/wbak, /com/rbak, & /systest/ssr_util/cptape do not >use streams I/O to get to ctape, they use an unreleased interface, the "ct_$" >calls. Their performance is OK, about 1 Megabyte/minute. Utilities like >/com/rwmt & tar use the streams I/O system, and their performance is >hurting, about 0.1 Megabytes/minute. >.......... >Dave Funk Just a couple of info to put things in the right place: 1) wbak, rbak, rwmt ALL use tfp_$ calls to access the tape or cartridge or floppy. The only difference here is that w/rbak use tfp_$block_list_io (sp?) to perform IO in BIG chunks, rwmt uses record IO and so is pretty slow on ct as the max record length there is 512 bytes (as opposed to magtape where I think is 16K and rwmt performs decently on them). 2) cptape uses ct_$. As a side note, performance via C I/O on exabytes (under sr9.7) is not that bad when compared to w/rbak. When I am at exabyte, I posted some time ago a request for help about write errors on our (Workstation Solution) exabyte. As it comes out, the power supply they use in the older units (the new ones they ship have a different one) has problems on 220V. The ripple on the +12V gets up to 1.5V (max. should be 150mV). Hope this helps, Achille Petrilli Cray & PWS operations
gah@cml.unl.edu (Glen A. Hansen) (04/02/91)
While on the subject of "tar", is it possible to "tar" more than one archive to
a cartridge tape? It seems a waste to use a 40 meg tape for a 20 meg archive. It would
be nice to put another archive at the tail end of the first (similar to rbak/wbak).
I have tried all permutations of the available "tar" options with no success. Am
I missing something here, or is what I am trying to do not possible?
On a similar note, any opinions of "cpio"? I believe you can use the "pax" command
for this, but haven't tried.
Thanks in advance,
gah@cml.unl.eduthompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/02/91)
> While on the subject of "tar", is it possible to "tar" more than one archive to > a cartridge tape? It seems a waste to use a 40 meg tape for a 20 meg archive. It would > be nice to put another archive at the tail end of the first (similar to rbak/wbak). > I have tried all permutations of the available "tar" options with no success. Am > I missing something here, or is what I am trying to do not possible? DISCLAIMER: I haven't tried this, so I can't vouch for it. You should be able to use the non-rewinding tape devices (generally, 12 or 13 instead of 8 or 9 (e.g. rct12, rmt12, rmts13). Perform your first tar to this device, and then just perform the second (and third and ...) If you've already put tape-file-1 out, and want to append to that tape, you probably need to use the /bin/mt (may not work with 8mm devices) command. Read the man page for info on it. I don't know about full O/S support yet, but Apollo provided a new_mt command with Omniback to support the new devices. I expect that that will be or has been incorporated in the O/S. -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!
rees@pisa.citi.umich.edu (Jim Rees) (04/03/91)
In article <9104020018.AA18211@cml.unl.edu>, gah@cml.unl.edu (Glen A. Hansen) writes:
While on the subject of "tar", is it possible to "tar" more than one archive to
a cartridge tape?
Not only is tar badly broken, but tape io is also broken (and always has
been). You can make this work but it's a pain. You have to rewind and
re-read each archive before writing the next. The sequence is something
like this:
mt -f /dev/rct8 rew
tar cfv /dev/rct12 file1 file2 file3 ...
mt -f /dev/rct8 rew
dd if=/dev/rct12 of=/dev/null bs=1k
tar cfv /dev/rct12 file4 file5 file6 ...
mt -f /dev/rct8 rew
dd if=/dev/rct12 of=/dev/null bs=1k
dd if=/dev/rct12 of=/dev/null bs=1k
tar cfv /dev/rct12 file7 file8 file9 ...
...
This takes forever. In fact, it's intractable, since the time required is
exponential with the number of archives. That means it doesn't matter how
fast the tape drive is, it still takes too long.thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/03/91)
> Not only is tar badly broken, but tape io is also broken (and always has > been). You can make this work but it's a pain. You have to rewind and > re-read each archive before writing the next. The sequence is something > like this: > > mt -f /dev/rct8 rew > tar cfv /dev/rct12 file1 file2 file3 ... > mt -f /dev/rct8 rew > dd if=/dev/rct12 of=/dev/null bs=1k > tar cfv /dev/rct12 file4 file5 file6 ... > mt -f /dev/rct8 rew > dd if=/dev/rct12 of=/dev/null bs=1k > dd if=/dev/rct12 of=/dev/null bs=1k > tar cfv /dev/rct12 file7 file8 file9 ... > ... No it isn't! (Small disclaimer -- I tested this at 10.3 -- you're on your own for 10.2 or 10.1) You only need to rewind the tape the first time (this, in essense, 'mounts' the tape device). After that, until you remove the tape, the device is there, and can be accessed. Therefore, all you need is mt -f /dev/rct8 rew tar cfv /dev/rct12 file1 file2 file3 ... tar cfv /dev/rct12 file4 file5 file6 ... tar cfv /dev/rct12 file7 file8 file9 ... ... I had no problem with this. I was able to run all the tars, rewind it, and go indexing (tar tvf /dev/rct12) and skipping around (mt -f /dev/rct12 fsf 2) with no problems. > This takes forever. In fact, it's intractable, since the time required is > exponential with the number of archives. That means it doesn't matter how > fast the tape drive is, it still takes too long. I know it's long in the case that you listed, but it isn't exponential. It's merely polynomial (n**2). The way you had did 0+1+2+3+4+...+(n-1) rewinds to put out 'n' tars. That's ( n**2 - n ) / 2, which is definitely O(n**2), not O(e**n). Sorry, but I just had to comment.... :-) -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!
rees@pisa.citi.umich.edu (Jim Rees) (04/03/91)
In article <9104030014.AA12617@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: > Not only is tar badly broken, but tape io is also broken... No it isn't! (Small disclaimer -- I tested this at 10.3 -- you're on your own for 10.2 or 10.1) You're right, it seems to have been fixed. It was broken at sr10. I know it's long in the case that you listed, but it isn't exponential. It's merely polynomial (n**2)... Right again. And only a second order one at that. Send me back to school.
shwake@raysnec.UUCP (Ray Shwake) (04/03/91)
In article <9104020018.AA18211@cml.unl.edu>, gah@cml.unl.edu (Glen A. Hansen) writes:
While on the subject of "tar", is it possible to "tar" more than one archive to
a cartridge tape?
Well, can't speak about the Apollo environment, but several years
ago I wrote a tar stacking routine to accomplish just that for the Zilog. It
took advantage of the "no-rewind" option associated with the tape devices.
It also includes "read" and "extract" options. If you want to play with this
shell script (comes with man page), let me know.
[Pardon the posting. Couldn't adress to the original poster.]
-----------
uunet!media!ka3ovk!raysnec!shwake shwake@rsxtechtvb@bugeater.UUCP (Terry V. Bush) (04/04/91)
mt -f /dev/rct12 rew
tar cvf /dev/rct12 file1 file2 file3 ...
tar cvf /dev/rct12 file4 file5 file6 ...
tar cvf /dev/rct12 file7 file8 file9 ...
To extract:
mt -f /dev/rct12 rew
tar xvf /dev/rct12
tar xvf /dev/rct12
tar xvf /dev/rct12
You don't need to do any of this "dd" stuff!
Note: Unlike many other platforms, the Apollo does not need a "fsf 1" step
between the "tar xvf"'s. Why they didn't use /dev/nrct8 is beyond me!
You can use the /etc/edmtdesc command to look at the two files.
Here is what I say on them:
% edmtdesc /dev/rct12 -l
Volume information:
dev (device type) ct
u (tape unit #) 0
lab (labeled) no
reo (reopen previously used volume) yes
clv (close volume on file-close) yes
spos (save position on volume-close) yes
File information:
f (file sequence #) current
rf (record format) F (fixed length)
bl (block length) 512
rl (record length) 512
ascnl (ascii newline handling) no
% edmtdesc /dev/rct8 -l
Volume information:
dev (device type) ct
u (tape unit #) 0
lab (labeled) no
reo (reopen previously used volume) yes
clv (close volume on file-close) yes
spos (save position on volume-close) no
File information:
f (file sequence #) current
rf (record format) F (fixed length)
bl (block length) 512
rl (record length) 512
ascnl (ascii newline handling) no
In article <50bc51ca.1bc5b@pisa.citi.umich.edu>, rees@pisa.citi.umich.edu (Jim Rees) writes:
> Path: frame!vsi1!ames!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.citi.umich.edu!rees
> From: rees@pisa.citi.umich.edu (Jim Rees)
> Newsgroups: comp.sys.apollo
> Subject: Re: Tar
> Message-ID: <50bc51ca.1bc5b@pisa.citi.umich.edu>
> Date: 2 Apr 91 17:22:42 GMT
> References: <9104020018.AA18211@cml.unl.edu>
> Sender: usenet@terminator.cc.umich.edu (usenet news)
> Reply-To: rees@citi.umich.edu (Jim Rees)
> Organization: University of Michigan IFS Project
> Lines: 27
>
> In article <9104020018.AA18211@cml.unl.edu>, gah@cml.unl.edu (Glen A. Hansen) writes:
>
> While on the subject of "tar", is it possible to "tar" more than one archive to
> a cartridge tape?
>
> Not only is tar badly broken, but tape io is also broken (and always has
> been). You can make this work but it's a pain. You have to rewind and
> re-read each archive before writing the next. The sequence is something
> like this:
>
> mt -f /dev/rct8 rew
> tar cfv /dev/rct12 file1 file2 file3 ...
>
> mt -f /dev/rct8 rew
> dd if=/dev/rct12 of=/dev/null bs=1k
> tar cfv /dev/rct12 file4 file5 file6 ...
>
> mt -f /dev/rct8 rew
> dd if=/dev/rct12 of=/dev/null bs=1k
> dd if=/dev/rct12 of=/dev/null bs=1k
> tar cfv /dev/rct12 file7 file8 file9 ...
>
> ...
>
> This takes forever. In fact, it's intractable, since the time required is
> exponential with the number of archives. That means it doesn't matter how
> fast the tape drive is, it still takes too long.
Peace,
Terry V. Bush
The Veritable Bugeater tvb@frame.com N6IFX