home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / rsts / 106 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.8 KB
  1. Path: sparky!uunet!enterpoop.mit.edu!spool.mu.edu!nigel.msen.com!dan
  2. From: dan@msen.com (Dan and Karen Sugalski)
  3. Newsgroups: comp.os.rsts
  4. Subject: Re: Exabyte Backup Failures
  5. Date: 27 Jan 1993 02:25:56 GMT
  6. Organization: Msen, Inc. -- Ann Arbor, Michigan
  7. Lines: 76
  8. Distribution: inet
  9. Message-ID: <1k4rs4INN5tv@nigel.msen.com>
  10. References: <1993Jan25.123329.11700@syma.sussex.ac.uk>
  11. NNTP-Posting-Host: garnet.msen.com
  12. X-Newsreader: TIN [version 1.1 PL8]
  13.  
  14. Stephen Carter (stevedc@syma.sussex.ac.uk) wrote:
  15.  
  16. : We are running RSTS 9.7.  We have had exabytes since I don't know how
  17. : long, and have been VERY happy with the overall functionality.
  18.  
  19. : In July 1992 we swapped two 512Mb Fuji's for Two 2Gb Seagate ST42400
  20. : Scsi discs hanging off a CMD Scsi controller.  The users' data did
  21. : expand (naturally!) but currently stands at (laboriously calculated) 
  22. : 2,146,696,704 bytes.
  23.  
  24. : When we backup now, the run fails (after 13 hours) with the following
  25.  
  26. :     |
  27. :     |
  28. :     ?Error reading Backup set
  29. :     ?Data error on device
  30. :     ?Error reading Backup set
  31. :     ?Data error on device
  32. :     ?Unexpected error 14 in RSTRMS
  33. :     |
  34.  
  35. : On the face of it, with these data volumes it may appear to be a badly
  36. : handled end-of-reel situation, so before folk flame me, I HAVE seen a real 
  37. : end-of-reel situation on the exabyte, and that was handled properly
  38. : (Please mount volume 2 of Backup set   etc etc)
  39.  
  40. : What is it?
  41.  
  42. Well, this sounds suspiciously like a problem that I've encountered on a
  43. lot of customer's machines--namely that RSTS' TMSCP handler has pretty
  44. poor error recovery. While I've never encountered an error in the middle
  45. of a backup, the most anyone's ever dumped to the thing are two RA81s
  46. (~750 meg of data, not counting free space left on the drives).
  47.  
  48. What seems to happen is that somewhere between the tape drive and the
  49. TMSCP handler, a packet gets lost, and the two get out of sync, never
  50. again to talk. (We have to power the drive and computer off--a reboot
  51. doesn't seem to be enough)
  52.  
  53. The easiest way we've found to trigger it is to do a restore when there's
  54. a load on the machine (100% guaranteed to cause a failure). The restore
  55. works OK and the data gets restored, but the tape drive will not talk to
  56. the computer any more. Symptoms include: Data Error on Device errors,
  57. Magtape Select errors, Device Hung errors, and, my favorite, complete
  58. machine lockups. (The latter can be cured by either inserting a tape or
  59. ejecting the tape that's already in. Things pick up where they left off,
  60. no harm done)
  61.  
  62. You might try upgrading to 10.1 (Skip 10.0 unless you're ready to apply
  63. several dozen patches, including one that's not documented anywhere, but
  64. is lurking on the upgrade tape). The TMSCP handling is reportedly better.
  65. I don't have any experience with the drives on it, though, as I don't
  66. know anyone with one of the tape drives that is using it.
  67.  
  68. Alternatively, you may want to try putting a pause of some sort between
  69. the BACKUP commands (maybe the big dump of data is causing a probelm and
  70. giving the drive a chance to flush buffers and such will help). If you're
  71. doing the verify after each backup, then *don't*! Do both backups firtst,
  72. then verify the tape.
  73.  
  74. Finally, check to see if there are any batch jobs that might be running in
  75. a different queue. (The bigger backup may be overlapping something else.)
  76. Also consider doing a SET SYSTEM/NOLOGINS in the com file before the
  77. backup starts. (You may want to shut down the other queues, as well as any
  78. other jobs that may be running)
  79.  
  80. And, even more finally, back up the non-system disk *first*. It's been by
  81. experience that, once TMSCP loses it, the backup/restore job is immortal.
  82. (Looks to have pending async IO--prio/runburst go to 128/127 but doesn't
  83. die) $SHUTUP won't be able to bring the system down, so you'll have to
  84. power off the machine. Dismount the big drive before you do--one fewer
  85. drive to clean...
  86.  
  87.  
  88.             .Sigs? We don' need no steenkin' .sigs!
  89.                     Dan
  90.