Tom Bird wrote:
> Richard Elling wrote:
>
>
>> I see no evidence that the data is or is not correct. What we know is that
>> ZFS is attempting to read something and the device driver is returning EIO.
>> Unfortunately, EIO is a catch-all error code, so more digging to find the
>> root cause is needed.
>>
>
> I'm currently checking the whole LUN, although as a 42TB unit this will
> take a few hours so we'll see how that is tomorrow.
>
>
>> However, I will bet a steak dinner that if this device was mirrored to
>> another,
>> the pool will import just fine, with the affected device in a faulted or
>> degraded
>> state.
>>
>
> On any other file system though, I could probably kick off a fsck and
> get back most of the data. I see the argument a lot that ZFS "doesn't
> need" a fsck utility, however I would be inclined to disagree, if not a
> full on fsck then something that can patch it up to the point where I
> can mount it and then get some data off or run a scrub.
>
>
Probably not. fsck only repairs metadata, it does not restore or correct
data. If the data is gone or damaged, then there isn't much ZFS could
do, since ZFS was not in control of the data redundancy (by default,
ZFS metadata is redundant).
BTW, another good sanity test is to try to read the ZFS labels:
zdb -l /dev/rdsk/...
Cindy, I note that we don't explicitly address the case where the pool
cannot be imported in the Troubleshooting and Data Recovery chapter
of the ZFS administration guide. Can we put this on the todo list?
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
