Feeling a bit brave (i guess), i upgraded one of our systems to Solaris 10/u2 (from u1), and moved quite a bit of data to zfs. This was 4 days ago. Found the system in a reboot loop this morning. Eventually got the system to boot (by wiping /etc/zfs/zpool.cache), but one of the pools causes the system to panic if i try to import it. Any hope of recovering any data in there? Note that i don''t know what caused the initial panic, as this was lost after however many reboots occured before i got to the system this morning. Christophe assertion failed: ss == NULL, file: ../../common/fs/zfs/space_map.c, line: 81 cee91990 genunix:assfail+51 (f6add838, f6add818,) cee919f4 zfs:space_map_add+2e4 (cf609e38, 1283000, ) cee91a54 zfs:space_map_load+239 (cf609e38, cee6c048,) cee91a7c zfs:zfsctl_ops_root+27c0c607 (cf609c00, 0, 400000) cee91ab4 zfs:metaslab_group_alloc+178 (cd24fe80, 200, 0, 6) cee91b2c zfs:metaslab_alloc_dva+10b (d417f740, 200, 0, c) cee91b64 zfs:zfsctl_ops_root+27c0d4a0 (d417f740, 200, 0, c) cee91ba0 zfs:zio_dva_allocate+5d (ce180500) cee91bb0 zfs:zio_next_stage+76 (ce180500) cee91bcc zfs:zio_checksum_generate+6c (ce180500) cee91bdc zfs:zio_next_stage+76 (ce180500) cee91c30 zfs:zio_write_compress+24a (ce180500) cee91c40 zfs:zio_next_stage+76 (ce180500) cee91c54 zfs:zio_wait_for_children+43 (ce180500, 1, ce1806) cee91c68 zfs:zio_wait_children_ready+15 (ce180500) cee91c78 zfs:zfsctl_ops_root+27c25746 (ce180500) cee91c8c zfs:zio_wait+1a (ce180500) cee91ca0 zfs:arc_write+89 (0, d417f740, 7, 3, ) cee91d18 zfs:dmu_objset_sync+121 (cf6677c0, ce17bc50) cee91d30 zfs:dsl_dataset_sync+14 (cf667940, ce17bc50) cee91d54 zfs:dsl_pool_sync+6f (cdcb2040, 6d1d5, 0) cee91d8c zfs:spa_sync+105 (d417f740, 6d1d5, 0) cee91dc8 zfs:txg_sync_thread+140 (cdcb2040, 0) cee91dd8 unix:thread_start+8 ()
Interesting. When you do the import, try doing this:
zpool import -o ro yourpool
And see if that fares any better. If it works, could you send the
output of "zpool status -v"? Also, how big is the pool in question?
Either access to the machine, or a way to copy the crash dump would be
useful. I can give you more commands to run at that point.
--Bill
On Mon, Jul 31, 2006 at 12:06:40PM -0400, Christophe Kalt
wrote:> Feeling a bit brave (i guess), i upgraded one of our systems
> to Solaris 10/u2 (from u1), and moved quite a bit of data to
> zfs. This was 4 days ago. Found the system in a reboot loop
> this morning.
>
> Eventually got the system to boot (by wiping
> /etc/zfs/zpool.cache), but one of the pools causes the system
> to panic if i try to import it. Any hope of recovering any
> data in there?
>
> Note that i don''t know what caused the initial panic, as this
> was lost after however many reboots occured before i got to
> the system this morning.
>
> Christophe
>
> assertion failed: ss == NULL, file: ../../common/fs/zfs/space_map.c, line:
81
> cee91990 genunix:assfail+51 (f6add838, f6add818,)
> cee919f4 zfs:space_map_add+2e4 (cf609e38, 1283000, )
> cee91a54 zfs:space_map_load+239 (cf609e38, cee6c048,)
> cee91a7c zfs:zfsctl_ops_root+27c0c607 (cf609c00, 0, 400000)
> cee91ab4 zfs:metaslab_group_alloc+178 (cd24fe80, 200, 0, 6)
> cee91b2c zfs:metaslab_alloc_dva+10b (d417f740, 200, 0, c)
> cee91b64 zfs:zfsctl_ops_root+27c0d4a0 (d417f740, 200, 0, c)
> cee91ba0 zfs:zio_dva_allocate+5d (ce180500)
> cee91bb0 zfs:zio_next_stage+76 (ce180500)
> cee91bcc zfs:zio_checksum_generate+6c (ce180500)
> cee91bdc zfs:zio_next_stage+76 (ce180500)
> cee91c30 zfs:zio_write_compress+24a (ce180500)
> cee91c40 zfs:zio_next_stage+76 (ce180500)
> cee91c54 zfs:zio_wait_for_children+43 (ce180500, 1, ce1806)
> cee91c68 zfs:zio_wait_children_ready+15 (ce180500)
> cee91c78 zfs:zfsctl_ops_root+27c25746 (ce180500)
> cee91c8c zfs:zio_wait+1a (ce180500)
> cee91ca0 zfs:arc_write+89 (0, d417f740, 7, 3, )
> cee91d18 zfs:dmu_objset_sync+121 (cf6677c0, ce17bc50)
> cee91d30 zfs:dsl_dataset_sync+14 (cf667940, ce17bc50)
> cee91d54 zfs:dsl_pool_sync+6f (cdcb2040, 6d1d5, 0)
> cee91d8c zfs:spa_sync+105 (d417f740, 6d1d5, 0)
> cee91dc8 zfs:txg_sync_thread+140 (cdcb2040, 0)
> cee91dd8 unix:thread_start+8 ()
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Jul 31, Bill Moore wrote: | Interesting. When you do the import, try doing this: | | zpool import -o ro yourpool | | And see if that fares any better. If it works, could you send the | output of "zpool status -v"? Also, how big is the pool in question? Same panic. It''s a 250GB drive, so around this. | Either access to the machine, or a way to copy the crash dump would be | useful. I can give you more commands to run at that point. Access to the machine a bit tricky, but i can send data, just let me know what, where, how. :) Christophe
For those within Sun (particularly the SPA experts), this core is available at: /net/mdb.eng/cores/eschrock/christophe_kalt/*.0 - Eric On Mon, Jul 31, 2006 at 04:04:43PM -0400, Christophe Kalt wrote:> On Jul 31, Bill Moore wrote: > | Interesting. When you do the import, try doing this: > | > | zpool import -o ro yourpool > | > | And see if that fares any better. If it works, could you send the > | output of "zpool status -v"? Also, how big is the pool in question? > > Same panic. > It''s a 250GB drive, so around this. > > | Either access to the machine, or a way to copy the crash dump would be > | useful. I can give you more commands to run at that point. > > Access to the machine a bit tricky, but i can send data, just > let me know what, where, how. :) > > Christophe > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock