Repeated ffs_newvnode panic (dup alloc) on one inode

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

Hi,

I had repeated kernel panics (10.99.12 if that matters) on a
supposedly dup inode (on a raidfraime device, if that matters):
panic("%s: dup alloc ino=%" PRId64 [...]")
(https://nxr.netbsd.org/xref/src/sys/ufs/ffs/ffs_vfsops.c#2242 )

With that backtrace:
panic() at vprintf
ffs_newvnode() at ffs_newvnode+0x441
vcache_new() at vcache_new+0x90
ufs_mkdir() at ufs_mkdir+0x6f
VOP_MKDIR() at VOP_MKDIR+0x40
nfsrv_mkdir() at nfsrv_mkdir+0x85c

The kernel would always panic with the same "NNN" inode number, as
soon as something would be writing to the filesystem in
question. After some lengthy 'find -inum' I did confirm that the inode
NNN didn't exist on the filesystem. However, I found some ... NNN-3,
NNN-2, NNN-1 inodes, and touching a file in that directory also
triggered the panic with again the NNN inode number.

Since I needed the filesystem to be operational I moved around those
files a bit until new inodes would be created far away from NNN and
this mitigated the issue so far.

Howver, I was wondering what could be the cause of this (dirty sector
on a disk after a crash?) and how to make sure this won't happen again
by examining the disk? I'm not sure to understand the "if
(ip->i_mode)" that triggers the panic. Does this mean that data read
on the disk is not 0-initialized?

Thanks for any hints!
Cheers,
Anthony