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. I hope folks from the ZFS team are investigating, but I can't speak for everyone. > 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. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
