Date: Mon, 01 Feb 2021 12:55:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Message-ID: <bug-253158-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 Bug ID: 253158 Summary: Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: bugzilla.freebsd@omnilan.de Hello, sorry for missing the patch and/or helpful code/debug links, but I want at least to record my long standing problem, which I haven't found time to sta= rt with before... I'm using "factory" ufs-snapshots since FreeBSD 8ish for almost all my deployments. Starting with 10, I'm observing crashes which I couldn't ever reproduce (be= low is a oneliner doing exactly what _should_ trigger the crash, but doesn't). But since the crashes have been guaratneed to show up for several years now= , I salvaged such a filessystem, which makes it possible to reproduce the crash. It's a mdimage(4) of a 36GB root memory disk, compressed 10G in size: http://www.omnilan.de/downloads/fs_slash.gz As soon as I utilize mksnap_ffs(8) on that md(4), (gunzip -c fs_slash.gz > /tmp/fs_slash mdconfig -a -t vnode -f /tmp/fs_slash mount /dev/md0 /mnt # to be adopted mksnap_ffs /mnt/.snap/.test ) I get the following kernel panic: panic: snapacct_ufs2: bad block cpuid =3D 3 time =3D 1612183847 KDB: stack backtrace: #0 0xffffffff80c515c5 at kdb_backtrace+0x65 #1 0xffffffff80c04251 at vpanic+0x181 #2 0xffffffff80c040c3 at panic+0x43 #3 0xffffffff80e86ab4 at snapacct_ufs2+0x164 #4 0xffffffff80e8998c at indiracct_ufs2+0x21c #5 0xffffffff80e86283 at expunge_ufs2+0x3a3 #6 0xffffffff80e84c51 at ffs_snapshot+0x2061 #7 0xffffffff80eac94c at ffs_mount+0x128c #8 0xffffffff80cd4c3d at vfs_domount+0x8bd #9 0xffffffff80cd3b87 at vfs_donmount+0x8e7 #10 0xffffffff80cd3269 at sys_nmount+0x69 #11 0xffffffff81038b3c at amd64_syscall+0x10c #12 0xffffffff8100f1fe at fast_syscall_common+0xf8 -------- Here's the description/test for what I essentially do at setup time, which leads to filesystems causing the mksnap_ffs(8) crash when e.g. FreeBSD boot= s up and runs background fsck(8) - which required a snaphshot, which crashes the machine... 1. Create a file with known size to fit content (this example exactly corresponds to the size of the known-bad fs_slash linked above # actually I'm using dd if=3D/dev/null instead of truncate(1) as used in th= e test loop) 2. newfs without SoftUpdates and/or Journaling, just use a label 3. Mount md(4) and copy content for pre-calculated size 4. do snapshot of the filesystem, move the snap inode, create hard link to = it as well as a symlink to the hardlink 5. umount - as done with real setup 6. additional test: re-mount, make another snapshot - that's where the realworld crash happens on about any 10-20th rollout 7. cleanup =3D=3D sh -c 'count=3D0; oldpwd=3D"$(pwd)"; while [ $count -lt 50 ]; do mdun=3D`tr= uncate -s 37312k /tmp/snaptest && mdconfig -n -a -t vnode -f /tmp/snaptest` ; newfs -L mksnapFFS -n -E /dev/md${mdun} && mount /dev/md${mdun} /mnt && find -x / \! -type d -flags nosnapshot | cpio -pmdu /mnt && mksnap_ffs /mnt/.snap/.test = && cd /mnt && { [ -d usr ] || mkdir usr ; } && mv .snap/.test usr && ln usr/.t= est .snap/.test && ln -s .test .snap/$(stat -f"%i %B %v test" /mnt/.snap/.test | sha1) && cd "${oldpwd}" && echo Successfull: $((count +=3D 1)) ; umount /mn= t ; mdconfig -d -u ${mdun} ; done' --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253158-227>