Date: Fri, 16 Jan 1998 04:13:03 -0800 From: Julian Elischer <julian@whistle.com> To: hackers@FreeBSD.ORG Subject: The 'dave rivers' momorial panic. Message-ID: <34BF4ECF.167EB0E7@whistle.com>
next in thread | raw e-mail | index | archive | help
I've gone some considerable distance towards tracking down a crash
that seems to resemble the problem dave's been seeing.
Basically, a particular setup (running on several
pieces of hardware) is incapable of doing a full news expire,
We've managed to simplify the case down to a reproducible test, that
involves copying the contents of one disk to a newly newfs'd
partition on another.
The exact symptom that we see is that bits in the cylinder group
bitmap get set by "something" after the cg has bee queued for write.
adding a test confirms that everything is alright immediatly before
the write, but the next time the cg is accessed, there are some extra
bits set. The changes are present on the disk.
It's not hardware.. we've changed everything, but it's reproducible.
with this particular setup..
<hmmmm> the more I write here the more it sounds like flaky hardware..
<\hmmmmm> but the patterns seen on disk do not
act like hardware..
it looks like a reallocation..
some file or more likely, directory, is extended,
and the cg summary info is never updated, though the
bitmaps are..
so the question is:
does anyone know of any 'covert' paths where the cg structs
(including bitmaps) are accessed other than in ffs_alloc.c?
I'd love to be able to mark the pages concerned 'read-only' when I queue
them for write. that'd catch the other writer,, :)
anyone have any ideas on how I'd do that for a bdwrite(bp)?
julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34BF4ECF.167EB0E7>