[Bug 268333] reboot: clearing /tmp: kernel panic: ZFS ; VERIFY3(0 == zap_add_int(zfsvfs->z_os, zfsvfs->z_unlinkedobj, zp->z_id, tx)) failed (0 == 97)

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 13 Dec 2022 02:11:46 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268333

Graham Perrin <grahamperrin@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/openzfso
                   |                            |nosx/zfs/issues/313
            Summary|kernel panic during boot ;  |reboot: clearing /tmp:
                   |ZFS ; VERIFY3(0 ==          |kernel panic: ZFS ;
                   |zap_add_int(zfsvfs->z_os,   |VERIFY3(0 ==
                   |zfsvfs->z_unlinkedobj,      |zap_add_int(zfsvfs->z_os,
                   |zp->z_id, tx)) failed (0 == |zfsvfs->z_unlinkedobj,
                   |97)                         |zp->z_id, tx)) failed (0 ==
                   |                            |97)
           Keywords|                            |crash
                URL|                            |https://codeberg.org/FreeBS
                   |                            |D/freebsd-src/src/branch/re
                   |                            |leng/13.1/sys/contrib/openz
                   |                            |fs/module/os/freebsd/zfs/zf
                   |                            |s_dir.c#L256-L281

--- Comment #2 from Graham Perrin <grahamperrin@freebsd.org> ---
> zap_add_int(zfsvfs->z_os, zfsvfs->z_unlinkedobj, zp->z_id, tx

Google finds this, from OpenZFS on OS X in 2015, closed but non-conclusive: 

<https://github.com/openzfsonosx/zfs/issues/313#issuecomment-102804769>

* a backtrace, but no address-to-symbol translation

<https://github.com/openzfsonosx/zfs/issues/313#issuecomment-102834366>

* two more panics, no backtraces.

Whilst the matches are remarkable (I'll add the issue (see also)), I doubt that
it helps to progress things here. 

----

martin, when was the pool last scrubbed (and free from error at the finish)? 

I assume that boot following the panic did succeed. Can you now scrub the
affected pool? 

zdb(8) might be more useful, but a scrub should be simple enough for starters. 

<https://openzfs.github.io/openzfs-docs/man/8/zdb.8.html>

Is the data backed up?

Can you describe the hardware? The storage media, in particular (HDD, SSHD, or
solid state; and so on).


(In reply to martin from comment #0)

> during boot

Given lines #0–#13 (below the nine-line stack backtrace), I'll tentatively edit
the summary line here. 

How exactly did you perform the restart? Through the GUI of a desktop
environment, or at the command line? 

/usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_dir.c:278 in this case
(kernel 13.1-RELEASE-p3) is
<https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_dir.c?h=releng%2F13.1#n278>
(in the midst of
<https://github.com/freebsd/freebsd-src/blob/releng/13.1/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_dir.c#L256-L281>
|
<https://codeberg.org/FreeBSD/freebsd-src/src/branch/releng/13.1/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_dir.c#L256-L281>).

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