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/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253158 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 start 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 (below 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 = 3 time = 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 boots 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=/dev/null instead of truncate(1) as used in the 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 == sh -c 'count=0; oldpwd="$(pwd)"; while [ $count -lt 50 ]; do mdun=`truncate -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/.test .snap/.test && ln -s .test .snap/$(stat -f"%i %B %v test" /mnt/.snap/.test | sha1) && cd "${oldpwd}" && echo Successfull: $((count += 1)) ; umount /mnt ; mdconfig -d -u ${mdun} ; done' -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253158-227>