1

ZFS stores 4 labels, 2 at the beginning of a device, 2 at the end. When they are corrupted a pool cannot be mounted.

I had a case of 3 broken labels (failed to unpack), but 1 was still intact. I could list it with zdb -lu just fine.

zpool import -d /dev/sda failed. Using -f, and/or -F, and/or -D failed.

cannot import '/dev/sda': no such pool available

Is there any way I could copy the label #2 to the labels #0, #1, #3?

I am assuming they are redundant copies, existing to boost reliability. However, if that were true, I fail to understand why zfs wouldn't import a pool if there's at least one label left intact, and then simply restore the other three.

Background on how it came to this issue:

  1. I did the stupid thing and created two of my pools with device names such as /dev/sda instead of /dev/disk/by-uuid/1234. Honestly I don't knwo what I was thinking, because I've been there before
  2. Today I plugged in a new drive, wanting to create a new, bigger pool.
  3. Of course, the two pools that failed were those whose "sda" names shifted by one letter.
  4. Once I realized this, I rebooted without the new drive, imported just fine with the correct device names used inside the label.

Why was this reported as a label issue? The labels are still broken, even after the import, with only label 2 intact. How can I fix them?

Add-on question: Is there a tool such as zpool note-my-device-has-a-new-name /dev/sda /dev/disk/by-uuid/1234? Considering the amount of people having the issue, this seems to be helpful. Once I've got my backup of those pools updated, I'll try again.

cfi
  • 258
  • 5
  • 15

2 Answers2

0

I still have no answer to recovering broken labels from one or more remaining, good labels.

But to "rename" the device access point:

zpool note-my-device-has-a-new-name /dev/sda /dev/disk/by-id/1234

do

zpool export tank
zpool import /dev/disk/by-id/1234

If the export fails (device is busy), you could search with lsof | grep tank for users, but more often than not it's just the nfs and samba services running, still accessing your storage. systemctl stop smbd.service nfs-server.service, and then retry the export. If your shell still holds a current work dir inside that pool, you should cd ~ or somewhere outside of that storage. If it still fails, you may try adding -f option, but note that zfs commands with an -f may cause data loss. Think twice.

cfi
  • 258
  • 5
  • 15
0

zhack: Add repair label option ยท openzfs/zfs@d04b5c9

[zhack(1)][1]

I have not used it, but might do in this case (after copying the data to a new pool):

root@mowa219-gjp4-8570p-freebsd:~ # zdb -l /dev/da2p1
------------------------------------
LABEL 0 
------------------------------------
    version: 5000
    name: 'Transcend'
    state: 0
    txg: 6557176
    pool_guid: 8076233369858608335
    errata: 0
    hostid: 635545813
    hostname: 'mowa219-gjp4-8570p-freebsd'
    top_guid: 13893535540375859253
    guid: 13893535540375859253
    vdev_children: 2
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 13893535540375859253
        path: '/dev/gpt/Transcend'
        whole_disk: 1
        metaslab_array: 256
        metaslab_shift: 32
        ashift: 12
        asize: 500102070272
        is_log: 0
        DTL: 273
        create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
        com.delphix:device_removal
    labels = 0 1 2 3 
root@mowa219-gjp4-8570p-freebsd:~ # zpool scrub Transcend
root@mowa219-gjp4-8570p-freebsd:~ # date ; uname -aKU
Sat Feb  4 01:41:37 GMT 2023
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #30 main-n260316-9922bccbc9c4: Sat Jan 28 20:39:00 GMT 2023     grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400078 1400078
root@mowa219-gjp4-8570p-freebsd:~ # ```

  [1]: https://openzfs.github.io/openzfs-docs/man/1/zhack.1.html
Graham Perrin
  • 635
  • 2
  • 10
  • 24