home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / aix / 11652 < prev    next >
Encoding:
Text File  |  1992-11-17  |  4.1 KB  |  90 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!shared!johnf
  3. From: johnf@shared.com (John Fusselman)
  4. Subject: moving files from disk to tape - problems!
  5. Summary: attempts to move files from disk to tape with dd fail instantly and
  6. Message-ID: <1992Nov17.163014.66377@shared.com>
  7. Date: Tue, 17 Nov 92 16:30:14 GMT
  8. Distribution: usa
  9. Organization: Shared Financial Systems
  10. Keywords: dd cp delete tape devices
  11. Lines: 77
  12.  
  13. In the process of attempting to duplicate a tape I effortlessly read the 
  14. tape contents onto disk using dd - ``dd if=/dev/rmt0.1 of=FILENAME''. The 
  15. trouble came when I attempted to copy the files from disk to a new tape; 
  16. dd never moved the tape but instead *promptly* produced an error as
  17. below:
  18.  
  19.   C:9$ dd if=file1 of=/dev/rmt0 
  20.   dd write error: Invalid argument
  21.   17+0 records in
  22.   16+0 records out
  23.   C:10$ 
  24.  
  25. The file, file1, is about 1.5 Mbytes and registered 3102 blocks on the
  26. way in, also using the default block size; disregard the record count
  27. shown in the example above because the numbers vary from 3 or more to
  28. less than 20 from one time to the next. Sometimes they even match,
  29. indicating the same number of blocks out as in! The command fails so
  30. quickly it is as though it is indeed complaining about the arguments
  31. presented (or not presented). A search of info proved unhelpful, only
  32. confirming my expectations that what I am trying to do is legitimate.
  33. BTW similar operations under SunOS worked flawlessly over many years.
  34.  
  35. Either an RS/6000 550 running AIX 3.1 or a 220 running 3.2.2 acts the
  36. same; the tape drives are both 1/4 inch cartridge, QIC-150 type,
  37. genuine IBM. The tape drives on both machines appear to function
  38. normally in all other respects. Not that it should have made a
  39. difference, but I tried the arguments to dd in different orders and
  40. with and without a blocksize as well as with "conv=sync." That
  41. particular argument, according to info, would have an effect only on
  42. the last block transferred because "streaming tape devices permit only
  43. multiples of 512 bytes." It's the first blocks that concern me - the
  44. tape never moves!
  45.  
  46. What is wrong with the use of dd to copy a file from disk to tape? Has
  47. dd ever been fully functional under AIX?
  48.  
  49. Things got more interesting when I tried "cp" on the 220 under 3.2.2;
  50. sometimes when it failed, it deleted the tape device! I was only able
  51. consistently to delete rmt0, rmt0.1, .2, and .4; rmt0.5 usually works
  52. flawlessly - if it works, it will move all of the file to tape, which
  53. can then be retrieved and compared (with "cmp") and verified to be
  54. perfectly reproduced and recoverable from the tape. If "cp" deletes
  55. the device, it will do so on the first try. For what it's worth, the
  56. "retension on open" devices will do so, even though they disappear.
  57.  
  58. Has anyone else seen the like of this, the removal of a device upon an
  59. error from cp? The response from cp was as follows:
  60.  
  61.   M:# cp file1 /dev/rmt0.1
  62.   cp: /dev/rmt0.1: A system call received a parameter that is not valid.
  63.   cp: /dev/rmt0.1: A system call received a parameter that is not valid.
  64.   M:#
  65.  
  66. Thereafter, the device, rmt0.1, would be gone.
  67.  
  68. I was logged in as root at the time the devices were deleted, but
  69. neither as root nor under my usual login was I able to move a tape with
  70. dd with an output file ("of=/dev/rmt0") of a tape device. Tape to disk
  71. and disk to disk operations - whether to or from remote machines - have
  72. always performed as expected.
  73.  
  74. Calling IBM on the problem of the disappearing tape devices yielded the
  75. response "that you're trying to do something unorthodox, using cp to
  76. copy a file to tape; the result should be that the one file replaces
  77. the other." But I said it did NOT replace it; it blew it away! "No
  78. problem; the devices are rebuilt when the system is rebooted!" I will
  79. NOT dignify this response with a comment of my own.
  80.  
  81. At this time I await the arrival - sometime this week or next, I
  82. presume - of my local SE to "see what I'm doing wrong or to determine
  83. what's wrong with my systems." IMHO I think what's wrong is the
  84. nameplate on the front and the OS it's running!
  85.  
  86. Thanks for sharing your experiences and knowledge.
  87. -- 
  88.                  Dallas, Texas   "Visualize whirled peas."
  89.  --->>> My comments are my opinions and may not be shared by Shared <<<---
  90.