On Sun, Jun 07, 2020 at 12:45:12PM +0100, Patrick Welche wrote: > I had a "/store/backup: bad dir ino 94539430 at offset 512: null entry\n" > panic at 3.40am on a Jun 6 13:54 UTC -current/amd64 box. I assume this > is from a daily run. > > /store/backup is a ffsv2+wapbl on cgd on raidframe
partition mounted on a directory of a zfs filesystem (that's new here) > that was just > filled up with a "dump -0auXf - /olddisk | restore rf -", so it is > the first time daily has seen it. > > Essentially, does that mean there was a problem with olddisk which was > faithfully recreated, or something to worry about? > > (olddisk was the same, and raidctl said it was clean, and fsck was > happy, so it wasn't an emergency copy.) > > > Cheers, > > Patrick > > #2 0xffffffff809a301f in vpanic ( > fmt=0xffffffff80e494a8 "%s: bad dir ino %ju at offset %d: %s\n", > ap=ap@entry=0xffff8b828042e948) at ../../../../kern/subr_prf.c:290 > #3 0xffffffff809a30e3 in panic (fmt=<optimized out>) > at ../../../../kern/subr_prf.c:209 > #4 0xffffffff80923863 in ufs_dirbad (how=<optimized out>, > offset=<optimized out>, ip=0xffffcc15fd939780) > at ../../../../ufs/ufs/ufs_lookup.c:750 > #5 ufs_lookup (v=<optimized out>) at ../../../../ufs/ufs/ufs_lookup.c:530 > #6 0xffffffff809fbe25 in VOP_LOOKUP (dvp=dvp@entry=0xffffcc11259d64c0, > vpp=vpp@entry=0xffff8b828042eb18, cnp=cnp@entry=0xffff8b828042ed88) > at ../../../../kern/vnode_if.c:177 > #7 0xffffffff809e37b3 in lookup_once (state=state@entry=0xffff8b828042ecb0, > searchdir=0xffffcc11259d64c0, > newsearchdir_ret=newsearchdir_ret@entry=0xffff8b828042ebf8, > foundobj_ret=foundobj_ret@entry=0xffff8b828042ec00, > newsearchdir_locked_ret=newsearchdir_locked_ret@entry=0xffff8b828042ebf7) > at ../../../../kern/vfs_lookup.c:1164 > #8 0xffffffff809e469f in namei_oneroot (isnfsd=0, inhibitmagic=0, > neverfollow=0, state=<optimized out>) at > ../../../../kern/vfs_lookup.c:1560 > #9 namei_tryemulroot (state=state@entry=0xffff8b828042ecb0, > neverfollow=neverfollow@entry=0, inhibitmagic=inhibitmagic@entry=0, > isnfsd=isnfsd@entry=0) at ../../../../kern/vfs_lookup.c:1897 > #10 0xffffffff809e644a in namei (ndp=ndp@entry=0xffff8b828042ed38) > at ../../../../kern/vfs_lookup.c:1933 > #11 0xffffffff809ebfd7 in fd_nameiat (fdat=fdat@entry=-100, > ndp=ndp@entry=0xffff8b828042ed38, l=<optimized out>) > at ../../../../kern/vfs_syscalls.c:181 > #12 0xffffffff809f0386 in do_sys_statat (l=<optimized out>, > fdat=fdat@entry=-100, userpath=<optimized out>, nd_flag=nd_flag@entry=0, > sb=sb@entry=0xffff8b828042ede8) at ../../../../kern/vfs_syscalls.c:3158 > #13 0xffffffff809f046f in sys___lstat50 (l=<optimized out>, > uap=0xffff8b828042ef00, retval=<optimized out>) > at ../../../../kern/vfs_syscalls.c:3203 > #14 0xffffffff803d34ac in sy_call (rval=0xffff8b828042eeb0, > uap=0xffff8b828042ef00, l=0xffffcc17ed1d0540, > sy=0xffffffff8106e118 <sysent+10584>) at ../../../../sys/syscallvar.h:65 > #15 sy_invoke (code=441, rval=0xffff8b828042eeb0, uap=0xffff8b828042ef00, > l=0xffffcc17ed1d0540, sy=0xffffffff8106e118 <sysent+10584>) > at ../../../../sys/syscallvar.h:94 > #16 syscall (frame=0xffff8b828042ef00) > at ../../../../arch/x86/x86/syscall.c:138 > #17 0xffffffff8020867d in handle_syscall ()
