> On Tue, Apr 10, 2007 at 09:43:39PM -0700, Anton B. > Rang wrote: > > > > That's only one cause of panics. > > > > At least two of gino's panics appear due to > corrupted space maps, for > > instance. I think there may also still be a case > where a failure to > > read metadata during a transaction commit leads to > a panic, too. Maybe > > that one's been fixed, or maybe it will be handled > by the above bug. > > The space map bugs should have been fixed as part of: > > 6458218 assertion failed: ss == NULL > > Which went into Nevada build 60. There are several > different > pathologies that can result from this bug, and I > don't know if the > panics are from before or after this fix.
If that can help you, we are able to corrupt a zpool on snv_60 doing the following a few times: -create a raid10 zpool (dual path luns) -making a high writing load on that zpool -disabling fc ports on both the fc switches Each time we get a kernel panic, probably because of 6322646, and sometimes we get a corrupted zpool. gino This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
