home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / sequent / 553 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.4 KB  |  55 lines
  1. Newsgroups: comp.sys.sequent
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!think.com!linus!progress!bedford.progress.COM!tucker
  3. From: tucker@bedford.progress.COM (Kyle Tucker)
  4. Subject: Re: /etc/dump (backup) errors
  5. Message-ID: <1992Sep15.203422.5712@progress.com>
  6. Sender: tucker@bahrain (Kyle Tucker)
  7. Nntp-Posting-Host: bahrain
  8. Reply-To: tucker@bedford.progress.COM
  9. Organization: Progress Software Corp.
  10. References: <1992Sep09.215425.18559@wvus.org> <sivbl.716535512@win4>
  11. Date: Tue, 15 Sep 1992 20:34:22 GMT
  12. Lines: 41
  13.  
  14. In article <sivbl.716535512@win4>, sivbl@win4.vut.EDU.AU (Brett L Sivies) writes:
  15. |> Hi,
  16. |> 
  17. |> pete@wvus.org (Pete Gregory) writes:
  18. |> 
  19. |> >we use /etc/dump - the filesystem dump program here.  two years ago i
  20. |> >wrote a shell-script wrapper for it so the operators could just answer
  21. |> >questions.  that works fine, if i tell dump to write directly to output 
  22. |> >device.  if i tell dump to write to stdout (an allowable feature 
  23. |> >according to the man page), it writes several error messages to the 
  24. |> >screen at the end of the dump that say "DUMP: Failure to acquire 
  25. |> >semaphore", "DUMP: Failure to release semaphore" and "DUMP: Possibly 
  26. |> >corrupted archive" (i'm not sure about the exact text of the last one).
  27. |> 
  28. |> 1. Yes the problem has arrisen for myself, and with the help of sequent I
  29. |> was able to fix the problem straight away... Is the Tape drive you are
  30. |> using an Exabyte or standard .25 cartridge?
  31. |> My problem centred around an exebyte drive on a S27.
  32. |> We had to make sure the tape drive was getting all the right parameters
  33. |> before it would work correctly...
  34. |> 
  35. |> /etc/dump 0sbdfu 15070 8 500000 /dev/rmt/<tape> /dev/dsk/<disk>
  36. |> 
  37. |> This is running under PTX 1.3.0 and it works fine dumping to an exabyte
  38. |> drive.
  39. |> 
  40. We had the same problems with PTX 1.3 with Cybernetics 8mm drive. Sequent
  41. FAXed us a lengthy tech note in which tehy give two options to solve the
  42. problem.
  43.  
  44. 1) Increase SEMAEM from default 16384 to 32767
  45.  
  46. 2) Use a larger block size based on the file system size.
  47.  
  48. I did the former and dump runs fine now. The tech note's name/number is
  49. snote-hw-tape-t8mm-2.
  50. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  51. Kyle Tucker - Email Administrator  |         Progress Software Corporation
  52. tucker@bedford.progress.com        |        14 Oak Park
  53. (617)280-4565               |        Bedford, Mass. 01730
  54. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  55.