Date: Thu, 13 Dec 2018 10:47:13 +0100 From: Gary Jennejohn <gljennjohn@gmail.com> To: freebsd-current@freebsd.org Subject: enabling inode hashes results in kernel panics Message-ID: <20181213104713.02a14912@ernst.home>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181213104713.02a14912>