From owner-freebsd-hackers Thu Oct 31 06:36:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA10453 for hackers-outgoing; Thu, 31 Oct 1996 06:36:06 -0800 (PST) Received: from nevis.oss.uswest.net (nevis.oss.uswest.net [204.147.85.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA10444 for ; Thu, 31 Oct 1996 06:36:04 -0800 (PST) Received: (from greg@localhost) by nevis.oss.uswest.net (8.6.12/8.6.12) id IAA25215; Thu, 31 Oct 1996 08:35:32 -0600 From: "Greg Rowe" Message-Id: <9610310835.ZM25213@nevis.oss.uswest.net> Date: Thu, 31 Oct 1996 08:35:32 -0600 In-Reply-To: Thomas David Rivers "Another data point in the daily panics..." (Oct 30, 6:57pm) References: <199610302357.SAA07583@lakes.water.net> X-Mailer: Z-Mail (3.2.1 10oct95) To: freebsd-hackers@freefall.freebsd.org, Thomas David Rivers Subject: Re: Another data point in the daily panics... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have a number of News systems running 2.1.5 Release with absolutely no problems. These systems range from anywhere between 8 and 20 gig of News spool space. They all run INN and CCD. These systems are "rock solid". The difference is that the hardware is all custom built based on advice found in these mailing lists. If your serious about running a "production" FreeBSD server, don't skimp on the hardware. Do some mailing list searches and find out what motherboard, controllers, and drives work best for your application. Your hardware is probably not what most folks on this list would consider using for a News server based on the load the application places on the system. Greg On Oct 30, 6:57pm, Thomas David Rivers wrote: > Subject: Another data point in the daily panics... > > Ok > > I'm just now cleaning up from last night's panic on my 2.1.5 > (now STABLE, not RELEASE) system. > > Recall, this is a 386DX-33, 8MEG, IDE controller, sio ports, running > my news and mail and SL/IP connections. > > Last night's panic wiped out my /usr/lib/news directory (I run > an old version of Cnews...) - so I had to reconstruct all of this > from backups and files gleaned from /usr/lost+found. (I'm painfully > rebuilding the history file as I type this... :-) ) > > Some items of interest: > > 1) I had to run fsck 3 times before getting a clean disk, > each time it discovered more dangling files to put > in lost+found. > > 2) The panic this time was not doubly free'ing of an > inode. I haven't seen this since I installed 2.1.5-S. > This time it was "panic: bad dir". > > 3) I've seen similar occurrences on IDE and SCSI (aha1542B) > drives, so I'm reluctant to call this a hardware/disk drive > problem - but it's possible... > > 4) By judicious choice of newfs parms, I can reproduce the > "free" panic during an install of 2.1.5-R (and 2.1.0) > with different hardware... [Scan the 2.1.0 mail logs > for a Subject: "panic: fs dup alloc" to see my previous > report...] > > > Is there no-one else who's ever seen panics like this? > > I would think that some ISP running a news system has got to run into > these types of problems... > > That's what makes me think it's my newfs parms.... perhaps I'm the > only person to set up "weird" ones that tickle this problem... [I could > be on a totally wrong track here - but it's the only similar item > between the IDE and SCSI configurations, besides the kernel...] > > Anyway, just for information's sake - here's the output of newfs -N, > the disklabel, the first part of a dumpfs. > > If anyone has a suggestion of where to look, or how to proceed, I'd > greatly appreciate it... > > ----------------- newfs -N /dev/rwd0s1e ----------------- > Warning: 3488 sector(s) in last cylinder unallocated > /dev/rwd0s1e: 2568800 sectors in 628 cylinders of 1 tracks, 4096 sectors > 1254.3MB in 40 cyl groups (16 c/g, 32.00MB/g, 7680 i/g) > super-block backups (for fsck -b #) at: > 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, > 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, > 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, > 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, > 2293792, 2359328, 2424864, 2490400, 2555936, > > ----------------- disklabel -r /dev/wd0c ---------------- > > # /dev/wd0c: > type: ESDI > disk: wd0s1 > label: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 16 > sectors/cylinder: 1008 > cylinders: 3157 > sectors/unit: 3183201 > rpm: 3600 > interleave: 1 > trackskew: 0 > cylinderskew: 0 > headswitch: 0 # milliseconds > track-to-track seek: 0 # milliseconds > drivedata: 0 > > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 307200 0 4.2BSD 0 0 0 # (Cyl. 0 - 304*) > b: 307200 307200 swap # (Cyl. 304*- 609*) > c: 3183201 0 unused 0 0 # (Cyl. 0 - 3157*) > e: 2568801 614400 4.2BSD 0 0 0 # (Cyl. 609*- 3157*) > > ----------------- first part of dumpfs -------------------------- > magic 11954 time Wed Oct 30 17:17:57 1996 > cylgrp dynamic inodes 4.4BSD > nbfree 99103 ndir 7926 nifree 1102441 nffree 1194 > ncg 57 ncyl 627 size 1284096 blocks 1137247 > bsize 8192 shift 13 mask 0xffffe000 > fsize 1024 shift 10 mask 0xfffffc00 > frag 8 shift 3 fsbtodb 1 > cpg 11 bpg 2816 fpg 22528 ipg 20480 > minfree 8% optim time maxcontig 7 maxbpg 2048 > rotdelay 0ms headswitch 0us trackseek 0us rps 60 > ntrak 1 nsect 4096 npsect 4096 spc 4096 > symlinklen 60 trackskew 0 interleave 1 contigsumsize 7 > nindir 2048 inopb 64 nspf 2 > sblkno 16 cblkno 24 iblkno 32 dblkno 2592 > sbsize 2048 cgsize 6144 cgoffset 2048 cgmask 0xffffffff > csaddr 2592 cssize 1024 shift 9 mask 0xfffffe00 > cgrotor 56 fmod 0 ronly 0 clean 1 > (no rotational position table) > > cs[].cs_(nbfree,ndir,nifree,nffree): > > ... > > > > - Dave Rivers - > >-- End of excerpt from Thomas David Rivers -- Greg Rowe | U S West - Interact Services | INTERNET greg@uswest.net 111 Washington Ave. South | Fax: (612) 672-8537 Minneapolis, MN USA 55401 | Voice: (612) 672-8535 Never trust an operating system you don't have source for....