Hello Some times ago, I encountered this nasty bug where the kernel would crash when mounting a filesystem with snapshots. I thought it was fixed, but it seems there are some problems leftover, at least on netbsd-8.
The crash: /mail: replaying log to disk ffs_snapshot_mount: vget failed 2 panic: ffs_snapshot_mount: 211471882 already on list fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 0xffffffff8021fe95 cs 0x8 rflags 0x246 cr2 0x72ef770d7700 ilevel 0 rsp 0xffff80090868eb40 curlwp 0xfffffe90f4689100 pid 76.1 lowest kstack 0xffff80090868c2c0 Stopped in pid 76.1 (mount_ffs) at netbsd:breakpoint+0x5: leave vpanic() at netbsd:vpanic+0x15d snprintf() at netbsd:snprintf ffs_snapshot_mount() at netbsd:ffs_snapshot_mount+0x371 ffs_mountfs() at netbsd:ffs_mountfs+0xafc ffs_mount() at netbsd:ffs_mount+0x579 VFS_MOUNT() at netbsd:VFS_MOUNT+0x4d mount_domount() at netbsd:mount_domount+0x122 do_sys_mount() at netbsd:do_sys_mount+0x2b0 sys___mount50() at netbsd:sys___mount50+0x33 syscall() at netbsd:syscall+0x1ec --- syscall (number 410) --- Then I booted of my kernel with snapshots disabled to cleanup inode 211471882. The rm caused a crash: panic: ffs_blkfree_common: freeing free block: dev = 0xa807, block = 115955440, fs = /mail fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 0xffffffff8021fe95 cs 0x8 rflags 0x246 cr2 0 ilevel 0 rsp 0xffff800908672810 curlwp 0xfffffe910b018080 pid 10.1 lowest kstack 0xffff8009086702c0 Stopped in pid 10.1 (rm) at netbsd:breakpoint+0x5: leave breakpoint(0,fffffea05fb0d000,ffff8009418d9788,ffff8009418d8000,ffff8009086728a0 ,ffffffff8096f568) at netbsd:breakpoint+0x5 vpanic(0,fffffe9100000028,ffff8009086728b0,ffff800908672870,177e06d40,ffffffff81 03f370) at netbsd:vpanic+0x15d snprintf(a807,ffffffff809a6b7a,6e956f0,fffffe90f7c1f690,8c50,6e956f0) at netbsd: snprintf ffs_blkfree_common(0,6e956f0,8000,fffffe90f7c1f600,a807,3808bf3b7) at netbsd:ffs _blkfree_common+0x3d7 ffs_blkfree_cg(0,fffffe90faba2800,0,ffffffffffffffff,0,40) at netbsd:ffs_blkfree _cg+0x131 ffs_indirtrunc(0,fffffe90faba2800,0,ffffffffffffffff,0,40) at netbsd:ffs_indirtr unc+0x47f ffs_indirtrunc(0,fffffe90faba2800,1,ffffffffffffffff,0,40) at netbsd:ffs_indirtr unc+0x1fb ffs_indirtrunc(2,2,40,0,c,10) at netbsd:ffs_indirtrunc+0x1fb ffs_truncate(0,235fb117e8,ffff800908672d60,fffffea05fac9b00,fffffea05fb11548,fff ffea05fb1156c) at netbsd:ffs_truncate+0xbac ufs_truncate_retry(10,fffffea05fb11548,ffff800908672de0,fffffea05fb11548,1,fffff ea05fb1156c) at netbsd:ufs_truncate_retry+0x92 ufs_inactive(20012,fffffea05fb11548,ffff800908672eb0,ffffffff81058e40,fffffea05f b11548,ffff800908672e1f) at netbsd:ufs_inactive+0x25a VOP_INACTIVE(fffffea05fb11548,ffffff809bbd91,fffffea05fb11548,fffffea05fb117e8,ffff800908672eb0,0) at netbsd:VOP_INACTIVE+0x4c vrelel(fffffea05fac9d00,fffffea05fac9b00,ffff800908672ec0,fffffea05fb117e8,0,fff ffe9100054000) at netbsd:vrelel+0x168 ufs_remove(0,fffffe9100054000,ffffffff810590a0,fffffea05fb117e8,fffffea05fb11548 ,ffff800908672f48) at netbsd:ufs_remove+0xab VOP_REMOVE(fffffea05f8ed008,0,fffffea05f8ed008,fffffe9100054400,fffffe90f90bad28 ,0) at netbsd:VOP_REMOVE+0x50 do_sys_unlinkat.isra.5(ffffffff81400600,ffff800908672fb0,0,0,ffffffff80922368,7f 7ffffa3373) at netbsd:do_sys_unlinkat.isra.5+0x1eb syscall() at netbsd:syscall+0x1ec --- syscall (number 10) --- 7966dd4fb1fa: After another reboot, I ran fsck on the fileystem, inode 211471882 indeed as troubles: ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=211471881 (31466368 should be 31466624) CORRECT? yes 845563840 DUP I=211471882 845563841 DUP I=211471882 845563842 DUP I=211471882 845563843 DUP I=211471882 845563844 DUP I=211471882 845563845 DUP I=211471882 845563846 DUP I=211471882 845563847 DUP I=211471882 INCORRECT BLOCK COUNT I=211471882 (11141696 should be 11142208) CORRECT? yes -- Emmanuel Dreyfus [email protected]
