Wouldn't this be the known feature where a write error to zfs forces a panic?
Vic On 10/4/07, Ben Rockwood <[EMAIL PROTECTED]> wrote: > Dick Davies wrote: > > On 04/10/2007, Nathan Kroenert <[EMAIL PROTECTED]> wrote: > > > > > >> Client A > >> - import pool make couple-o-changes > >> > >> Client B > >> - import pool -f (heh) > >> > > > > > >> Oct 4 15:03:12 fozzie ^Mpanic[cpu0]/thread=ffffff0002b51c80: > >> Oct 4 15:03:12 fozzie genunix: [ID 603766 kern.notice] assertion > >> failed: dmu_read(os, smo->smo_object, offset, size, entry_map) == 0 (0x5 > >> == 0x0) > >> , file: ../../common/fs/zfs/space_map.c, line: 339 > >> Oct 4 15:03:12 fozzie unix: [ID 100000 kern.notice] > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51160 > >> genunix:assfail3+b9 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51200 > >> zfs:space_map_load+2ef () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51240 > >> zfs:metaslab_activate+66 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51300 > >> zfs:metaslab_group_alloc+24e () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b513d0 > >> zfs:metaslab_alloc_dva+192 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51470 > >> zfs:metaslab_alloc+82 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b514c0 > >> zfs:zio_dva_allocate+68 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b514e0 > >> zfs:zio_next_stage+b3 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51510 > >> zfs:zio_checksum_generate+6e () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51530 > >> zfs:zio_next_stage+b3 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b515a0 > >> zfs:zio_write_compress+239 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b515c0 > >> zfs:zio_next_stage+b3 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51610 > >> zfs:zio_wait_for_children+5d () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51630 > >> zfs:zio_wait_children_ready+20 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51650 > >> zfs:zio_next_stage_async+bb () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51670 > >> zfs:zio_nowait+11 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51960 > >> zfs:dbuf_sync_leaf+1ac () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b519a0 > >> zfs:dbuf_sync_list+51 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51a10 > >> zfs:dnode_sync+23b () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51a50 > >> zfs:dmu_objset_sync_dnodes+55 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51ad0 > >> zfs:dmu_objset_sync+13d () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51b40 > >> zfs:dsl_pool_sync+199 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51bd0 > >> zfs:spa_sync+1c5 () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51c60 > >> zfs:txg_sync_thread+19a () > >> Oct 4 15:03:12 fozzie genunix: [ID 655072 kern.notice] ffffff0002b51c70 > >> unix:thread_start+8 () > >> Oct 4 15:03:12 fozzie unix: [ID 100000 kern.notice] > >> > > > > > >> Is this a known issue, already fixed in a later build, or should I bug it? > >> > > > > It shouldn't panic the machine, no. I'd raise a bug. > > > > > >> After spending a little time playing with iscsi, I have to say it's > >> almost inevitable that someone is going to do this by accident and panic > >> a big box for what I see as no good reason. (though I'm happy to be > >> educated... ;) > >> > > > > You use ACLs and TPGT groups to ensure 2 hosts can't simultaneously > > access the same LUN by accident. You'd have the same problem with > > Fibre Channel SANs. > > > I ran into similar problems when replicating via AVS. > > benr. > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
