> 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.
Now this is scary, looking from the descriptions, it is possible that we might lose data in zfs, and/or resulted in a corrupted zpool that panics the kernel, if during the write operation, zfs loses connection to underlying hardwares? (for example a power failure?) But I've rarely seen that since we got UFS w/ logging in Solaris 7 or something. Even with UFS, there is always fsck allowing us to bring system back to a consistent state for recovering from previous backup. Is ZFS really supposed to be more reliable than UFS w/ logging, for example, in single disk, root file system scenario? > > - 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-discu > ss > This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
