> 	You mentioned decrementing by 8k, in possible relation to some
> disk code. Well, it happens that this one disk (IDE) I was beating on
> rather a lot does in fact have 8k blocks; the other three drives (all SCSI,
> a 340M scsi-1, 540M scsi-2, and zip drive) are all labeled for 4k blocks.
> The IDE drive was the one that had the fsck errors last time.

Well, then it does sound like that could be the cause...


> Do you, offhand, have any suggestions
> as to what I might look for next time it crashes?

nothing that'll really help if all you have at your disposal is ddb.
8-)

basically, look around and see what all is being done with that disk.
also, investigate the buffers that the cluster code is accessing, that
cause it to panic.

The problem is that ddb just isn't sophisticated enough to do real
data structure investigation (assuming finite programmer tolerance for
pain).  oh for remote kgdb on the i386.


You might be able to work around the problem by turning off more
of the clustering code (part of it, block reallocation, is already
turned off by default) frobbing the ISSEQREAD macro to always be zero...

I don't like to encourage workarounds for this sort of problem
because they tend to never actually be fixed properly in the long run,
and they cost performance.  (Previous workarounds for filesystem- and
buffer-related code include turning off block reallocation to avoid
clustering bugs and reducing MAXBSIZE so that i386 kernel vm bogons
aren't triggered.  Both of those are still in place, and both of
those have a non-trivial cost in terms of filesystem I/O performance.)


chris