enabling inode hashes results in kernel panics

[Gary Jennejohn]

I just had two panics as a result of enabling inode hashes on a
file system yesterday when I had to run fsck on it.

The filesystem showed no problems at all yesterday, the problem
didn't appear until I accessed it today.

NOTE that my fsck was installed from r341840 yesterday morning,
so it should be up-to-date.  My kernel is also at r341840.

I have run fsck on this filesystem six times.  Although fsck
claims to have repaired the inode-check hash every time, it in
reality has not repaired anything.  I know this because, after
the first two fsck runs, I mounted the filesystem.  Accessing it
resulted in a immediate panic (the second of the two).

The file system is located on a SSD with trim enabled.  Whether
that is relevant I cannot say, but this is the ONLY filesystem
with inode hashes enabled.

The inodes are all contiguous, from 122229888 thorugh 122229904. 
Strangely, MTIME=Sep 6 23:21 2002 on every one of them, but the
SSD itslef is only a month old and the files on it only a few
weeks old.

The panic message is
	Inode 122229888: check-hash failed
	panic: softdep_update_inodeblock: bad link count

It almost appears like the softdep code in the kernel is not
aware of inode hashes and gets confused.

I have the crash dumps and the core.txt files.

It doesn't appear that I can disable the hashes using tunefs, so
my only remedy will be to run fsdb and clear these inodes and lose
quite a few rather large files.

-- 
Gary Jennejohn