enabling inode hashes results in kernel panics
gljennjohn at gmail.com
Thu Dec 13 10:39:29 UTC 2018
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.
More information about the freebsd-current