Well folks,
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
aditya@cs.uh.edu
----- Begin Included Message -----
>From mcneill%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
To: mark@gest20.sinet.slb.com
Subject: Re: 4.1.1 upgrade and ciprico
Mark@Gest20.Sinet.Slb.Com:
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 -----
>From aditya@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 for mark@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
>From wagner@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 -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:11 CDT