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