home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / dec / 4980 < prev    next >
Encoding:
Text File  |  1992-09-14  |  3.4 KB  |  82 lines
  1. Newsgroups: comp.sys.dec
  2. Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
  3. From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  4. Subject: re: Non-Interactive dump for RISC Ultrix 4.2 [it is]
  5. Message-ID: <1992Sep14.193905.11916@nntpd2.cxo.dec.com>
  6. Lines: 69
  7. Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  8. Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
  9. Organization: Digital Equipment Corporation
  10. References:  <GEORGE.92Sep14023506@tusk.med.harvard.edu>
  11. Date: Mon, 14 Sep 1992 19:39:05 GMT
  12.  
  13.  
  14. In article <GEORGE.92Sep14023506@tusk.med.harvard.edu>, george@tusk.med.harvard.edu (George Planansky) writes:
  15. >
  16. >The Ultrix 4.2 dump paramater "B", it turns out, refers
  17. >to the capacity in 1024 byte blocks of the dump tape.  Seems
  18. >redundant to me.
  19.  
  20. The manual page entry for 'B' reads:
  21.  
  22. "Indicates that the next argument is a number that specifies the
  23.  size, in 1024-byte blocks, of a storage medium, such as a
  24.  diskette or removable disk cartridge."
  25.  
  26. Note the "diskette or removable disk cartridge".  I'd guess that
  27. when dump(8) sees the 'B' option it begins believing the output
  28. media is disk instead of tape.  Disk can after call have a fixed
  29. number of 1 KB blocks.  On tapes the number 1 KB blocks can change
  30. because of records skipped due to errors and such.
  31.  
  32. >This is NOT to be confused with the Sun's SunOS and SGI's IRIX dumps' 
  33. >"b" parameter, which refers to a blocking factor.  (Why doesn't the
  34. >Ultrix dump have this?)
  35.  
  36. Because little active improvement has been made on dump(8) over the
  37. last few years.  Aside for support for new tape drivers, loader support
  38. and the TA90, etc, there hasn't been much new.  I don't know WHY little
  39. improvement has been made, but must assume it's because the people that
  40. schedule engineering's time don't believe it needs to be updated.  This
  41. has been a classic problem of ours and I'm not sure how to fix it.  Maybe
  42. a concerted SPR or letter writting campaign to corporate executives...
  43.  
  44. Oh, the last time I looked the 'b' option for a blocking factor was
  45. present in dump(8).  It just isn't documented.  The problem is that
  46. there isn't corresponding support in restore.
  47.  
  48. >
  49. >And why does the Ultrix dump ask me to mount a disk, when it computes
  50. >that it has run out of tape?
  51.  
  52. As noted before, because it believes it is writting to disk instead
  53. of tape.  Don't use the 'B' option on tapes. 
  54. >
  55. >The following (from Mountain Computer's exabyte manual) seems to work:
  56. >
  57. >   dump 0usdBf 346 4137733 2097152 /dev/nrmt1h /usr
  58.  
  59. It is always worth noting that ULTRIX dump(8) will use all of the
  60. available and accessible tape (*).  For supported tapes, it should
  61. have (but sometimes doesn't) reasonable parameters for estimating
  62. the amount of tape needed.  Please recognize the estimates as just
  63. that, ESTIMATES.  If the parameters are wrong, then the estimates
  64. will be wrong.  It will still use all the tape.
  65.  
  66. However, if you specify other parameters to use as estimates, it
  67. will trust you and work on the assumption that your estimate is
  68. correct.  If you provide bad information, then you may end up
  69. telling it to use only part of a tape.
  70.  
  71. >--
  72. >George Planansky
  73. >Department of Biological Chemistry & Molecular Pharmacology
  74. >Harvard University Medical School, 240 Longwood Ave., Boston, MA 02115
  75. >email: gplanansky@tusk.med.harvard.edu
  76. >phone: (617) 432-3919
  77. >fax:   (617) 432-4360
  78. >
  79. --
  80. Alan Rollow                alan@nabeth.cxo.dec.com
  81.  
  82.