>From what i understand, and from everything i've read by following threads here, there are ways to do it but there is not a standardized tool yet, and it's complicated and on a per-case basis but people who pay for support have recovered pools.
i'm sure they are working on it, and i would imagine it would be a major goal. On Wed, Aug 5, 2009 at 1:23 AM, James Hess <no-re...@opensolaris.org> wrote: > So much for the "it's a consumer hardware problem" argument. > I for one gotta count it as a major drawback of ZFS that it doesn't provide > you a mechanism to get something of your pool back in the manner of > reconstruction or reversion, if a failure occurs, where there is a metadata > inconsistency. > > A policy of data integrity taken to the extreme of blocking access to good > data is not something OS users want. > > Users don't put up with this sort of thing from other filesystems... some > sort of improvement here is sorely needed. > > ZFS ought to be retaining enough information and make an effort to bring > pool metadata back to a consistent state, even if it means loss of data, > that a file may have to revert to an older state, or a file that was > undergoing changes may now be unreadable, since the log was inconsistent.. > > even if the user should have to zpool import with a recovery-mode option > or something of that nature. > > It beats losing a TB of data on the pool that should be otherwise intact. > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
