Score:0

How can one recover/write a label (clone existing one)?

ng flag
cfi

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.

Score:0
sk flag

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
Score:0
ng flag
cfi

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.