Date: Fri, 27 Jul 2001 02:30:01 -0700 (PDT) From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Message-ID: <200107270930.f6R9U1W58251@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/29045; it has been noted by GNATS. From: Ian Dowse <iedowse@maths.tcd.ie> To: Bill Moran <wmoran@iowna.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107270930.f6R9U1W58251>