Date: Tue, 02 Feb 2021 19:26:51 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Message-ID: <bug-253158-3630-a8Z8X5v2KP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253158-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-253158-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #5 from Kirk McKusick <mckusick@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 hav= e 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 toget= her so that directory-wide operations that stat every file (like `ls -l') or re= ad many files (like `grep *.c') only need to read a minimal number of inode bl= ocks (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 n= ew inode caused .factory to notice and make a copy of the old inode block befo= re 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 f= roze 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 cit= ed 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. --=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-3630-a8Z8X5v2KP>