That sounds like a great idea for a tool Jeff. Would it be possible to build
that in as a "zpool recover" command?
Being able to run a tool like that and see just how bad the corruption is, but
know it's possible to recover an older version would be great. Is there any
chance of outputting details so the sysadmin can know roughly how much was
lost?
My thoughts are going to be very rough (I don't know much about zfs internals),
but I'm wondering if something like this would work, where all bad blocks are
reported, along with the latest 3 good ones:
*************************************8
# zpool recover <pool>
......... pool details ...........
Finding and testing uberblocks...
1. block a date/time: xxxxx/xxxx
CORRUPTED
2. block b date/time: yyyyy/yyyy
CORRUPTED
3. block c date/time: zzzzz/zzzz
Appears OK
4. block d date/time: zzzzz/zzzz
Appears OK
5. block e date/time: zzzzz/zzzz
Appears OK
>
*************************************8
Victor was talking in another thread about using zdb to check the pool before
doing an import of a damaged pool. Might it be possible for the next stage of
the recovery process to give the user an option of testing or importing the
pool for any particular uberblock?
It does sound like testing can take a long time, so this would need to be
something that can be cancelled, and you would also need a way to mark
uberblocks as bad should problems be found with either the test or import.
This would be a great addition to ZFS though, and would hopefully save Victor a
bit of time ;-)
Ross
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
