malc@equinox.unr.edu (Malcolm Carlock) (03/30/91)
When using a command of the form
tar cf - file ... | rsh somewhere dd of=/dev/rmt0
Is there a way of getting the remote dd to write the tape such that
the blocksize of the final tar image on tape is something other than 1?
I've tried "ibs=1 obs=512", no ibs/obs args at all, and various other
ibs/obs combinations, and a number of conv options. I still get
"tar: blocksize=1" each time I subsequently try a tar [tx] on the tape
(directly, on the remote machine.)
Grrr.
Malcolm L. Carlock Internet: malc@unr.edu
UUCP: unr!malc
BITNET: malc@equinoxarthur@sgi.com (Arthur Evans) (04/03/91)
In article <5909@tahoe.unr.edu> malc@equinox.unr.edu (Malcolm Carlock) writes: >When using a command of the form > > tar cf - file ... | rsh somewhere dd of=/dev/rmt0 > >Is there a way of getting the remote dd to write the tape such that >the blocksize of the final tar image on tape is something other than 1? I think you're asking the wrong question. I suspect that tar is writing a with a blocksize of 1, since it's writing to standard output. Try using the 'b' option to tar to specify a blocking factor. Read your tar man page under the 'b' option. Mine says: "Due to the blocking algorithm, a tar tape created by writing to the standard output should be read from standard input." So you may need to read the tape with "tar xf - < /dev/rmt0" or even (ich) "dd if=/dev/rmt0 | tar xf -". As always, your milage may vary. Good luck. -arthur -- Arthur Evans -- Information Decorator, Akbar and Jeff's Documentation Hut
kepowers@mbunix.mitre.org (Powers) (04/04/91)
>> tar cf - file ... | rsh somewhere dd of=/dev/rmt0 >Try using the 'b' >option to tar to specify a blocking factor. Read your >tar man page under the 'b' option. Mine says: >"Due to the blocking algorithm, a tar tape created by writing >to the standard output should be read from standard input." You also have the B option to force input and output to 20 blocks per record. This allows tar to work across a communications channel where the blocking may not be maintained. -- ---------- Kelly-Erin Powers The MITRE Corporation Unix Systems Group Burlington Road (617) 271-2143 Bedford, MA 01730 kepowers@mbunix.mitre.org linus!mbunix!kepowers