4.1.1 upgrade and ciprico
I got there in the end. It is obviously a popular subject as I got a lot of
requests for summaries. The problems seem to be caused by some advice
ciprico give on using the tunefs command after newfs. From 4.1.1 the
maximum contiguous space alllowed is 7 blocks whereas ciprico recommend
40 . Unfortunately tunefs allows you to specify 40 (even though it is
illegal). The system has problems when it mounts. Because mount knows about
tyhe limit of 7.
There is also a problem apparently with some names used in the driver with
names now introduced from sun.(see below).
Thanks fopr all your help. I hope to start upgrading this w/e.
Mark Read Sun System Mnager Geco Stavanger.
Special thanks to,
mcneill%eplrx7@uunet.UU.NET (Keith McNeill)
sid%ingres.com@sjsca4.psi
----- Begin Included Message -----
>Frommcneill%eplrx7@uunet.UU.NET Tue Feb 26 16:13:52 1991
Received: from uunet.UU.NET ([137.39.1.2]) by GEST20.sinet.slb.com; Tue, 26 Feb 91 16:13:41 +0100
Received: from eplrx7.UUCP by uunet.UU.NET with UUCP
(5.61/UUNET-primary-gateway) id AA09369; Tue, 26 Feb 91 10:16:39 -0500
Received: from dude.research.epl by eplrx7 (4.1/SMI-4.0)
id AA20019; Tue, 26 Feb 91 10:14:02 EST
Date: Tue, 26 Feb 91 10:14:02 EST
From:mcneill%eplrx7@uunet.UU.NET (Keith McNeill)
Message-Id: <9102261514.AA20019@eplrx7>
Received: by dude.research.epl (4.1/SMI-4.1)
id AA00435; Tue, 26 Feb 91 10:11:56 EST
Subject: Re: 4.1.1 upgrade and ciprico
Status: R
> Hi netland,
> I am planning on upgrtading to 4.1.1 shortly. I have heard some rumours
> that there are problems with the driver being unstable for ciprico /rimfire
> driivers for esdi/smd controllers (I think the part numbers are 3200 and
> 3400). I am currently running 1.16 of the combined rimfire/ciprico driver.
> Could somebody please confirm/appease my worries.
> I will summarize.
>
> The rumours I have heard says that the machine keeps falling over periodically
> (so to speak).
>
> Mark Read Sun System Manager Geco A/S Stavanger Norway
>
> Ps We are running both Sun 4/330 and Sun 3/160 cpus.
We have been running 4.1.1 since New Years without any problems with our
3200s & 3400s. We have version 2.0 of the device driver..you may want to
call Ciprico to get it.
2 things to note:
1) You have to change the name of the rfsize() routine in the driver so
that it doesn't confilict with RFS...Ciprico suggests rrfsize().
2) If you used tunefs to change maximum contiguous sectors on the drive
(as Ciprico suggested) you have to change it so that it is <= 7. See
the tunefs man page.
If you don't reduce maxcontig the file system will pass fsck but
you will get an IO error when you try to mount it.
Keith
Keith D. McNeill | Du Pont Company
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
----- End Included Message -----
----- Begin Included Message -----
>From sid%ingres.com@sjsca4.psi Wed Feb 27 05:37:09 1991
Received: from sjsca4.psi by GEST20.sinet.slb.com; Wed, 27 Feb 91 05:37:08 +0100
Date: Wed, 27 Feb 91 05:37:08 +0100
From: sid%ingres.com@sjsca4.psi
To: mark
X-Vms-To: gest20.SINet.SLB.COM::mark
Subject: Re: help with 4.1.1 and ciprico smd controller
Status: R
yes, indeed, I did get by this. There is a duplicate symbol named
rfsize that got introduced when sun started supporting RFS net
devices. You need to make sure that the ciprico rf driver sources
have the the changed rfsize symbol (or you can certainly change it
yourself in all occurrances - you can change ti anything - rfdsize,
rfpsize seem to be popular choices.)
Good luck,
--
Sid Shapiro -- ASK Computer Systems, Inc. Ingres Division
sid@ingres.com (415)748-3470
----- End Included Message -----
----- Begin Included Message -----
>Fromaditya@cs.uh.edu Tue Feb 26 19:59:45 1991
Received: from lavaca.uh.edu by GEST20.sinet.slb.com; Tue, 26 Feb 91 19:59:32 +0100
Received: from voyager.cs.uh.edu by lavaca.uh.edu with SMTP id AA23999
(5.65a+/IDA-1.4.2 formark@gest20.SINet.SLB.COM); Tue, 26 Feb 91 13:03:48 -0600
Received: by voyager.cs.uh.edu (4.1/SMI-4.1)
id AA08017; Tue, 26 Feb 91 13:03:17 CST
Date: Tue, 26 Feb 91 13:03:17 CST
From:aditya@cs.uh.edu (Aditya Talwar)
Message-Id: <9102261903.AA08017@voyager.cs.uh.edu>
To:mark@gest20.SINet.SLB.COM
Subject: Re: Filesystem Compatiblity between 4.0.3->4.1.1
Status: R
Hi Mark,
I am including some messages for your refrenece
If you have problems contact me
Thanks
aditya@cs.uh.edu
>From quest!cipric!kec@mmm.serc.mmm.com Fri Jan 11 10:24:14 1991
Received: from umn-cs.UUCP by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP
id AA28424; Fri, 11 Jan 91 10:55:24 EST
Received: by umn-cs.cs.umn.edu (smail2.5)
id AA27028; 11 Jan 91 09:44:02 CST (Fri)
Received: by quest.UUCP (smail2.5)
id AA11805; 11 Jan 91 09:46:55 CST (Fri)
Received: by cipric.mn.org (smail2.5)
id AA00688; 10 Jan 91 11:20:28 CST (Thu)
To:aditya@cs.uh.edu
Subject: Ciprico Controllers and SunOS 4.1.1
Date: 10 Jan 91 11:20:28 CST (Thu)
From:kec@cipric.mn.org (Ken E. Carson)
Message-Id: <9101101120.AA00688@cipric.mn.org>
Status: R
Aditya,
The problem that you are most likely experiencing is due
to a tunefs bug in the 4.1.1 release. We have normally recommended
tuning filesystems with a rotational delay of zero and maximum
contiguous blocks value of 40. According to the 4.1.1 relase notes
(Known Problems, page 93) the maxcontig parameter cannot be set
above seven. If your Rimfire controlled disks were tuned according
to our recommendations, they would not mount under 4.1.1. It is not
necessary to reformat or make new file systems to recover from this
problem, only to tunefs with the -a option at 7 or less. The most
important item in tuning filesystems on a Ciprico controlled disk
is the rotational delay. This must be set to zero for best
performance. If you have any questions, please call or email.
Ken Carson
Ciprico Customer Support
(612) 559-2034 (Operator)
(612) 559-3915 Extension 236 (Direct/Voice Mail)
kec@cipric.mn.org
uunet!rosevax!cipric!kec
>From auspex!auspex.com!guy@uunet.UU.NET Thu Jan 10 16:22:45 1991
Received: from auspex.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA07033; Thu, 10 Jan 91 17:23:08 -0500
Date: Thu, 10 Jan 91 11:38:14 PST
From:guy@auspex.com (Guy Harris)
Message-Id: <9101101938.AA00295@auspex.com>
To:aditya@cs.uh.edu
Subject: Re: Filesystem Compatiblity between 4.0.3->4.1.1
Status: R
>Sun claims that the file systems are compatible. We heard conflicting>reports (from Sun Engineers) about a change in the Super block>structure, etc.
Yes, the superblock format *did* change. Basically, 4.0[.x] uses the
4.3BSD file system, while 4.1[.x] uses the 4.3-tahoe file system; some
fixed-size tables in the 4.3BSD superblock (and possibly elsewhere) were made
variable-size in 4.3-tahoe.
Berkeley's claim is that:
1) a system using the 4.3-tahoe file system should be able to
safely mount either 4.3BSD or 4.3-tahoe file systems
read-write (the 4.3-tahoe code can tell the difference
between the two types of file system, and treats them
differently);
2) a system using the 4.3BSD file system can safely mount
4.3-tahoe file systems read-only, but not read-write, because
it doesn't know how to update the new-style superblock.
There's a field in the 4.3-tahoe superblock that tells what type of file
system the file system is; I'm not sure how the 4.3-tahoe code ensures
that the field in question has a value indicating an old-style
superblock on old-style file systems.
>From eplrx7!mcneill@uunet.UU.NET Fri Jan 11 18:12:09 1991
Received: from eplrx7.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA08976; Thu, 10 Jan 91 09:51:27 -0500
Received: from dude.research.epl by eplrx7 (4.1/SMI-4.0)
id AA19233; Thu, 10 Jan 91 09:49:38 EST
Date: Thu, 10 Jan 91 09:49:38 EST
From: eplrx7!mcneill@uunet.UU.NET (Keith McNeill)
Message-Id: <9101101449.AA19233@eplrx7>
Received: by dude.research.epl (4.1/SMI-4.1)
id AA02080; Thu, 10 Jan 91 09:49:01 EST
To:aditya@cs.uh.edu
Subject: Re: Filesystem Compatiblity between 4.0.3->4.1.1
Status: R
aditya@cs.uh.edu (Aditya Talwar):> Recently we upgraded from SunOS 4.0.3 to 4.1.1. During are preparation we> had read about the upward compatibility of filesystems. This is what> happened. We have a Sun 4/470 with Ciprico Controller (Rimfire Driver),> after upgrading, two of the disks on the controller mounted correctly &> two others failed to mount. Although all four disks did go through fsck> cleanly (done both in boot sequence and manually). We got back on the air> after recreating the filesystem & restoring on the disks.> > Question: Have any of you heard/noticed similar problems with file> systems. Sun claims that the file systems are compatible. We heard> conflicting reports (from Sun Engineers) about a change in the Super block> structure, etc. which causes instantaneous failure (as in our case) or> failure after some elapsed time (aging).> > Please email your replies to me or put it on the net.> > Email:aditya@cs.uh.edu
The problem has to due with tunefs. If you followed the directions in the
Ciprico manual you did a:
tunefs -a 40 ...
after you newfs'd the filesystem when you first installed the ciprico
controller.
The 40 is the maxcontig parameter. 4.1.1 won't allow maxcontig beyond 7. Do
a man on tunefs.
The error message from mount is less than clear as to what the real problem
is. As I remember it only says: I/O error. Both Ciprico & Sun have been
advised of the problem.
I hate to say it but all you had to do was a
tunefs -a 7 /dev/rrfXXX
and your filesystems would have mounted ok.
Keith
Keith D. McNeill | Du Pont Company
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
>Fromwagner@cadillac.siemens.com Thu Jan 10 14:20:32 1991
Received: by siemens.siemens.com (5.54/1.15)
id AA18849; Thu, 10 Jan 91 12:38:56 EST
Received: from leech.siemens.com by cadillac.siemens.com (4.1/SMI-4.0)
id AA21952; Thu, 10 Jan 91 12:33:16 EST
Date: Thu, 10 Jan 91 12:33:16 EST
From:wagner@cadillac.siemens.com (Michael Wagner)
Message-Id: <9101101733.AA21952@cadillac.siemens.com>
Received: by leech.siemens.com (4.1/SMI-4.0)
id AA13229; Thu, 10 Jan 91 12:33:10 EST
To:aditya@cs.uh.edu
Subject: Re: Filesystem Compatiblity between 4.0.3->4.1.1
Newsgroups: comp.sys.sun
References: <1128@brchh104.bnr.ca>
Cc:wagner@cadillac.siemens.com
Status: RO
Check your tunefs parameters and the tunefs(8) man page. We had
the same problem. It seems that Ciprico recommends a maxcontig
value of 40, but mount will only let you mount filesystems with a
value of 7 or less. This is supposedly buried somewhere deep in
the release notes (a quick lookup says page 73), but I missed
this and wasted an hour in search of it and a few more hours
restoring the file systems I needless destroyed thinking they
were trashed. Good Luck!
Michael Wagner
Siemens Corporate Research, Inc.
Princeton, NJ 08540
wagner@cadillac.siemens.com
----- End Included Message -----
