From: johnf@shared.com (John Fusselman)
Subject: moving files from disk to tape - problems!
Summary: attempts to move files from disk to tape with dd fail instantly and
Date: Tue, 17 Nov 92 16:30:14 GMT
Distribution: usa
Organization: Shared Financial Systems
Keywords: dd cp delete tape devices

In the process of attempting to duplicate a tape I effortlessly read the 
tape contents onto disk using dd - ``dd if=/dev/rmt0.1 of=FILENAME''. The 
trouble came when I attempted to copy the files from disk to a new tape; 
dd never moved the tape but instead *promptly* produced an error as
below:

  C:9$ dd if=file1 of=/dev/rmt0 
  dd write error: Invalid argument
  17+0 records in
  16+0 records out
  C:10$ 

The file, file1, is about 1.5 Mbytes and registered 3102 blocks on the
way in, also using the default block size; disregard the record count
shown in the example above because the numbers vary from 3 or more to
less than 20 from one time to the next. Sometimes they even match,
indicating the same number of blocks out as in! The command fails so
quickly it is as though it is indeed complaining about the arguments
presented (or not presented). A search of info proved unhelpful, only
confirming my expectations that what I am trying to do is legitimate.
BTW similar operations under SunOS worked flawlessly over many years.

Either an RS/6000 550 running AIX 3.1 or a 220 running 3.2.2 acts the
same; the tape drives are both 1/4 inch cartridge, QIC-150 type,
genuine IBM. The tape drives on both machines appear to function
normally in all other respects. Not that it should have made a
difference, but I tried the arguments to dd in different orders and
with and without a blocksize as well as with "conv=sync." That
particular argument, according to info, would have an effect only on
the last block transferred because "streaming tape devices permit only
multiples of 512 bytes." It's the first blocks that concern me - the
tape never moves!

What is wrong with the use of dd to copy a file from disk to tape? Has
dd ever been fully functional under AIX?

Things got more interesting when I tried "cp" on the 220 under 3.2.2;
sometimes when it failed, it deleted the tape device! I was only able
consistently to delete rmt0, rmt0.1, .2, and .4; rmt0.5 usually works
flawlessly - if it works, it will move all of the file to tape, which
can then be retrieved and compared (with "cmp") and verified to be
perfectly reproduced and recoverable from the tape. If "cp" deletes
the device, it will do so on the first try. For what it's worth, the
"retension on open" devices will do so, even though they disappear.

Has anyone else seen the like of this, the removal of a device upon an
error from cp? The response from cp was as follows:

  M:# cp file1 /dev/rmt0.1
  cp: /dev/rmt0.1: A system call received a parameter that is not valid.
  cp: /dev/rmt0.1: A system call received a parameter that is not valid.
  M:#

Thereafter, the device, rmt0.1, would be gone.

I was logged in as root at the time the devices were deleted, but
neither as root nor under my usual login was I able to move a tape with
dd with an output file ("of=/dev/rmt0") of a tape device. Tape to disk
and disk to disk operations - whether to or from remote machines - have
always performed as expected.

Calling IBM on the problem of the disappearing tape devices yielded the
response "that you're trying to do something unorthodox, using cp to
copy a file to tape; the result should be that the one file replaces
the other." But I said it did NOT replace it; it blew it away! "No
problem; the devices are rebuilt when the system is rebooted!" I will
NOT dignify this response with a comment of my own.

At this time I await the arrival - sometime this week or next, I
presume - of my local SE to "see what I'm doing wrong or to determine
what's wrong with my systems." IMHO I think what's wrong is the
nameplate on the front and the OS it's running!

Thanks for sharing your experiences and knowledge.
-- 
                 Dallas, Texas   "Visualize whirled peas."
 --->>> My comments are my opinions and may not be shared by Shared <<<---