Date: Wed, 22 Jan 1997 23:04:09 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: 2.1.6.1 freeing free inode panic... (nightly panics) Message-ID: <199701230404.XAA07877@lakes.water.net>
next in thread | raw e-mail | index | archive | help
I've received a couple of interesting replies this go-'round on the panic. If you're interested in previous discussions; look through the mail archive for "nightly panics." Several people have suggested that fsck could be the culprit. In that, fsck is not catching some terrible file system inconsistency. such that when a file system gets into this state, it's stuck there. [A newfs and restore, of course, fixes.] I would submit that the bug is that the file system gets into that state to begin with.... granted; fsck (possibly) could do something with it - but there should be no reason (barring hardware faults, stray gamma rays, etc...) for the file system to be corrupted this way - much less for it to panic the machine. So, I'm willing to believe this is a situation unexamined by fsck because it's not supposed to happen. I'm also willing to believe that "it's not supposed to happen" is a contributing cause in the panic (sorta an obvious statement; that's what panic() means :-) ) Jaye Mathisen writes: > I have several servers that once I get this error one time, I can count on > getting it again, unless I newfs, and restore the FS. I would say that my experience echoes his. It seems that building a new file system eliminates the problem - for a short time; and once it's returned, it's there for good. Is it possible there's a boundary condition in "isclr" - such that bits around, say a word boundary; are not checked [this would presumably be a compiler bug, as isclr() is a pretty straightforward macro - see /usr/include/sys/param.h.] I'm not sure it's worth examining at 2.1.6.1; as I believe 2.2 is quite different in this area. But, if anyone has any suggestions, please don't hesitate to come forward with possibilities to examine [I've read through ffs_alloc.c; seems reasonable to me.] A quick/reliable reproduction of the problem would go a long way toward solving it.... - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701230404.XAA07877>