snoopy@ecrcvax.UUCP (Sebastian Schmitz) (02/18/86)
Expires: References: Sender: Reply-To: snoopy@ecrcvax.UUCP (Sebastian Schmitz) Followup-To: Distribution: Organization: European Computer-Industry Research Centre, Munchen, W. Germany Keywords: Dear Net, Here is a summary of the eagle problem solved. Thanks to all who responded. I hope this helps some of you sometime. It turned out we had a broken disc controller. Power was partly responsible: when we pulled some other current eaters out the controller showed large -uh- variations in its behaviour.... (due to its fault - a new controller worked ok). Anyways to answer some of the queries posed by you and to reward you with some of the knowhow gained ;-) the very hard way (about a week of sleepless days & nights), here goes... 1- yes, eagles are smaller than ra81's. I got it the wrong way around ! 2- ULTRIX 1.1 does allow disc partitioning when the system is running. This is really top notch. But one has to be careful. The manual for the chpt (change partition program) says:"Be careful - indiscriminate changing of the partitioning can result in losing large amounts of data." Nominated understatement of the year. But it is *lovely* to have. No more tweaking the driver and recompiling the kernel. One can frob the disc partitions live now. GREAT ! The other groovy feature of /etc/chpt is that it will tell you which disc partitions overlap with what. VERY VERY GOOD for finding those blocks which just happen to thunder into the next partitions superblock.... 3- one thing that screwed us for a while was that my SI eagles have 48 sects per track and the MSCP controller says they only have 47. Answer: The MSCP *controller* reserves one (the last) sector of any track for *its own* bad block forwarding. Therefore be sure that you declare the disc properly - i.e. 48 sects per track for *NON MSCP* controllers (like System Industries). For MSCP controllers (like DEC and Emulex) you have to declare 47. I presume the general way is to have one less than nsect for MSCP devices. 4- "Old" disc drivers (i.e. ones which do not read the current partitioning scheme off the drive) can be compiled into ULTRIX 1.1 without problems. 5- up to ULTRIX 1.0 Ultrix used to have disc drivers which would do their own bad block forwarding. This worked well until one day a disc went on a rampage and the bad block table got filled very quickly (even though the disc was ok, just the arm stuck a bit..). Therefore some wise person (seriously) at DEC decided to take it out. GOOD thing too. No system can ever be as discerning as humans. Mild FLAME ON... I really like the MicroVAX2's. We just got 2 with 9MB memory (bigger than our 785) and I have configured three others running various versions of ULTRIX. I am duly impressed. They are awfully fast (even on the little winnies - I was really surprised). ULTRIX is a truly professional product. Everything works first time. The compatibility even for binaries (homegrown on 4.2) is frightening (the editor crashes at the same point etc.). I don't know how to put this, but it has a very good 'feel' to it. The people who put it together really thought long & hard and *good*. I take back anything negative I have ever said about MV2's and claim the opposite. Shame - I'm gonna miss those soft hands... (ok, Joe, drag in the humble pie...) /etc/chpt is my long lost love...the best thing to happen to UNIX for a long time. I hope this is not too commercial. I am not with DEC. FLAME OFF. Some of the problems could have been solved with better info on MSCP. I have nothing on this. Is there anyone who can point me to some reliable documentation ? Love, Seb -- There are three types of people: - those who make things happen - those who watch things happening - and those who wonder what happened ...\!mcvax\!unido\!ecrcvax\!snoopy /* N.B. valid csh address */
chris@umcp-cs.UUCP (Chris Torek) (02/19/86)
In article <207@ecrcvax.UUCP> snoopy@ecrcvax.UUCP (Sebastian Schmitz) writes: >... my SI eagles have 48 sects per track and the MSCP controller >says they only have 47. Answer: The MSCP *controller* reserves one >(the last) sector of any track for *its own* bad block forwarding. >[...] I presume the general way is to have one less than nsect >for MSCP devices. Assuming only one sector per track is unwise. The `get unit status' end packet includes information on the number of reserved sectors per track. >Some of the problems could have been solved with better info on >MSCP. I have nothing on this. Is there anyone who can point me to >some reliable documentation ? No---or at least not yet.... (`Shipped on the tenth'... let me see... that means I should see them by the end of the year....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu