Re: enabling inode hashes results in kernel panics

On Thu, 13 Dec 2018 10:47:13 +0100
Gary Jennejohn <gljennjohn_at_gmail.com> wrote:

> 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.
> 

I ran fsdb on every affected inode and allowed it to correct
the inode hashes.

After that, fsck no longer found any errors and I was able to
mount and access the filesystem without a kernel panic.

So, it would appear that fsdb really does correct inode hash
errors, whereas fsck does not.

-- 
Gary Jennejohn