Bug #4219
open
zfs: allocating allocated segment
0%
Description
panic[cpu1]/thread=ffffff04eae2d120:
zfs: allocating allocated segment(offset=182868315136 size=36864)
ffffff0020379560 genunix:vcmn_err+2c ()
ffffff0020379650 zfs:zfs_panic_recover+ae ()
ffffff00203796f0 zfs:space_map_add+d3 ()
ffffff00203797a0 zfs:space_map_load+396 ()
ffffff0020379800 zfs:metaslab_activate+95 ()
ffffff00203798c0 zfs:metaslab_group_alloc+246 ()
ffffff0020379980 zfs:metaslab_alloc_dva+2aa ()
ffffff0020379a20 zfs:metaslab_alloc+9c ()
ffffff0020379ab0 zfs:zio_alloc_zil+98 ()
ffffff0020379b20 zfs:zil_lwb_write_start+2ad ()
ffffff0020379b90 zfs:zil_lwb_commit+b6 ()
ffffff0020379be0 zfs:zil_commit_writer+e2 ()
ffffff0020379c20 zfs:zil_commit+a7 ()
ffffff0020379ca0 zfs:zvol_write+231 ()
ffffff0020379cd0 genunix:cdev_write+3d ()
ffffff0020379d80 specfs:spec_write+48c ()
ffffff0020379df0 genunix:fop_write+6b ()
ffffff0020379ec0 genunix:pwrite64+244 ()
ffffff0020379f10 unix:brand_sys_sysenter+1c9 ()
syncing file systems...
panic[cpu1]/thread=ffffff04eae2d120:
panic sync timeout
log device may be faulty, but should not cause zfs panic.
Updated by Nahum Shalman almost 7 years ago
I have a pool of a single mirror vdev that is now spitting out the same error message with the following panic and stack trace:
http://imgur.com/WLC8Qub
Does anyone want me to try to obtain a crash dump?
Should my crash be a different issue number?
Details:
Pool was running on a 2013-era SmartOS platform until it ended up in the reboot loop.
The pool is unimportable (triggers the panic) read-write by the latest SmartOS platform ( https://github.com/joyent/illumos-joyent/tree/20150917 ) but is importable readonly.
To reproduce this panic, simply try to import my broken zpool normally ( "zpool import zones" )
Per discussion on IRC it's possible that I hit #4390
Updated by Damian Wojslaw almost 7 years ago
Is it a duplicate or reoccurence of: https://www.illumos.org/issues/4390?
Stack trace seems very similar