home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / rsts / 105 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  5.2 KB
  1. Path: sparky!uunet!ukma!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!nigel.msen.com!msage
  2. From: msage@msen.com (Micro Sage Software)
  3. Newsgroups: comp.os.rsts
  4. Subject: Re: Exabyte Backup Failures
  5. Date: 28 Jan 1993 00:17:23 GMT
  6. Organization: Msen, Inc. -- Ann Arbor, Michigan
  7. Lines: 102
  8. Distribution: inet
  9. Message-ID: <1k78n2INNhvb@nigel.msen.com>
  10. References: <1k4rs4INN5tv@nigel.msen.com>
  11. NNTP-Posting-Host: garnet.msen.com
  12. X-Newsreader: TIN [version 1.1 PL8]
  13.  
  14. Dan and Karen Sugalski (dan@msen.com) wrote:
  15. : Stephen Carter (stevedc@syma.sussex.ac.uk) wrote:
  16.  
  17. : : We are running RSTS 9.7.  We have had exabytes since I don't know how
  18. : : long, and have been VERY happy with the overall functionality.
  19.  
  20. : : In July 1992 we swapped two 512Mb Fuji's for Two 2Gb Seagate ST42400
  21. : : Scsi discs hanging off a CMD Scsi controller.  The users' data did
  22. : : expand (naturally!) but currently stands at (laboriously calculated) 
  23. : : 2,146,696,704 bytes.
  24.  
  25. : : When we backup now, the run fails (after 13 hours) with the following
  26.  
  27. : :     |
  28. : :     |
  29. : :     ?Error reading Backup set
  30. : :     ?Data error on device
  31. : :     ?Error reading Backup set
  32. : :     ?Data error on device
  33. : :     ?Unexpected error 14 in RSTRMS
  34. : :     |
  35.  
  36. : : On the face of it, with these data volumes it may appear to be a badly
  37. : : handled end-of-reel situation, so before folk flame me, I HAVE seen a real 
  38. : : end-of-reel situation on the exabyte, and that was handled properly
  39. : : (Please mount volume 2 of Backup set   etc etc)
  40.  
  41. : : What is it?
  42.  
  43. RSTRMS is just an overlay in backup, nothing that you explictly called
  44. into being.  It's part of the verification (actual backup set read 
  45. routine).  This problem is most eveident on 11/44 systems.  Much less a
  46. problem on 11/84's
  47.  
  48. : Well, this sounds suspiciously like a problem that I've encountered on a
  49. : lot of customer's machines--namely that RSTS' TMSCP handler has pretty
  50. : poor error recovery. While I've never encountered an error in the middle
  51. : of a backup, the most anyone's ever dumped to the thing are two RA81s
  52. : (~750 meg of data, not counting free space left on the drives).
  53.  
  54. Actually, the largest customer using ome of these we have has 2 nearly
  55. full RA81's ~= .9gb.  They only encounter problems during restores.
  56.  
  57. : What seems to happen is that somewhere between the tape drive and the
  58. : TMSCP handler, a packet gets lost, and the two get out of sync, never
  59. : again to talk. (We have to power the drive and computer off--a reboot
  60. : doesn't seem to be enough)
  61.  
  62. Right.  The reason VMS will work with the turkey drives is that the TMSCP
  63. handler is very pushy about things.  It will keep hammering at a drive
  64. until something gives where as RSTS tries to be polite about it.  Since these
  65. drives barely respond to SCSI at all, RSTS often loses.
  66.  
  67. : The easiest way we've found to trigger it is to do a restore when there's
  68. : a load on the machine (100% guaranteed to cause a failure). The restore
  69. : works OK and the data gets restored, but the tape drive will not talk to
  70. : the computer any more. Symptoms include: Data Error on Device errors,
  71. : Magtape Select errors, Device Hung errors, and, my favorite, complete
  72. : machine lockups. (The latter can be cured by either inserting a tape or
  73. : ejecting the tape that's already in. Things pick up where they left off,
  74. : no harm done)
  75.  
  76. : You might try upgrading to 10.1 (Skip 10.0 unless you're ready to apply
  77. : several dozen patches, including one that's not documented anywhere, but
  78. : is lurking on the upgrade tape). The TMSCP handling is reportedly better.
  79. : I don't have any experience with the drives on it, though, as I don't
  80. : know anyone with one of the tape drives that is using it.
  81.  
  82. 2nd the 10.1 release (with emphasis on skipping 10.0).  Check with colorado
  83. as all our customers received their updates at about the same time (6
  84. months ago).  10.0 will work okay if you get all the patches.  Contact me
  85. if you would like them, I've got them all typed in as ONLPAT command file
  86. already.
  87.  
  88. : Alternatively, you may want to try putting a pause of some sort between
  89. : the BACKUP commands (maybe the big dump of data is causing a probelm and
  90. : giving the drive a chance to flush buffers and such will help). If you're
  91. : doing the verify after each backup, then *don't*! Do both backups firtst,
  92. : then verify the tape.
  93.  
  94. We verify tapes around here with a home-grown tape verification program. 
  95. It's written in Macro-11 and takes advantage of streaming tape drives
  96. (gets them going pretty fast).  It is used every night at about 5 sites on
  97. Exabytes, 3 of them using CMD controllers. 
  98.  
  99. Also, don't make your buffers too big.  If they are too large, then RSTS
  100. will have to keep stopping and refilling them which will cause it to stop
  101. streaming.  That puts a lot of wear on an already rickety tape drive (get
  102. the hint I have little love for ExaByte?).  Make the Block Size MAXIMUM and
  103. either leave the buffer size alone.
  104.  
  105. What Version of RSTS are you running?  What type of system and how much
  106. memory?  The whole thing can be system dependent.
  107.  
  108. If you'd like the verify program, contact me and I can E-Mail it to you. 
  109. It's only about 20 blocks of source. 
  110.  
  111. Gerry Duprey                                  EMAIL: gerry@msage.com 
  112. Micro Sage Software Systems                   VOICE: (313) 663-0444 
  113. 130 South First Street 
  114. Ann Arbor, MI 48104 USA
  115.  
  116.