From owner-freebsd-bugs Fri Jul 27 2:30:11 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EDA9937B407 for ; Fri, 27 Jul 2001 02:30:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f6R9U1W58251; Fri, 27 Jul 2001 02:30:01 -0700 (PDT) (envelope-from gnats) Date: Fri, 27 Jul 2001 02:30:01 -0700 (PDT) Message-Id: <200107270930.f6R9U1W58251@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ian Dowse Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Reply-To: Ian Dowse Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR i386/29045; it has been noted by GNATS. From: Ian Dowse To: Bill Moran Cc: freebsd-gnats-submit@freebsd.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Date: Fri, 27 Jul 2001 10:27:47 +0100 In message <200107270010.f6R0A1020956@freefall.freebsd.org>, Bill Moran writes: > My question now is: Is there anything more I can do to help isolate > what really caused this problem? I have a few theories currently: A hex diff of a few examples of file corruption might help suggest a cause. If you can get two copies of what should be the same file but the md5 checksums differ, run hd file.good > file.good.hd hd file.bad > file.bad.hd diff -u file.good.hd file.bad.hd and try to do this with as many examples of corruption as you can find. To get such "good" and "bad" versions of the same file, rerun the md5 checks you tried earlier, and then make copies of any files that are listed as having different checksums. Hopefully this way you can grab a few good and bad versions of the same file. > First, I attempted to establish a way to reliably crash the > machine so I could be sure if/when I fixed it. Unfortunately, The machine will only crash if the data corruption somehow triggers some kernel sanity check. That will be much less likely to occur than the real problem, which is the data corruption itself. The most reliable way to test if the problem is fixed is to run the md5 test while the system is busy. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message