> > 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. I hope > folks from the ZFS > team are investigating, but I can't speak for > everyone.
This week we'll start one of our "burn test" on snv60. I'll let you know. For the moment we are able to panic zfs very easily. We'll see if we are able to corrupt again a zpool. > > Maybe someone needs to file a bug/RFE to remove all > panics from ZFS, > > at least in non-debug builds? The QFS approach is > to panic when > > inconsistency is found on debug builds, but return > an appropriate > > error code on release builds, which seems > reasonable. > > In order to do this we need to fix 6322646 first, > which addresses the > issue of 'backing out' of a transaction once we're > down in the ZIO layer > discovering these problems. It doesn't matter if > it's due to an I/O > error or space map inconsistency or I/O error if we > can't propagate the > error. Any EDT for 6322646 and 6417779 ? 6417779 ZFS: I/O failure (write on ...) 6322646 ZFS should gracefully handle all devices failing (when writing) Isn't there a way to increase the "timeout" to have Solaris just hang when a lun is not available and have it retry the i/o more times? gino This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
