Date: Sat, 27 Oct 2001 21:00:02 -0700 (PDT) From: Bill Moran <wmoran@iowna.com> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Message-ID: <200110280400.f9S402U77311@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: Bill Moran <wmoran@iowna.com>
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree
Date: Sat, 27 Oct 2001 23:56:00 -0400
I finally managed to find some time to look into this again, but I
have no idea what to make of the results.
Ian Dowse wrote:
> In message <200107270010.f6R0A1020956@freefall.freebsd.org>, Bill Moran writes:
>
> 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
I reconnected the 80 conductor cable earlier today, and intentionally
recreated the problem so that I could do the hex diff procedure you
describe. Here's what happened:
1. Did a find | md5 like you described in previous messages
2. Started a "make world" process and then started another find | md5
running simultaneously.
3. Once I had two files full of md5 checksums, I ran a diff to find
out what files had become victums of corruption.
4. I used the diff to pick files to run the hex dump on. I had original
files on another server, safe from any possible corruption.
The problem is: no differences were found between the two files. Put in
plain english, I have two files that *should* be identical, but the md5
checksums differ, however, the hd/diff procedure above shows no differences.
I can only assume that the disk corruption is such that under some
circumstances the files appear currupted, but under other circumstances,
the correct data for the file is available.
I would still like to isolate this, but I don't know what else to try.
How do I identify the corruption if it's transient? I guess the first
thing would be to determine under what conditions the garbled data appears?
--
"Where's the robot to pat you on the back?"
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?200110280400.f9S402U77311>