[Bug 271292] kernel panic while dd'ing a USB disk to a ZFS directory

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

--- Comment #17 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to dgilbert from comment #15)

Looking at the zfs source it appears that
( in openzfs/module/zcommon/zfeature_common.c )
the following means that, sort of special code
changed like the temporary sysctl for block
cloning, FreeBSD gets all features as soon as they
are imported:

static boolean_t
zfs_mod_supported_feature(const char *name,
    const struct zfs_mod_supported_features *sfeatures)
{
        /*
         * The zfs module spa_feature_table[], whether in-kernel or in
         * libzpool, always supports all the features. libzfs needs to
         * query the running module, via sysfs, to determine which
         * features are supported.
         *
         * The equivalent _can_ be done on FreeBSD by way of the sysctl
         * tree, but this has not been done yet.  Therefore, we return
         * that all features are supported.
         */

#if defined(_KERNEL) || defined(LIB_ZPOOL_BUILD) || defined(__FreeBSD__)
        (void) name, (void) sfeatures;
        return (B_TRUE);
#else
        return (zfs_mod_supported(ZFS_SYSFS_POOL_FEATURES, name, sfeatures));
#endif
}

This means I'm confused about how/why edonr's status has long
been not listed in the likes of the openzfs-2.*-freebsd files,
but is listed for the openzfs-2.*-linux files:

# diff /usr/share/zfs/compatibility.d/openzfs-2.1-*
1c1
< # Features supported by OpenZFS 2.1 on FreeBSD
---
> # Features supported by OpenZFS 2.1 on Linux
9a10
> edonr
amd64_ZFS amd64  1400088 1400088 # diff
/usr/share/zfs/compatibility.d/openzfs-2.0-*
1c1
< # Features supported by OpenZFS 2.0 on FreeBSD
---
> # Features supported by OpenZFS 2.0 on Linux
8a9
> edonr

Despite edonr in those files, it looks to me like:

zilsaxattr "active"
head_errlog "active"

have been handled in main's kernel well before your
Feb-13 time frame. But that still leaves:

block_cloning "active"

So, if I understand right, you would end up with just
Read-Only status for the pool for a kernel from
around Feb-13.

I've not investigated the loader for back then but
I'd expect that using a more modern loader would deal
with any issue there (if it even is a boot pool).

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