From owner-freebsd-fs@freebsd.org Tue Feb 2 19:26:51 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F8F353B401 for ; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DVZZ324PMz4Svg for ; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 471B153B15A; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 46E3A53B3CB for ; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DVZZ31ThBz4Sn2 for ; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 267D813DCC for ; Tue, 2 Feb 2021 19:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 112JQpMi039540 for ; Tue, 2 Feb 2021 19:26:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 112JQpIg039539 for fs@FreeBSD.org; Tue, 2 Feb 2021 19:26:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253158] Panic: snapacct_ufs2: bad block - Non-suJ mksnap_ffs(8) crash Date: Tue, 02 Feb 2021 19:26:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 19:26:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253158 --- Comment #5 from Kirk McKusick --- (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.=