🚀 go-pugleaf

In article <sivbl.716535512@win4>, sivbl@win4.vut.EDU.AU (Brett L Sivies) writes:
|> Hi,
|> 
|> pete@wvus.org (Pete Gregory) writes:
|> 
|> >we use /etc/dump - the filesystem dump program here.  two years ago i
|> >wrote a shell-script wrapper for it so the operators could just answer
|> >questions.  that works fine, if i tell dump to write directly to output 
|> >device.  if i tell dump to write to stdout (an allowable feature 
|> >according to the man page), it writes several error messages to the 
|> >screen at the end of the dump that say "DUMP: Failure to acquire 
|> >semaphore", "DUMP: Failure to release semaphore" and "DUMP: Possibly 
|> >corrupted archive" (i'm not sure about the exact text of the last one).
|> 
|> 1. Yes the problem has arrisen for myself, and with the help of sequent I
|> was able to fix the problem straight away... Is the Tape drive you are
|> using an Exabyte or standard .25 cartridge?
|> My problem centred around an exebyte drive on a S27.
|> We had to make sure the tape drive was getting all the right parameters
|> before it would work correctly...
|> 
|> /etc/dump 0sbdfu 15070 8 500000 /dev/rmt/<tape> /dev/dsk/<disk>
|> 
|> This is running under PTX 1.3.0 and it works fine dumping to an exabyte
|> drive.
|> 
We had the same problems with PTX 1.3 with Cybernetics 8mm drive. Sequent
FAXed us a lengthy tech note in which tehy give two options to solve the
problem.

1) Increase SEMAEM from default 16384 to 32767

2) Use a larger block size based on the file system size.

I did the former and dump runs fine now. The tech note's name/number is
snote-hw-tape-t8mm-2.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Kyle Tucker - Email Administrator  | 		Progress Software Corporation
tucker@bedford.progress.com 	   |		14 Oak Park
(617)280-4565			   |		Bedford, Mass. 01730
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -