home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12461 < prev    next >
Encoding:
Text File  |  1992-08-15  |  3.1 KB  |  85 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!wupost!darwin.sura.net!mips!odin!fido!zola!zuni!anchor!olson
  3. From: olson@anchor.esd.sgi.com (Dave Olson)
  4. Subject: Re: help in understanding tape blocks: dd, bstream, tar
  5. Message-ID: <ok5q824@zuni.esd.sgi.com>
  6. Sender: news@zuni.esd.sgi.com (Net News)
  7. Organization:  Silicon Graphics, Inc.  Mountain View, CA
  8. References: <16hugoINNr9s@agate.berkeley.edu>
  9. Distribution: na
  10. Date: Sat, 15 Aug 92 20:24:47 GMT
  11. Lines: 72
  12.  
  13. In <16hugoINNr9s@agate.berkeley.edu> bartlett@violet.berkeley.edu (Paul Bartlett/Gary Shea;Lat 841;;;MV86) writes:
  14.  
  15. | Situation: Machines: Indigo, 4D70/GT  Running 4.0.5
  16. |            Tape drive (4D70/GT, from SGI): ARCHIVE: VIPER 150  21247-005 VP1
  17. |        Tape drive (ditto, from ANDATATO): EXABYTE: EXB-8200        2618
  18. |            Tape drive (Indigo, from SUN): ARCHIVE: VIPER 150  21531-004
  19. | 
  20. | The following happens on all three combinations.
  21. | 
  22. | What I'm trying to do:
  23. | use tar with bstream as per the bstream man page to make backups
  24. | and distribution tapes for customers to use.
  25.  
  26. The problem is that bstream defaults to 64Kbyte blocks if -b isn't
  27. used, and for non-tape devices, tar defaults to 20.  The net result
  28. is that bstream sees a 0 returned before tar quits having seen
  29. its internal end of archive record, so bstream prompts for an
  30. additional tape.  Specify the same blocking factor to tar and
  31. bstream, or at least make tar's blocksize a multiple of bstream's,
  32. and the problem will go away.
  33.  
  34. I.e., it isn't a bug, but a (subtle) user error.
  35.  
  36. By the way, I seldom see much advantage in using bstream with SCSI tape.
  37. SCSI tape does readahead typically when reading, and does double
  38. buffering in the tape drive with our driver.  Using bstream also
  39. makes error recovery more problematical.  In some cases, bstream
  40. will actually slow things down with SCSI, since there is more
  41. data movement going on.
  42.  
  43. Finally, you can see similar problems under 4.0 using just tar,
  44. if you specify a different blocking factor when reading than
  45. when writing, for similar reasons.  (tar gets a 0 read back from
  46. the tape driver before seeing the end-of-archive record, because
  47. of the way the buffering works.  I've thought of trying to special
  48. case this, but the way the buffering code is done in tar makes
  49. this less than clean, and may introduce some subtle bugs.)
  50.  
  51. | (1) tar cf - Mail | bstream -o/dev/tape
  52. | 
  53. | and then, I do
  54. | 
  55. | (2) bstream -i/dev/tape | tar tf -
  56. | 
  57. | and get a listing of most of my directory, then a message:
  58. | 
  59. | </dev/tape> Change tape and type RETURN or "quit":
  60. | 
  61. | and if I hit return, I get the rest of my directory, and the
  62. | message again.
  63. | 
  64. | If I try 
  65. | 
  66. | (3) tar t
  67. | 
  68. | directly, I get some of my directory (less than before), then 
  69. | a message
  70. | 
  71. | Change tape and press the Enter key:
  72. | 
  73. | and if I hit return, I get the rest of my directory.
  74. | 
  75. | If I do
  76. | 
  77. | (4) dd if=/dev/tape | tar tf -
  78. | 
  79. | *then* I get the whole directory. This also works if I put a 
  80. | bstream into the pipe.
  81. --
  82. Let no one tell me that silence gives consent,  |   Dave Olson
  83. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  84.     Maria Isabel Barreno                        |   olson@sgi.com
  85.