Repository navigation
zpool create -t fails to emit zpool history entry for create command #18102
Description
System information
| Type | Version/Name |
|---|---|
| Distribution Name | NixOS |
| Distribution Version | 25.11.20250830.d7600c7 |
| Kernel Version | 6.12.44 |
| Architecture | x86_64 |
| OpenZFS Version | zfs-2.3.4-1 zfs-kmod-2.3.4-1 |
Describe the problem you're observing
in #16408, the reporter’s pool did not have an entry for the zpool create command in zpool history, even though that was in theory a special case that should never get evicted from the history. zpool history -i entries for create pool version 5000 and set feature@... and so on were present as expected.
i ran into those exact symptoms today, just after creating a pool. zpool history was empty, with no entry for the zpool create command, but zpool history -i entries for create pool version 5000 and set feature@... and so on were present as expected.
Describe how to reproduce the problem
$ truncate -s 1G test.img
zpool create without -t works as expected:
$ zpool create test ./test.img
$ zpool history test
History for 'test':
2026-01-01.14:59:54 zpool create test ./test.img
zpool create with -t that does not rename the pool, also works as expected:
$ zpool destroy test
$ zpool create -t test test ./test.img
$ zpool history test
History for 'test':
2026-01-01.15:00:15 zpool create -t test test ./test.img
zpool create with -t that does rename the pool, fails to create the history entry:
$ zpool destroy test
$ zpool create -t test2 test ./test.img
$ zpool history test
cannot open 'test': no such pool
$ zpool history test2
History for 'test2':
zpool history -i still contains the internal entries as expected:
$ zpool history -i test2
2026-01-01.15:00:29 [txg:4] create pool version 5000; software version unknown; uts venus 6.12.44 #1-NixOS SMP PREEMPT_DYNAMIC Thu Aug 28 14:31:16 UTC 2025 x86_64
2026-01-01.15:00:29 [txg:4] set tname=test2
2026-01-01.15:00:29 [txg:4] set feature@async_destroy=enabled
[...]
2026-01-01.15:00:29 [txg:4] set feature@large_microzap=enabled
Activity
delan commentedon Jan 7, 2026
zpool create -t(83e9986) andzpool import -t(26b42f3) are both designed to override the on-disk zpool propertynamewith an in-core “temporary” name, but they work somewhat differently under the hood.importing with a temporary name sets
spa->spa_import_flags |= ZFS_IMPORT_TEMP_NAMEin ZFS_IOC_POOL_IMPORT, which tells spa_write_cachefile() and spa_config_generate() to use the ZPOOL_CONFIG_POOL_NAME inspa->spa_configinstead ofspa->spa_name.creating with a temporary name permanently(!) sets the internal zpool property
tname(ZPOOL_PROP_TNAME) in thezc->zc_nvlist_srcof ZFS_IOC_POOL_CREATE, which tells zfs_ioc_pool_create() (4ceb8dd) and spa_create() to use that name instead ofzc->zc_name, then setsspa->spa_import_flags |= ZFS_IMPORT_TEMP_NAMElike an import.but zfsdev_ioctl_common() fails to check for
tnamewhen saving the pool name tozfs_allow_log_key, so when we call ZFS_IOC_LOG_HISTORY, we call spa_open() on the wrong pool name and get ENOENT, so the logging silently fails.i’ll send a patch to fix this, but i think the design of
tnamefeels weird. it only seems to exist to influence the pool creation logic between ZFS_IOC_POOL_CREATE and spa_add(), but it gets stored in the pool permanently, despite the comment that saysTemporary pool names should never be written to disk.…Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix various issues reported in #23
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`
Fix history logging for `zpool create -t`