Skip to content

Recieving a stream with the large microzap feature flag is not properly recordedΒ #18143

Closed

Description

@AustinWise

System information

Type Version/Name
Distribution Name Ubuntu
Distribution Version 25.10
Kernel Version 6.17.0-8-generic
Architecture x86_64
OpenZFS Version zfs-2.3.4-1ubuntu2 , zfs-kmod-2.3.4-1ubuntu2

Describe the problem you're observing

When receiving a stream with the large microzap feature is enabled, the activation is not properly recorded. There are two distinct issues:

  • The in-memory status of the feature is not recorded. This causes sends of the received dataset to not included the large microzap feature flag.
  • The feature can attempt to be activated multiple times, causing a panic.

Describe how to reproduce the problem

echo 1048576 >> /sys/module/zfs/parameters/zap_micro_max_size
dd if=/dev/zero of=./test.zfs bs=1M count=128
zpool create test `pwd`/test.zfs
zpool set feature@large_microzap=enabled test

zpool get feature@large_microzap test
zfs create test/src
cd /test/src
seq 1 4096 | xargs touch

zfs snap test/src@snap
zfs send -L test/src@snap | zfs recv test/dest
# The feature is not recorded as active in the test/third's dataset extensions
zfs send -L test/dest@snap | zfs recv test/third

# sync so we can inspect the on disk structures
zpool sync test

zfs snap test/src@second
# The receive panics
zfs send -L -i test/src@snap test/src@second | zfs recv -F test/dest

I was not sure how to inspect the dataset extensions for test/third using zdb. I instead used my c# program to dump them and verify the large dataset feature was not activated.

Include any warning/errors/backtraces from the system logs

VERIFY0(zap_add(mos, dsobj, spa_feature_table[f].fi_guid, sizeof (zero), 1, &zero, tx)) failed (17)
PANIC at dsl_dataset.c:1139:dsl_dataset_activate_feature()
Showing stack for process 3101
CPU: 24 UID: 0 PID: 3101 Comm: txg_sync Tainted: P           OE      6.14.0-37-generic #37~24.04.1-Ubuntu
Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x76/0xa0
 dump_stack+0x10/0x20
 spl_dumpstack+0x28/0x40 [spl]
 spl_panic+0xfc/0x120 [spl]
 ? zap_add+0x83/0xc0 [zfs]
 dsl_dataset_activate_feature+0x1a9/0x290 [zfs]
 dsl_dataset_clone_swap_sync_impl+0x9cd/0xf40 [zfs]
 ? dmu_buf_rele+0x3a/0x50 [zfs]
 ? dsl_dir_rele+0x31/0x40 [zfs]
 dmu_recv_end_sync+0x274/0x5d0 [zfs]
 dsl_sync_task_sync+0xb8/0x110 [zfs]
 dsl_pool_sync+0x3ca/0x4e0 [zfs]
 spa_sync+0x421/0xda0 [zfs]
 ? spa_txg_history_set.part.0+0xb1/0x110 [zfs]
 ? spa_txg_history_init_io+0x120/0x130 [zfs]
 txg_sync_thread+0x20a/0x3b0 [zfs]
 ? __pfx_txg_sync_thread+0x10/0x10 [zfs]
 ? __pfx_thread_generic_wrapper+0x10/0x10 [spl]
 thread_generic_wrapper+0x5e/0x70 [spl]
 kthread+0xfe/0x230
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x47/0x70
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Activity

  1. added a commit that references this issue on Feb 5, 2026
    4f180e0
  2. added a commit that references this issue on Feb 17, 2026
    612d401
  3. added a commit that references this issue on Jul 30, 2026
    1fb5d62
  4. added a commit that references this issue on Aug 5, 2026
    32815c1
  5. added a commit that references this issue on Sep 26, 2026
    4ad6303
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type: DefectIncorrect behavior (e.g. crash, hang)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions