> His explanation: he invalidated the incorrect
> uberblocks and forced zfs to revert to an earlier
> state that was consistent.
Would someone be willing to document the steps required in order to do this
please?
I have a disk in a similar state:
# zpool import
pool: tank
id: 13234439337856002730
state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
The pool may be active on another system, but can be imported using
the '-f' flag.
see: http://www.sun.com/msg/ZFS-8000-72
config:
tank FAULTED corrupted data
c7d0 ONLINE
This happened after I foolishly began trusting zfs-fuse with some large but
relatively unimportant data on a big, empty single disk zpool in my home
machine and then suffered a power cut before I got around to backing it up.
OpenSolaris can't import the pool either, so the drive is sat on a shelf
waiting till a method for fixing it is published.
While it's clearly my own fault for taking the risks I did, it's still pretty
frustrating knowing that all my data is likely still intact and nicely
checksummed on the disk but that none of it is accessible due to some tiny
filesystem inconsistency. With pretty much any other FS I think I could get
most of it back.
Clearly such a small number of occurrences in what were admittedly precarious
configurations aren't going to be particularly convincing motivators to provide
a general solution, but I'd feel a whole lot better about using ZFS if I knew
that there were some documented steps or a tool (zfsck? ;) that could help to
recover from this kind of metadata corruption in the unlikely event of it
happening.
cheers,
Rob
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
