[Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253158

--- Comment #5 from Kirk McKusick <mckusick at FreeBSD.org> ---
(In reply to Harald Schmalzbauer from comment #4)
Thanks for testing. Once I figured it out, the fix seemed obvious. But that is
not always the case, so glad it worked out. It is especially helpful to have a
reliable way to identify problems and confirm their solution.

The panic arose when the inode allocated for the snapshot came from an inode
block not previously used for snapshots.

The filesystem tries to cluster the inodes in a directory to be close together
so that directory-wide operations that stat every file (like `ls -l') or read
many files (like `grep *.c') only need to read a minimal number of inode blocks
(each 32K disk block holds 128 inodes).  If all of the snapshots are taken in
/.snap, then they will typically all be allocated from the same inode block.

You filled your filesystem full enough that there were no more locally
available inodes (`ls -i /mnt/.snap' shows .factory as inode 4114 while the new
snapshot got inode 2830 which is more than 128 inodes away). Writing that new
inode caused .factory to notice and make a copy of the old inode block before
allowing it to be changed.

To make a copy .factory needed to allocate a block in which to put it.  That
new block got allocated between the time that the new snapshot allocation froze
the filesystem and was making a pass over the block maps to create its own
frozen image. The panic occurred because the code had assumed that no new
blocks could be allocated. That was true except in the rare case I just cited
above. So, the fix was to accept that there are legitimate cases where other
snapshots can allocate blocks when the filesystem is frozen.

Not sure if that qualifies as a simple explanation.

-- 
You are receiving this mail because:
You are the assignee for the bug.