Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!lewis!steve From: steve@lewis.OZ (Steve Pattinson) Newsgroups: comp.sys.pyramid Subject: Re: Megatape Summary: We have similar problems Message-ID: <234@lewis.OZ> Date: 29 Aug 89 03:29:23 GMT References: Organization: Lewis Construction Co. P/L., Melbourne, Australia. Lines: 54 In article , erek@helios.enea.se (Erik Ekstr|m) writes: > > I am working on a site with one Pyramid 9035 and one Pyramid 9015. > The 9035 have mirror disks and both of them have one Megatape (500MB) > tapedriver. The controller is IOP/TPE. > We have a 500 Mbyte Megatape connected to a 9825 and previously a 98xe. We have seen some of the problems you are having in the past although we are reasonably happy with the device now. > 1. Sometimes we get a write error (BOT is found before EOT) > on the tape (end of tape) when we're using cpio for dumping > the filesystems. > This happened here too, although we were using 'dump'. A BOT is suddenly encountered in the middle of the tape. There were various theories about this, but in the end our Megatape service agency fixed the problem without reference to the Pyramid s/w or microcode etc. (New firmware may have been loaded into the Megatape.) I suggest you approach the matter as if it were a fault with the Megatape itself. > 2. We lose the microcode in the TPE once and a while. Yep, seen that. Our current 9825 running OSX4.4 seems to do it less often than the 98xe we had before, but that might be my imagination. I gather it's a generic fault. I've even seen it happen on a Nixdorf Targon 35 (a Pyramid clone) We could usually make it happen with a "mt fsf n" command, where n was of such a value that the search would take many minutes. It seemed that the TPE microcode timed out (perhaps timeouts setup for 9 track tape) and caused the microcode failure. We did have this problem partially fixed in a PTF about a year ago, although long searches still fail, and one has to do many "mt fsf 1"'s instead of going direct to the file you want. > 3. Sometimes we get a systemcrash when we're re trying to > reload the microcode on the living 9035. > We have not had this problem although we have loaded the microcode (as per /etc/brc command) on the fly many times. > 4. We get a write error in the middle of the tape quite a few > times. > Suggests your Megatape need attending to. We have this problem very rarely. > 5. The tape differs quite a lot in length. > More likely changes in efficiency in writing to the tape I would have thought. Have you tried a large block size? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Stephen Pattinson. | ACSnet => steve@lewis.oz | Ph => +61 3 320 4700 Lewis Construction (Co) Pty.Ltd., 15 Batman St., West Melbourne 3003. Australia