Hello Gino, Wednesday, April 11, 2007, 10:43:17 AM, you wrote:
>> 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. G> If that can help you, we are able to corrupt a zpool on snv_60 doing the following a few times: G> -create a raid10 zpool (dual path luns) G> -making a high writing load on that zpool G> -disabling fc ports on both the fc switches G> Each time we get a kernel panic, probably because of 6322646, and G> sometimes we get a corrupted zpool. Is it still the case? Was the problem of corruption the pool addressed and hopefully solved? -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
