home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20402 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  2.4 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!galaxy.dnet!gleeve
  2. From: gleeve@galaxy.dnet
  3. Newsgroups: comp.os.vms
  4. Subject: Long standing apparent Backup or XQP problem
  5. Message-ID: <9301052330.AA21443@relay1.UU.NET>
  6. Date: 5 Jan 93 23:18:59 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 48
  11.  
  12. When making up masters for the VMS/L&T sig tapes at the recent
  13. DECUS symposium, I encountered a problem making a Backup
  14. saveset which had happened at the prior symposium as well. I thought
  15. the community might appreciate an alert that this can happen.
  16.  
  17. What I did:
  18.   I ran Backup on a VAX 6660 to create savesets, on the same disk,
  19.    where the disk had plenty of space (well, it had plenty before
  20.    I started :-) ). The commands were of the form
  21.  
  22. $ backup/block=4096/trunc [.a*...] [somewhere]a.bck/save
  23.  
  24. which normally creates a saveset of all the relevant directories.
  25.  
  26.   Doing a BACKUP/LIST of [somewhere]a.bck/save
  27.  
  28. revealed errors recovered by XOR groups, and errors of lost blocks
  29. in files within the saveset, EVEN THOUGH there were NO errors reported
  30. by Backup during creation of the savesets, nor any hardware errors
  31. (via show error) reported on the device.
  32.  
  33.    If I tried again, I could eventually (within at most 4 tries)
  34. get a clean saveset. The problem seemed to occur more often if
  35. other disk accesses (even read accesses!) were going on at the time.
  36.  
  37.    I have not seen this problem on a uniprocessor, and subsequently
  38. switched to using one on the floor. This is however the second time
  39. I have seen this on an SMP VAX (it happened in Atlanta too). I suspect
  40. some XQP bug on an SMP machine, or perhaps some way in which
  41. Backup can misbehave when the account's AUTH params are set wrong.
  42.  
  43.    (Unfortunately, the account is set up as a courtesy by DEC folks
  44. and I was not willing to run authorize to look at it, since it is
  45. after all not my machine, and in any case I lacked the privs to
  46. modify it legitimately.)
  47.  
  48.    The point of all this is cautionary: at least SOME of the
  49. time use BACKUP/COMPARE or BACK/LIST on your savesets to ensure
  50. this is not happening to you.
  51.    If anyone can shed light on the problem beyond this caution,
  52. please feel welcome. If it happens again I will gather more information
  53. on the account. Still, the problem didn't occur, with the same
  54. account, where backup was running on a uniprocessor.
  55. Glenn
  56. Everhart@raxco.com
  57. VMS SIG Tapecopy coordinator
  58.  
  59.  
  60.