NetBSD Problem Report #60621

From www@netbsd.org  Thu Aug 20 03:36:01 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C65951A923B
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 20 Aug 2026 03:36:00 +0000 (UTC)
Message-Id: <20260820033559.5C8BC1A923C@mollari.NetBSD.org>
Date: Thu, 20 Aug 2026 03:35:59 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: panic: ufs_inactive: dirty filesystem?
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60621
>Category:       kern
>Synopsis:       panic: ufs_inactive: dirty filesystem?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 20 03:40:00 +0000 2026
>Originator:     Taylor R Campbell
>Release:        10.1
>Organization:
The NetBSD Foundation, Inc.
>Environment:
NetBSD bester.NetBSD.org 10.1 NetBSD 10.1 (WWUSERVER) #0: Wed Dec 18 12:03:42 UTC 2024  spz@franklin.NetBSD.org:/home/netbsd/10/amd64/obj/sys/arch/amd64/compile/WWUSERVER amd64
>Description:

Wed Aug 19 15:35:20 UTC 2026
Starting root file system check:
/dev/rraid0a: file system is journaled; not checking
[  10.9232881] /: replaying log to disk
[  22.7101747] ufs_inactive: unlinked ino 61 on "/" has non zero size 0 or blocks fffffffffffffec0 with allerror 0
[  22.7201807] panic: ufs_inactive: dirty filesystem?
[  22.7301867] cpu3: Begin traceback...
[  22.7301867] vpanic() at netbsd:vpanic+0x183
[  22.7301867] panic() at netbsd:panic+0x3c
[  22.7401925] ufs_inactive() at netbsd:ufs_inactive+0x167
[  22.7501979] VOP_INACTIVE() at netbsd:VOP_INACTIVE+0x3c
[  22.7501979] vrelel() at netbsd:vrelel+0x154
[  22.7602037] ffs_wapbl_replay_finish() at netbsd:ffs_wapbl_replay_finish+0x35
[  22.7602037] ffs_wapbl_start() at netbsd:ffs_wapbl_start+0x4b
[  22.7702094] ffs_mount() at netbsd:ffs_mount+0x553
[  22.7702094] VFS_MOUNT() at netbsd:VFS_MOUNT+0x5a
[  22.7802154] do_sys_mount() at netbsd:do_sys_mount+0x3ac
[  22.7902217] sys___mount50() at netbsd:sys___mount50+0x33
[  22.7902217] syscall() at netbsd:syscall+0x1fc
[  22.8002275] --- syscall (number 410) ---
[  22.8002275] netbsd:syscall+0x1fc:
[  22.8002275] cpu3: End traceback...

>How-To-Repeat:

	1. take and unlink an fss ffs fs-internal snapshot
	   (say that five times fast!)
	2. create a couple very large files (~70GB), not sparse
	3. rm the very large files
	4. trip over wapbl_flush: current transaction too big to flush
	   (PR kern/54504: -9/-current WAPBL panic: current transaction
	   too big to flush, https://gnats.NetBSD.org/54504)
	5. reboot

	Not 100% sure the snapshot part is necessary -- perhaps keeping
	any unlinked file open during sudden interruption (panic, power
	loss, &c.) is enough.

	The ffs wapbl replay logic seems to be unable to cope with the
	resulting non-truncated unlinked file.

>Fix:

	Yes, please!  And a test case too.

	I'm not clear on why the inode in question is being processed
	by ffs_wapbl_replay_finish.

	That means it is listed in a WAPBL_WC_INODES record, i.e., it
	has been registered with wapbl_register_inode as a partially
	allocated inode, which shouldn't be in use by anything else
	yet; surely, if the inode allocation had completed, as I
	suspect it had (since fssconfig(8) completed and I think --
	though I'm not sure -- that the snapshot was even mounted),
	then we should have passed through wapbl_unregister_inode.

	But maybe there's some path that bypasses
	wapbl_unregister_inode incorrectly under certain circumstances,
	or somehow the complete inode allocation got committed in a
	separate transaction from wapbl_unregister_inode.

Home	PR Database Search