panic in space_map.c line: 114

emoon

emoon

Hi,

I'm running FreeBSD 9.2-amd64 (latest release) and I'm getting this panic when I start the ZFS service:
Code: 
panic: solaris assert: sm->sm_space + size <= sm->sm_size, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 114

I had this pool running fine under FreeBSD 8.0 but then the system disk died (bad HDD) so I got a new SSD, installed 9.2 from scratch on that one and at the same time added two new HDDs to the array. The array is running on this RAID card:

Code: 
3ware device driver for 9000 series storage controllers, version: 3.80.06.003
twa0: <3ware 9000 series Storage Controller> port 0x2000-0x20ff mem 0xf4000000-0xf5ffffff,0xf6100000-0xf6100fff irq 16 at device 0.0 on pci1
twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=4
twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-16ML, 16 ports, Firmware FE9X 4.10.00.021, BIOS BE9X 4.08.00.003
....
da0 at twa0 bus 0 scbus0 target 0 lun 0
da0: <AMCC 9650SE-16M DISK 4.10> Fixed Direct Access SCSI-5 device
da0: 100.000MB/s transfers
da0: 22888096MB (46874820608 512 byte sectors: 255H 63S/T 2917822C)

I upgraded the pool under 9.2 and saw the correct size of the array (21 TB) and everything was working just fine but when I reboot the machine now I run into this issue all the time :\

Here is a bit more information from the crash log:

Code: 
Mon Nov 11 10:20:16 CET 2013

FreeBSD saya.zenic.org 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

panic: solaris assert: sm->sm_space + size <= sm->sm_size, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 114

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: solaris assert: sm->sm_space + size <= sm->sm_size, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 114
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff80947986 at kdb_backtrace+0x66
#1 0xffffffff8090d9ae at panic+0x1ce
#2 0xffffffff8196b12a at assfail+0x1a
#3 0xffffffff8187c298 at space_map_add+0x1b8
#4 0xffffffff8187c6d4 at space_map_load+0x1a4
#5 0xffffffff81864a0c at metaslab_activate+0xdc
#6 0xffffffff81865774 at metaslab_alloc+0x7a4
#7 0xffffffff818a23da at zio_dva_allocate+0x9a
#8 0xffffffff8189ee73 at zio_execute+0xc3
#9 0xffffffff80954554 at taskqueue_run_locked+0x74
#10 0xffffffff80955506 at taskqueue_thread_loop+0x46
#11 0xffffffff808db67f at fork_exit+0x11f
#12 0xffffffff80cdc23e at fork_trampoline+0xe
Uptime: 8m48s
Dumping 458 out of 8168 MB:..4%..11%..21%..32%..42%..53%..63%..74%..81%..91%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
#0  doadump (textdump=<value optimized out>) at pcpu.h:234
234     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:234
#1  0xffffffff8090d486 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:449
#2  0xffffffff8090d987 in panic (fmt=0x1 <Address 0x1 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:637
#3  0xffffffff8196b12a in assfail (a=<value optimized out>,
    f=<value optimized out>, l=<value optimized out>)
    at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81
#4  0xffffffff8187c298 in space_map_add (sm=0xfffffe004318cb00,
    start=13950055920640, size=1024)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c:114
#5  0xffffffff8187c6d4 in space_map_load (sm=0xfffffe004318cb00,
    ops=0xffffffff81939280, maptype=<value optimized out>,
    smo=0xfffffe0043690b20, os=0xfffffe0007162400)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c:367
#6  0xffffffff81864a0c in metaslab_activate (msp=0xfffffe0043690b00,
    activation_weight=9223372036854775808)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:921
#7  0xffffffff81865774 in metaslab_alloc (spa=0xfffffe00439f4000,
    mc=0xfffffe00431eab80, psize=512, bp=0xfffffe00c5132680, ndvas=2,
    txg=3260044, hintbp=0x0, flags=<value optimized out>)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:1463
#8  0xffffffff818a23da in zio_dva_allocate (zio=0xfffffe00c1946000)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2338
#9  0xffffffff8189ee73 in zio_execute (zio=0xfffffe00c1946000)
    at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1305
#10 0xffffffff80954554 in taskqueue_run_locked (queue=0xfffffe00430a5a80)
    at /usr/src/sys/kern/subr_taskqueue.c:312
#11 0xffffffff80955506 in taskqueue_thread_loop (arg=<value optimized out>)
    at /usr/src/sys/kern/subr_taskqueue.c:501
#12 0xffffffff808db67f in fork_exit (
    callout=0xffffffff809554c0 <taskqueue_thread_loop>,
    arg=0xfffffe000786a570, frame=0xffffff824ff1bc40)
    at /usr/src/sys/kern/kern_fork.c:992
#13 0xffffffff80cdc23e in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:606
#14 0x0000000000000000 in ?? ()

Any ideas of how I can solve this issue?

Thanks!
 
Hi again,

I tried to import the pool under FreeBSD 10-BETA3 to see if there wouldn't be any difference and while the assert line was different the code which it asserts on was the same.

Right now I'm considering 3 options:

1. Try to find a solution for the problem (which seems to be hard)
2. Create a new pool and destroy the old one (which would erase all the data)
3. Switch to using UFS or some other filesystem instead of ZFS.

I really would like to use ZFS as its a great FS but running into to these issues isn't something I really want again.
 
You must log in or register to reply here.
Back
Top