On 11/14/06, Robert Milkowski <[EMAIL PROTECTED]> wrote:
Hello Rainer,
Tuesday, November 14, 2006, 4:43:32 AM, you wrote:
RH> Sorry for the delay...
RH> No, it doesn't. The format command shows the drive, but zpool
RH> import does not find any pools. I've also used the detached bad
RH> SATA drive for testing; no go. Once a drive is detached, there
RH> seems to be no (not enough?) information about the pool that allows import.
Aha, you did zpool detach - sorry I missed it. Then zpool import won't
show you any pools to import from such disk. I agree with you it would
be useful to do so.
After examining the source, it clearly wipes the vdev label during a detach.
I suppose it does this so that the machine can't get confused at a later date.
It would be nice if the detach simply renamed something, rather than
destroying the pool though. At the very least, the manual page ought
to
reflect the destructive nature of the detach command.
That said, it looks as if the code only zeros the first uberblock, so the
data may yet be recoverable. In order to reconstruct the pool, I think
you would need to replace the vdev labels with ones from another of
your mirrors, and possibly the EFI label so that the GUID matched.
Then, corrupt the first uberblock, and pray that it imports. (It may be
necessary to modify the txg in the labels as well, though I have
already speculated enough...)
Can anyone say for certain?
Chris
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
