Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zpool create with feature@allocation_classes disabled and special vdev hangs #9427

Closed
rugubara opened this issue Oct 8, 2019 · 1 comment · Fixed by #9429
Closed

zpool create with feature@allocation_classes disabled and special vdev hangs #9427

rugubara opened this issue Oct 8, 2019 · 1 comment · Fixed by #9429
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@rugubara
Copy link
Contributor

rugubara commented Oct 8, 2019

System information

Type Version/Name
Distribution Name gentoo
Distribution Version rolling
Linux Kernel 5.2.19
Architecture x86_64
ZFS Version 0.8.2
SPL Version internal

Describe the problem you're observing

Pool creation hangs when special vdev is defined and feature@allocation_classes is disabled

Describe how to reproduce the problem

zpool create -d tank /dev/sda special /dev/sdb

Include any warning/errors/backtraces from the system logs

There is no output. zpool command doesn't return. Any subsequent zpool commands also hang (incl zpool status). The underlying devices get partitioned, but the pool is not created.
as soon as I add -o feature@allocation_classes=enabeld, the pool creation succeeds.

@loli10K loli10K added the Type: Defect Incorrect behavior (e.g. crash, hang) label Oct 8, 2019
@loli10K
Copy link
Contributor

loli10K commented Oct 8, 2019

Logs collected from debug build:

VERIFY(spa_feature_is_enabled(spa, SPA_FEATURE_ALLOCATION_CLASSES)) failed
PANIC at spa_misc.c:1555:spa_activate_allocation_classes()
Showing stack for process 4329
CPU: 0 PID: 4329 Comm: txg_sync Tainted: P           O    4.9.0-3-amd64 #1 Debian 4.9.30-2+deb9u5
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0000000000000000 ffffffffb75285b4 ffffffffc08d8480 ffffc23401bb7ac8
 ffffffffc056b125 0000000000000008 579a0c3000000028 ffffc23401bb7ad8
 ffffc23401bb7a78 7328594649524556 75746165665f6170 6e655f73695f6572
Call Trace:
 [<ffffffffb75285b4>] ? dump_stack+0x5c/0x78
 [<ffffffffc056b125>] ? spl_panic+0xc5/0x100 [spl]
 [<ffffffffc07b16e8>] ? zap_add_impl+0xb8/0x280 [zfs]
 [<ffffffffc07b819d>] ? feature_get_refcount+0x4d/0x90 [zfs]
 [<ffffffffc07710c3>] ? spa_activate_allocation_classes+0x53/0x60 [zfs]
 [<ffffffffc077de49>] ? vdev_construct_zaps+0x189/0x240 [zfs]
 [<ffffffffc077dd2a>] ? vdev_construct_zaps+0x6a/0x240 [zfs]
 [<ffffffffc075c10d>] ? spa_sync_config_object+0xad/0x480 [zfs]
 [<ffffffffc056d43b>] ? spl_kmem_cache_alloc+0xab/0xc10 [spl]
 [<ffffffffb72ac985>] ? set_next_entity+0xb5/0x1a0
 [<ffffffffb73df0b6>] ? kmem_cache_alloc_node_trace+0x156/0x5a0
 [<ffffffffb780390e>] ? mutex_lock+0xe/0x30
 [<ffffffffc056bbd3>] ? spl_kmem_zalloc+0xc3/0x140 [spl]
 [<ffffffffb780390e>] ? mutex_lock+0xe/0x30
 [<ffffffffb72e2d3b>] ? lock_timer_base+0x7b/0xa0
 [<ffffffffc076f5e0>] ? spa_suspend_async_destroy+0x50/0x50 [zfs]
 [<ffffffffb72e2bca>] ? __internal_add_timer+0x1a/0x50
 [<ffffffffb72e5346>] ? add_timer+0x126/0x200
 [<ffffffffc076f5e0>] ? spa_suspend_async_destroy+0x50/0x50 [zfs]
 [<ffffffffc0789384>] ? vdev_indirect_should_condense+0x84/0x2b0 [zfs]
 [<ffffffffc075cfa9>] ? spa_sync+0x859/0x1800 [zfs]
 [<ffffffffc077a7f9>] ? vdev_get_stats_ex_impl+0xe9/0x2b0 [zfs]
 [<ffffffffb780390e>] ? mutex_lock+0xe/0x30
 [<ffffffffb780390e>] ? mutex_lock+0xe/0x30
 [<ffffffffc0773a4e>] ? spa_txg_history_init_io+0xfe/0x110 [zfs]
 [<ffffffffc0778a13>] ? txg_sync_thread+0x303/0x5a0 [zfs]
 [<ffffffffc0778710>] ? txg_thread_wait+0xd0/0xd0 [zfs]
 [<ffffffffc0573e10>] ? __thread_exit+0x20/0x20 [spl]
 [<ffffffffc0573e86>] ? thread_generic_wrapper+0x76/0xb0 [spl]
 [<ffffffffb72965d7>] ? kthread+0xd7/0xf0
 [<ffffffffb7296500>] ? kthread_park+0x60/0x60
 [<ffffffffb78065f5>] ? ret_from_fork+0x25/0x30

behlendorf pushed a commit that referenced this issue Oct 10, 2019
When "feature@allocation_classes" is not enabled on the pool no vdev
with "special" or "dedup" allocation type should be allowed to exist in
the vdev tree.

Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #9427 
Closes #9429
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 26, 2019
When "feature@allocation_classes" is not enabled on the pool no vdev
with "special" or "dedup" allocation type should be allowed to exist in
the vdev tree.

Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#9427
Closes openzfs#9429
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 27, 2019
When "feature@allocation_classes" is not enabled on the pool no vdev
with "special" or "dedup" allocation type should be allowed to exist in
the vdev tree.

Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#9427
Closes openzfs#9429
tonyhutter pushed a commit that referenced this issue Jan 23, 2020
When "feature@allocation_classes" is not enabled on the pool no vdev
with "special" or "dedup" allocation type should be allowed to exist in
the vdev tree.

Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #9427
Closes #9429
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants