ULTRIX 1.1 Eagle Disc Problems solved - Summary

[Sebastian Schmitz]

Expires:
References:
Sender:
Reply-To: snoopy at 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 */