> About 99% of the problems reported as "I need ZFS > fsck" can be summed up > by two ZFS bugs: > > 1. If a toplevel vdev fails to open, we should be > able to pull > information from necessary ditto blocks to open > the pool and make > what progress we can. Right now, the root vdev > code assumes "can't > open = faulted pool," which results in failure > scenarios that are > perfectly recoverable most of the time. This needs > to be fixed > so that pool failure is only determined by the > ability to read > critical metadata (such as the root of the DSL). > . If an uberblock ends up with an inconsistent view > of the world (due > to failure of DKIOCFLUSHWRITECACHE, for example), > we should be able > to go back to previous uberblocks to find a good > view of our pool. > This is the failure mode described by Jeff. > [b]These are both bugs in ZFS and will be fixed. [/b]
I totally agree these covers most of the corruptions we had in past. Any news about that bugs in recent Nevada release? Anyone can provide us a detailed procedure to "go back to previous uberblocks to find a good view of our pool" as described by Jeff? Thanks gino -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
