Chris Siebenmann wrote: > I'm not Anton Rang, but: > | How would you describe the difference between the data recovery > | utility and ZFS's normal data recovery process? > > The data recovery utility should not panic my entire system if it runs > into some situation that it utterly cannot handle. Solaris 10 U5 kernel > ZFS code does not have this property; it is possible to wind up with ZFS > pools that will panic your system when you try to touch them. > > (The same thing is true of a theoretical file system checking utility.) > > The data recovery utility can ask me questions about what I want it > to do in an ambiguous situation, or give me only partial results. > > The data recovery can be run read-only, so that I am sure that any > problems in it are not making my situation worse. > > | Nobody thinks that an answer of "sorry, we lost all of your data" is > | acceptable. However, there are failures which will result in loss of > | data no matter how clever the file system is. > > The problem is that there are currently ways to make ZFS lose all your > data when there are no hardware faults or failures, merely people or > software mis-handling pools. This is especially frustrating when the > only thing that is likely to be corrupted is ZFS metadata and the vast > majority (or all) of the data in the pool is intact, readable, and so > on. >
As others have noted, the COW nature of ZFS means that there is a good chance that on a mostly-empty pool, previous data is still intact long after you might think it is gone. A utility to recover such data is (IMHO) more likely to be in the category of forensic analysis than a mount (import) process. There is more than enough information publically available for someone to build such a tool (hint, hint :-) -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
