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.

Sign up for GitHub

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

Jump to bottom

VERIFY3(size <= spa_maxblocksize(spa)) failed (1048576 <= 131072) #3591

Closed
behlendorf opened this issue Jul 13, 2015 · 1 comment
Closed

VERIFY3(size <= spa_maxblocksize(spa)) failed (1048576 <= 131072) #3591

behlendorf opened this issue Jul 13, 2015 · 1 comment
Milestone
0.6.5

Comments

@behlendorf
Copy link
Contributor

Originally from #354, filed here so it can be tracked.

I recently patched to a level that included this fix. I did not upgrade my pool, but was able to successfull create a zvol with a 1MB block size, which immediately triggered the following panic:

[ 2739.227921] VERIFY3(size <= spa_maxblocksize(spa)) failed (1048576 <= 131072)
[ 2739.228023] PANIC at arc.c:1547:arc_buf_alloc()
[ 2739.228073] Showing stack for process 3480
[ 2739.228078] CPU: 10 PID: 3480 Comm: zvol Tainted: P O 3.18.16-gentoo #1
[ 2739.228080] Hardware name: Supermicro H8DM8-2/H8DM8-2, BIOS 080014 10/22/2009
[ 2739.228082] 000000000000060b ffff8807f42079e8 ffffffff814a2b18 00000000000000fb
[ 2739.228091] ffffffffa1fcaf05 ffff8807f42079f8 ffffffffa063eeb4 ffff8807f4207b78
[ 2739.228094] ffffffffa063ef5d ffff8807f4207a78 ffffffff00000030 ffff8807f4207b88
[ 2739.228097] Call Trace:
[ 2739.228108] [] dump_stack+0x46/0x58
[ 2739.228118] [] spl_dumpstack+0x3d/0x3f [spl]
[ 2739.228124] [] spl_panic+0xa7/0xda [spl]
[ 2739.228129] [] ? spl_kmem_cache_alloc+0x649/0x668 [spl]
[ 2739.228135] [] ? mutex_unlock+0x9/0xb
[ 2739.228158] [] ? dbuf_rele_and_unlock+0x2bf/0x3bb [zfs]
[ 2739.228161] [] ? mutex_unlock+0x9/0xb
[ 2739.228173] [] ? dbuf_rm_spill+0x749/0x786 [zfs]
[ 2739.228185] [] arc_buf_alloc+0x53/0x165 [zfs]
[ 2739.228198] [] dbuf_read+0x2cf/0x71a [zfs]
[ 2739.228214] [] dmu_buf_rele_array+0x242/0x415 [zfs]
[ 2739.228229] [] dmu_buf_hold_array_by_bonus+0xc9/0xe8 [zfs]
[ 2739.228244] [] dmu_read_req+0x49/0xe9 [zfs]
[ 2739.228258] [] zrl_is_locked+0x1267/0x1593 [zfs]
[ 2739.228266] [] taskq_create+0x4e3/0x648 [spl]
[ 2739.228272] [] ? wake_up_process+0x34/0x34
[ 2739.228277] [] ? taskq_create+0x276/0x648 [spl]
[ 2739.228282] [] kthread+0xcd/0xd5
[ 2739.228285] [] ? kthread_create_on_node+0x16c/0x16c
[ 2739.228289] [] ret_from_fork+0x58/0x90
[ 2739.228292] [] ? kthread_create_on_node+0x16c/0x16c

I would imagine that if the pool isn't upgraded we don't want to allow the creation of larger than 128k blocksize.
@behlendorf behlendorf added this to the 0.6.5 milestone Jul 13, 2015
@behlendorf behlendorf mentioned this issue Jul 13, 2015
Closed
@sentania
Copy link

@behlendorf I believe I'm using the "latest" of everything. I used gentoo-9999, pointed at git master as of
~2pm CT 7/10, for kmod, spl, and zfs.

FWIW - I was able to resurrect this pool by importing it into an ominOS (bloody_20150618) live CD, and destroying the wayward zvol.

After zpool upgrade, everything has been functioning as expected for about 48 hours and counting.

behlendorf added a commit to behlendorf/zfs that referenced this issue Aug 24, 2015
@behlendorf
Check large block feature flag on volumes
1c329ca 
Since ZoL allows large blocks to be used by volumes, unlike upstream
illumos, the feature flag must be checked prior to volume creation.
This is critical because unlike filesystems, volumes will create a
object which uses large blocks as part of the create.  Therefore, it
cannot be safely checked in zfs_check_settable() after the dataset
can been created.

In addition this patch updates the relevant error messages to use
zfs_nicenum() to print the maximum blocksize.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue openzfs#3591
@behlendorf behlendorf mentioned this issue Aug 24, 2015
Closed
tomgarcia pushed a commit to tomgarcia/zfs that referenced this issue Sep 11, 2015
@behlendorf @tomgarcia
Check large block feature flag on volumes
d516e15 
Since ZoL allows large blocks to be used by volumes, unlike upstream
illumos, the feature flag must be checked prior to volume creation.
This is critical because unlike filesystems, volumes will create a
object which uses large blocks as part of the create.  Therefore, it
cannot be safely checked in zfs_check_settable() after the dataset
can been created.

In addition this patch updates the relevant error messages to use
zfs_nicenum() to print the maximum blocksize.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#3591
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.5
Development

No branches or pull requests
2 participants
@behlendorf @sentania