Fixing vdev name

[Alexander Leidinger]

Quoting David Chisnall <theraven at freebsd.org> (from Thu, 20 Sep 2018  
14:05:46 +0100):

> [ Please keep me in the cc line - I'm not subscribed to this list ]
>
>>> Hello the list,
>>>
>>> I have a VM that uses ZFS with a pair of striped devices.  The  
>>> first  is a partition on the root disk, created by the installer.   
>>> When  this was too small, I added another device (da1) and told  
>>> the pool  to expand to use it (no redundancy, because the  
>>> underlying storage  for the VM images provides that).  After a  
>>> reboot, I can no longer  boot the system. Booting from the install  
>>> CD and attempting to  import the pool, it correctly identifies  
>>> da0p4 as one of the  devices, but gives me a long number instead  
>>> of da1.
>>
>> This means ZFS doesn't see the other device (or more correctly no   
>> device with the ZFS meta-data on the device which matches what the   
>> pool wants to see as the second vdev).
>
> So there's been some corruption to the disk?

Maybe.

>> Do you see the second disk from non-ZFS tools?
>
> geom lists da1 as a device of the correct type, but zdb doesn't find  
> any labels for it.
>
>> Does the partition info  look OK there (if you partitioned it  
>> before giving it to ZFS)?
>
> I dind't partition it, I just assigned the whole thing to ZFS.

For a raw disk (real hardware) not recommended, but for a LUN from a  
SAN I see no issue with that.

>> Does the geometry/size look correct?
>
> Yup, in geom list it all looks sensible.
>
>>
>>> How do I fix this so that the pool again points to da1?
>>
>> As a side note, it doesn't matter if it is da1 or something else  
>> (e.g.  /dev/gpt/<volid> or whatever), as long as it is a geom  
>> provider  instead of the uuid of the device like it seems to be the  
>> case right  now.
>
> So does this mean that something on the (virtual) disk was corrupted  
> (sufficiently to remove both copies of the label and the uberblock)?

Sounds like. Or the unterlying provider was in some kind of "revert to  
initial state after power-cycle" mode. Or the backing store was  
exchanged in between. Or ...

If you have the space, make an exact copy of the backing store of both  
disks, then run "zpool import -F <pool_name>". This will _try_ to  
revert back to a pool state which can be imported (before addition of  
the 2nd vdev). This will then off course be without any data (or  
chance to recover it) since the addition of the second vdev, but maybe  
this is good enough for you. You then have off course the possibility  
to copy both pools back from the "safecopy" you did before and you  
will be in the same situation as now.

I have no other idea right now and don't know if there is some kind of  
way to let zfs/zdb search harder for ZFS structures on disk (to give  
you an idea of what may have happened or how big a possible corruption  
is).

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF