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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
