seth@megad.UUCP (Seth H Zirin) (10/02/85)
I regularly use the following command line to copy entire filesystems of
20 Meg and more (minus the /dev directory of course) from one disk to another
and it works just fine:
tar cf - SOME-LIST-OF-STUFF | (cd NEWDIR ; tar xvf - )
If I try to run it in the background (at least on a Uniplus+ SV machine)
with the command line below, it hangs infinitely (until I KILL(1) it a few
minutes later).
(tar cf - SOME-LIST-OF-STUFF | (cd NEWDIR ; tar xvf - )) &
Now I've added my two cents (or two command lines) to the discussion.
--
-------------------------------------------------------------------------------
Name: Seth H Zirin
UUCP: {decvax, ihnp4}!philabs!sbcs!megad!seth
Keeper of the News for megadearle@smeagol.UUCP (Greg Earle) (01/07/86)
I just had my first experience with 4.2BSD <-> System V tar (un)portability, which I would like to relate. I was developing an xmodem program on my Sun, for use on a Perkin-Elmer 3200 series computer, running XELOS (System V). I used tar cvbf 20 /dev/nrmt0 <file> on the Sun side (on a CDC 9 track), and then mt eof 2 to write end-of-tape. When I took it down to the Perkin-Elmer site, an attempt to tar tvbf 20 /dev/rmt/0m yielded back-and-forth motions on the tape drive (an older Cipher model), and a 'tar: read error' from tar. I took two different tapes down, with the same result. Nothing would make it read the tape. This site also has an AT&T 3b5, which uses the identical CDC 9-track as the Sun, so I tried to read it on that. In this case, 'tar tvbf 20 /dev/rmt/0m' at least was able to access the tape, but instead of the single file entry for the tar directory, it started replicating this file entry ad nauseum/infinitum. I had to kill the tar to stop it. I then did a 'tar xv' to extract, and was hopeful when it finished properly, and the output file size matched the tar directory entry size. Unfortunately, when I looked at the file, what really happened was that it took a chunk of one of the functions, and it replicated that over and over until it filled the proper file size. Note: I also got a 'tar: Blocksize = 2' on the extract, which I thought had something to do with a BSD filesize, but I thought tar was independant of things like that! To make things more interesting, I tried an 'od -c < /dev/rmt/0m' and got the header and the (real) beginning of the file, but od decided that the file ended after 2 blocks (2Kbytes). Anyone have any similar experiences, or know what is going on?? Greg Earle JPL sdcrdcf!smeagol!earle (UUCP) ia-sun2!smeagol!earle@cit-vax.arpa (ARPA)
bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (01/10/86)
>From: Greg Earle <earle%smeagol.uucp@BRL.ARPA> >I used > tar cvbf 20 /dev/nrmt0 <file> >on the Sun side (on a CDC 9 track), and then mt eof 2 to write end-of-tape. >When I took it down to the Perkin-Elmer site, an attempt to > tar tvbf 20 /dev/rmt/0m >yielded back-and-forth motions on the tape drive (an older Cipher model), >and a 'tar: read error' from tar. Some of those CDC drives can not handle the blocking factor of 20, they cannot read physical blocks >8K, use a smaller blocking factor when writing the tape, I went through this a few months back with my 3B5 also, yes it's brain-damaged, no, there's probably no other way around it. (And again, the caveat, I still claim I blew the breaker twice on my TU78 using a blocking factor of 1 so maybe for saftey's sake try something like 5.) -Barry Shein, Boston University
earle@smeagol.UUCP (Greg Earle) (01/11/86)
Thanks to everyone who responded to my question about tar(1) portability.
For those interested, the consensus was :
(1) The old Cipher drive on the Perkin Elmer is probably brain damaged,
and can't read my tape(s) due to different gap size, etc. In this case,
the only solution would be to write the 'tar' file onto the tape via dd,
and see if it can be "un-dd'ed" off of the Cipher.
(2) The tape controller on the AT&T 3b5 can't handle the default tar block
size of 20. Some people suggested 5, but I think (from the blocksize:2
problem) that the safest way is bs=1.
(3) System V 'tar' doesn't like the directory header info that BSD tar puts
on it. You must use the '-o' flag in BSD tar to suppress this.
My 'solution' (I had to get the file before I posted the question) was to
call up my system and use cu/tip to download it. Thank goodness for modems...
Thanks again.
Greg Earle
JPL
sdcrdcf!smeagol!earle (UUCP)
ia-sun2!smeagol!earle@cit-vax.arpa (ARPA)
-------------------------
Know Your Culture:
"Speed" and "The Dream is Alive" -
Two movies about (1) guess what ; and (2) footage shot from the Shuttle
(during Sally Ride's mission) of the Earth and various other sundry
locales. Shot in 135 mm film, and playing at a 5-story IMAX theater
near you. Watch as your stomach turns inside out when you see a fighter
do a barrel roll over a mountain top (in Speed); the shots in "Dream..."
are indescribably breathtaking (narration by Walter Cronkite ... and that's
the way it is). Beats the hell out of Return of Sun of Revenge of Rocky IV
(or whatever the nerds are raving about in net.movies :-)rct@occrsh.UUCP (01/11/86)
One of the major problems with respect to portability of tar tapes (in my experience) has been the tendency of well-meaning friends to use the blocking factor 20 without realizing that, for Sys V tar anyway, this results in a record length of 20 x 512 = 10k bytes. Unfortunately, the 3B20S computers I use have tape controllers (UN52) with a hardware limitation of 6k bytes max record length, and 3B5 tape controllers are scarcely any better with a limit of 8k bytes. This is particularly annoying when fellow administrators with VAXen tell me that they have no problems using blocking factors exceeding 20k. One such person said that the ANSI standard (unknown) provides for blocking factors as high as 32k!! On the plus side, there is now (in the documentation at least) a UN138 tape controller for the 3B20S that provides for maximum record lengths of 30k bytes, as well as 1600/6250 densities. SO... In addition to any problems related to different tar versions, you might be fighting tape controller limitations on maximum record length as well. --Bob Tracy AT&T Technologies, Inc. Network Systems Oklahoma City, OK ...!ihnp4!okc_5b!occrsh!rct
guy@sun.uucp (Guy Harris) (01/13/86)
> (3) System V 'tar' doesn't like the directory header info that BSD tar puts > on it. You must use the '-o' flag in BSD tar to suppress this. It may not like it, but it will tolerate it; it just prints error messages and continues when it sees the directory header info. Guy Harris
fnf@unisoft.UUCP (Fred Fish) (01/16/86)
In article <3144@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> (3) System V 'tar' doesn't like the directory header info that BSD tar puts >> on it. You must use the '-o' flag in BSD tar to suppress this. > >It may not like it, but it will tolerate it; it just prints error messages >and continues when it sees the directory header info. > Perhaps this is true of most system V's, but have you tried it on a PDP-11 under System V Release 0? It made a directory with some VERY interesting filenames, the first (and last) time I tried it. -Fred
dave@onfcanim.UUCP (Dave Martindale) (01/16/86)
[People have been discussing tape controller limitations on the 3B series of computers] With the exception of a few recent products, DEC controllers (disk and tape) have never buffered the data they were handling, except for a small silo in some cases to smooth out data flow. Thus, they have always been able to transfer as many bytes as you could ask for, which was either 2^16 bytes or 2^16 (16-bit) words, depending on the controller. Thus, anyone else who builds a controller that emulates DEC hardware is also going to support large transfers. On a workstation with 1/4 inch cartridge tape drive (SGI IRIS), the "standard" block sizes for tar and cpio are 200Kb and 250Kb respectively, to make the best use of the drive - it has to back up and take a flying start for every block read. And from the standpoint of tape use, even a block size of 20 isn't that high; it results in wasting 10% of the tape in interrecord gaps at 1600BPI, and much more at 6250. Now, for a question: Why would anyone in their right mind design a tape controller that could only handle 5Kb records? Surely the data doesn't have to be buffered? Only the very fastest tape drives (6250 BPI at 125 or 200 IPS) handle data at anything close to the rates that the system bus *must* be able to handle in order to handle any kind of decent disk. Dave Martindale