thr3ads.net - zfs discuss - [zfs-discuss] Importing old vdev [Oct 2011]

If this information is useful, please help other people find it:
Share via:

James Lee

2011-Oct-07 15:02 UTC

[zfs-discuss] Importing old vdev

Hello,

I had a pool made from a single LUN, which I''ll call c4t0d0 for the
purposes of this email.  We replaced it with another LUN, c4t1d0, to
grow the pool size.  Now c4t1d0 is hosed and I''d like to see about
recovering whatever data we can from the original LUN, c4t0d0.

I can still see the ZFS labels on t0 with zdb [1], but it is not
available for importing (even with zpool import -D).  Are there any
tools available for me to tweak the metadata on the old LUN so that I
can import it?  Is there anything else I can try?

I am using Solaris 10 U9, and before anyone says anything, our SAN guys
don''t really understand ZFS or else I would have made the pool
redundant
in the first place.

Thanks,

James

[1] starlight ~ # zdb -l /dev/dsk/c4t0d0s0
--------------------------------------------
LABEL 0
--------------------------------------------
    version=22
    name=''idmtestdb2''
    state=0
    txg=0
    pool_guid=10473782060848894552
    hostid=2237159492
    hostname=''starlight.es.gwu.edu''
    top_guid=16179157240083602291
    guid=5824491362217506815
    vdev_children=1
    vdev_tree
        type=''replacing''
        id=0
        guid=16179157240083602291
        whole_disk=0
        metaslab_array=23
        metaslab_shift=31
        ashift=9
        asize=268425232384
        is_log=0
        children[0]
                type=''disk''
                id=0
                guid=5824491362217506815
                path=''/dev/dsk/c4t0d0s0''
                devid=''id1,ssd at n0/a''
                phys_path=''/scsi_vhci/ssd at g0:a''
                whole_disk=1
                DTL=60
        children[1]
                type=''disk''
                id=1
                guid=18335497050081682816
                path=''/dev/dsk/c4t1d0s0''
                devid=''id1,ssd at n1/a''
                phys_path=''/scsi_vhci/ssd at g1:a''
                whole_disk=1
                DTL=254
    create_txg=0
--------------------------------------------
LABEL 1
--------------------------------------------
    version=22
    name=''idmtestdb2''
    state=0
    txg=0
    pool_guid=10473782060848894552
    hostid=2237159492
    hostname=''starlight.es.gwu.edu''
    top_guid=16179157240083602291
    guid=5824491362217506815
    vdev_children=1
    vdev_tree
        type=''replacing''
        id=0
        guid=16179157240083602291
        whole_disk=0
        metaslab_array=23
        metaslab_shift=31
        ashift=9
        asize=268425232384
        is_log=0
        children[0]
                type=''disk''
                id=0
                guid=5824491362217506815
                path=''/dev/dsk/c4t0d0s0''
                devid=''id1,ssd at n0/a''
                phys_path=''/scsi_vhci/ssd at g0:a''
                whole_disk=1
                DTL=60
        children[1]
                type=''disk''
                id=1
                guid=18335497050081682816
                path=''/dev/dsk/c4t1d0s0''
                devid=''id1,ssd at n1/a''
                phys_path=''/scsi_vhci/ssd at g1:a''
                whole_disk=1
                DTL=254
    create_txg=0
--------------------------------------------
LABEL 2
--------------------------------------------
    version=22
    name=''idmtestdb2''
    state=0
    txg=0
    pool_guid=10473782060848894552
    hostid=2237159492
    hostname=''starlight.es.gwu.edu''
    top_guid=16179157240083602291
    guid=5824491362217506815
    vdev_children=1
    vdev_tree
        type=''replacing''
        id=0
        guid=16179157240083602291
        whole_disk=0
        metaslab_array=23
        metaslab_shift=31
        ashift=9
        asize=268425232384
        is_log=0
        children[0]
                type=''disk''
                id=0
                guid=5824491362217506815
                path=''/dev/dsk/c4t0d0s0''
                devid=''id1,ssd at n0/a''
                phys_path=''/scsi_vhci/ssd at g0:a''
                whole_disk=1
                DTL=60
        children[1]
                type=''disk''
                id=1
                guid=18335497050081682816
                path=''/dev/dsk/c4t1d0s0''
                devid=''id1,ssd at n1/a''
                phys_path=''/scsi_vhci/ssd at g1:a''
                whole_disk=1
                DTL=254
    create_txg=0
--------------------------------------------
LABEL 3
--------------------------------------------
    version=22
    name=''idmtestdb2''
    state=0
    txg=0
    pool_guid=10473782060848894552
    hostid=2237159492
    hostname=''starlight.es.gwu.edu''
    top_guid=16179157240083602291
    guid=5824491362217506815
    vdev_children=1
    vdev_tree
        type=''replacing''
        id=0
        guid=16179157240083602291
        whole_disk=0
        metaslab_array=23
        metaslab_shift=31
        ashift=9
        asize=268425232384
        is_log=0
        children[0]
                type=''disk''
                id=0
                guid=5824491362217506815
                path=''/dev/dsk/c4t0d0s0''
                devid=''id1,ssd at n0/a''
                phys_path=''/scsi_vhci/ssd at g0:a''
                whole_disk=1
                DTL=60
        children[1]
                type=''disk''
                id=1
                guid=18335497050081682816
                path=''/dev/dsk/c4t1d0s0''
                devid=''id1,ssd at n1/a''
                phys_path=''/scsi_vhci/ssd at g1:a''
                whole_disk=1
                DTL=254
    create_txg=0

James Lee

2011-Oct-10 20:43 UTC

head link

[zfs-discuss] Importing old vdev

On 10/07/2011 11:02 AM, James Lee wrote:> Hello,
> 
> I had a pool made from a single LUN, which I''ll call c4t0d0 for
the
> purposes of this email.  We replaced it with another LUN, c4t1d0, to
> grow the pool size.  Now c4t1d0 is hosed and I''d like to see about
> recovering whatever data we can from the original LUN, c4t0d0.
> 
> I can still see the ZFS labels on t0 with zdb [1], but it is not
> available for importing (even with zpool import -D).  Are there any
> tools available for me to tweak the metadata on the old LUN so that I
> can import it?  Is there anything else I can try?
> 
> I am using Solaris 10 U9, and before anyone says anything, our SAN guys
> don''t really understand ZFS or else I would have made the pool
redundant
> in the first place.
I found an old post by Jeff Bonwick with some code that does EXACTLY
what I was looking for [1].  I had to update the ''label_write''
function
to support the newer ZFS interfaces:
> /*
>  * Write a label block with a ZBT checksum.
>  */
> static void
> label_write(int fd, uint64_t offset, uint64_t size, void *buf)
> {
>         zio_eck_t *zbt, zbt_orig;
>         zio_cksum_t zc;
> 
>         zbt = (zio_eck_t *)((char *)buf + size) - 1;
>         zbt_orig = *zbt;
> 
>         ZIO_SET_CHECKSUM(&zbt->zec_cksum, offset, 0, 0, 0);
> 
>         zio_checksum_SHA256(buf, size, &zc);
>         zbt->zec_cksum = zc;
> 
>         VERIFY(pwrite64(fd, buf, size, offset) == size);
> 
>         *zbt = zbt_orig;
> }
Then I compiled it against the illumos headers...something like:
> /usr/sfw/bin/gcc -I illumos-gate/usr/src/uts/common/fs/zfs -o labelfix
labelfix.c illumos-gate/usr/src/uts/common/fs/zfs/sha256.c assfail.o -lzfs
-lnvpair -lmd
And finally ran the resulting binary against the old LUN:
> # zpool import
> # ./labelfix /dev/rdsk/c4t60000970000192602845533030373032d0s0
> # zpool import
>   pool: idmtestdb2
>     id: 10473782060848894552
>  state: DEGRADED
> action: The pool can be imported despite missing or damaged devices.  The
>         fault tolerance of the pool may be compromised if imported.
> config:
> 
>         idmtestdb2                                 DEGRADED
>           replacing-0                              DEGRADED
>             c4t60000970000192602845533030373032d0  ONLINE
>             c4t60000970000192602845533030363743d0  UNAVAIL  cannot open
> # zpool import idmtestdb2
> # zpool detach idmtestdb2 18335497050081682816
> # zpool status idmtestdb2
>   pool: idmtestdb2
>  state: ONLINE
>  scrub: none requested
> config:
> 
>         NAME                                     STATE     READ WRITE CKSUM
>         idmtestdb2                               ONLINE       0     0     0
>           c4t60000970000192602845533030373032d0  ONLINE       0     0     0
> 
> errors: No known data errors
Thank you Jeff!

[1]
http://thread.gmane.org/gmane.os.solaris.opensolaris.zfs/15796/focus=15929

Daniel Carosone

2011-Oct-10 22:42 UTC

head link

[zfs-discuss] Importing old vdev

On Mon, Oct 10, 2011 at 04:43:30PM -0400, James Lee
wrote:> I found an old post by Jeff Bonwick with some code that does EXACTLY
> what I was looking for [1].  I had to update the
''label_write'' function
> to support the newer ZFS interfaces:
That''s great!

Would someone in the community please kindly adopt this little snippet
so that it is maintained as further zfs format updates occur?  Perhaps
even fold it into zdb?

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111011/5cd2c9f8/attachment.bin>

zfs discuss - Oct 2011 - Importing old vdev

[zfs-discuss] Importing old vdev

[zfs-discuss] Importing old vdev

[zfs-discuss] Importing old vdev