Switching ZFS pool to partuuid from /dev/sda labeling for server migration

Operating Systems & Open Source Linux
, ,
1

Hello all,

I have a very specific issue with trying to move from the sda/sdb disk labels that are assigned at boot to the more permanent partuuid system.

This is the result of trying to export, then re-import using the " import -d /dev/disk/by-partuuid" command.

The odd thing is the rest of the disks just stay as sdb, sbc, etc. and I don’t know enough about ZFS to change them all, or even if this is bad. Perhaps the disks will be found regardless?

I need to migrate the system (new motherboard, CPU) and I know that the UUIDs are more stable. Will this pose an issue? Will the import still work even though the rest of the disks still use a labeling system that assigns letters based on read order in BIOS (or some early boot phase of linux)?

$ sudo zpool export archive_pool
$ sudo zpool import -d /dev/disk/by-partuuid/e6e3728b-aa97-4246-b19a-c96d989664e3 archive_pool

$ zpool status archive_pool
pool: archive_pool
state: ONLINE
scan: scrub repaired 0B in 02:56:30 with 0 errors on Sun Oct 8 03:20:32 2023
config:

    NAME                                      STATE     READ WRITE CKSUM
    archive_pool                              ONLINE       0     0     0
      raidz1-0                                ONLINE       0     0     0
        sdb                                   ONLINE       0     0     0
        sdc                                   ONLINE       0     0     0
        sdd                                   ONLINE       0     0     0
        sde                                   ONLINE       0     0     0
        e6e3728b-aa97-4246-b19a-c96d989664e3  ONLINE       0     0     0
    cache
      sdh                                     ONLINE       0     0     0

System is a ubuntu server edition version 22.04

version: 2.1.5-1ubuntu6~22.04.1
srcversion: 5A94B4662A7A991696CC35F
vermagic: 5.15.0-87-generic SMP mod_unload modversions

[ 7.028468] ZFS: Loaded module v2.1.5-1ubuntu6~22.04.1, ZFS pool version 5000, ZFS filesystem version 5

ZFS version 5 as seen above

All disks in the archive_pool are WD RED 4tb, the cache is a samsung 256gb SATA SSD

systems runs a 4770k baseclock and 32gb of 2600mhz ram

All the best, thanks for any help.

2

I usually just issue sudo zpool import, without fancy complications. ZFS then iterates all the block devices (even zvols of other pools, under /dev/zvol/) and prints out a list if there are any pools that aren’t already imported. Then i just sudo zpool import theDesiredPool, bang, done. I stopped caring about block device names quite a while ago, since ZFS is auto-magic like that.

edit: also, the zpool-import manpage says

-d dir|device
   Uses device or searches for devices or files in dir.  The -d option can be specified multiple times.

so, you could just tell ZFS to look in the -d /dev/disk/by-partuuid/ directory, without specifying a particular partition. I haven’t tried this myself, but it’d kinda make sense that ZFS uses the file names / as device names.

4 Likes
3

This is how I always thought of it

4

okay, @Platypussy is right:

root@Ubu2004RedChungus:/home/ish# zpool list -v Curoch
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Curoch      2.03T   729G  1.32T        -         -    15%    35%  1.00x    ONLINE  -
  raidz1-0  2.03T   729G  1.32T        -         -    15%  35.0%      -    ONLINE
    sdh1     699G      -      -        -         -      -      -      -    ONLINE
    sdg1     699G      -      -        -         -      -      -      -    ONLINE
    sde1     699G      -      -        -         -      -      -      -    ONLINE
root@Ubu2004RedChungus:/home/ish# zpool export Curoch ; sleep 5 ; zpool import -d /dev/disk/by-id Curoch ; sleep 5 ; zpool list -v Curoch
NAME                               SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Curoch                            2.03T   729G  1.32T        -         -    15%    35%  1.00x    ONLINE  -
  raidz1-0                        2.03T   729G  1.32T        -         -    15%  35.0%      -    ONLINE
    wwn-0x50026b7682991bd0-part1   699G      -      -        -         -      -      -      -    ONLINE
    wwn-0x500253884023bc67-part1   699G      -      -        -         -      -      -      -    ONLINE
    wwn-0x500253885009ce56-part1   699G      -      -        -         -      -      -      -    ONLINE
root@Ubu2004RedChungus:/home/ish# zpool export Curoch ; sleep 5 ; zpool import -d /dev/disk/by-partuuid Curoch ; sleep 5 ; zpool list -v Curoch
NAME                                       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Curoch                                    2.03T   729G  1.32T        -         -    15%    35%  1.00x    ONLINE  -
  raidz1-0                                2.03T   729G  1.32T        -         -    15%  35.0%      -    ONLINE
    f1098db0-5569-9047-8bc5-2a7c2573f3ab   699G      -      -        -         -      -      -      -    ONLINE
    a408494e-57a2-314d-8c5e-8e6a0053050c   699G      -      -        -         -      -      -      -    ONLINE
    73716b89-f720-d245-9a6f-1ba001be2317   699G      -      -        -         -      -      -      -    ONLINE
2 Likes
5

OH that’s how that works! Thanks all :slight_smile:

$ zpool status archive_pool
pool: archive_pool
state: ONLINE
scan: scrub repaired 0B in 02:56:30 with 0 errors on Sun Oct 8 03:20:32 2023
config:

    NAME                                      STATE     READ WRITE CKSUM
    archive_pool                              ONLINE       0     0     0
      raidz1-0                                ONLINE       0     0     0
        71dfaf04-d9b0-f94d-a2a2-19f774486688  ONLINE       0     0     0
        19b6661d-5a50-684d-b0b1-62079feb77da  ONLINE       0     0     0
        f571c5cd-cc41-8e40-adda-c831a60b11b0  ONLINE       0     0     0
        1423afdc-4f87-844d-8f5e-5e9054ce4b49  ONLINE       0     0     0
        e6e3728b-aa97-4246-b19a-c96d989664e3  ONLINE       0     0     0
    cache
      ec7ee570-464c-7147-b1a7-e3e25a49496e    ONLINE       0     0     0

That resolves my issue, cheers.

3 Likes
6

If i recall correctly, using the WWN IDs [“double-doubleU-N”] (“World Wide Numbers”) is actually quite smart - those should be factory-printed on the physical device itself - part of the serial number should be a component of it. This makes it easier, in a hot-swap array scenario, to identify and just pull-and-replace the failed drive.

Although, the WWNs / serial numbers are usually printed on the butt-side, not the front, where the SATA/SAS connectors are - sticking DIY-labels on the visible end might be beneficial - that’s what i did.

I’m still not quite sure why we’re talking about PARTUUIDs, but i’m sure OP has a reasonable use case. :wink:

7

I like the idea of the WWN’s, but usually use the serial number version, when I make arrays.

Some OS’s seem to mess with the last 1 or 2 digits of the WWN’s, for some reason. I have no idea why…

Also no idea why the system list both the wwn and the serial line in the same folder, instead of separating them into /by-id and /by-uniqueid or some such. but is handy when mixing fleets of sas and sata, if you are only single lane-ing traffic, so dont care too much (I am not an enterprise user, and this hobbles the bi-directional possibility… but home user burstiness makes it not necessary)

oh, and the part uuid was not needed, just me messing about having a play with different folders, presuming it would assemble

1 Like
8

indeed, you’re providing an additional proof of concept, on-topic, for the OP :smiley::+1:

2 Likes