zfs pools migrieren zwischen LXCs?

[UdoB]

Für den Trick...

In dem Pool existiert bereits ein raidz-vdev. (#34).

Somit ist nach meinem Verständnis das Entfernen eines beliebigen vdevs nicht mehr möglich, egal ob das eine einzelne Platte oder ein Mirror ist.

Ich lasse ich mich aber wirklich gerne vom Gegenteil überzeugen!

---
Spezialisten könnten eventuell per "zdb rollback" alle Transaktionen seit dem "add" rückgängig machen. Aber in der Liga spiele ich nicht...

 

[news]

Danke @UdoB ich habe es grade versucht und hatte mit meiner ZFS Version kein Erfolg.

zfs-2.2.7-pve1
zfs-kmod-2.2.6-pve1

Die Testumgebung waren 6x 1GB Raw-Dateien, die über /dev/loopN verfügbar gemacht wurden.
Mit diesen Loop-Device konnte ich ein ZFS Pool "tpool" erzeugen:
zpool create tpool [-n] raidz1 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
zfs set atime=off tpool
zfs set com.sun:auto-snapshot=false tpool

zpool list -v tpool
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tpool       3.75G   233K  3.75G        -         -     0%     0%  1.00x    ONLINE  -
  raidz1-0  3.75G   233K  3.75G        -         -     0%  0.00%      -    ONLINE
    loop0      1G      -      -        -         -      -      -      -    ONLINE
    loop1      1G      -      -        -         -      -      -      -    ONLINE
    loop2      1G      -      -        -         -      -      -      -    ONLINE
    loop3      1G      -      -        -         -      -      -      -    ONLINE

Das fehlerhafte ZFS Command konnte ich identifiziere:
zpool add tpool [-n] -f /dev/loop4

zpool list -v tpool
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tpool       4.69G   298K  4.69G        -         -     0%     0%  1.00x    ONLINE  -
  raidz1-0  3.75G   284K  3.75G        -         -     0%  0.00%      -    ONLINE
    loop0      1G      -      -        -         -      -      -      -    ONLINE
    loop1      1G      -      -        -         -      -      -      -    ONLINE
    loop2      1G      -      -        -         -      -      -      -    ONLINE
    loop3      1G      -      -        -         -      -      -      -    ONLINE
  loop4        1G    14K   960M        -         -     0%  0.00%      -    ONLINE

zpool status tpool -v
  pool: tpool
 state: ONLINE
config:
    NAME        STATE     READ WRITE CKSUM
    tpool       ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        loop0   ONLINE       0     0     0
        loop1   ONLINE       0     0     0
        loop2   ONLINE       0     0     0
        loop3   ONLINE       0     0     0
      loop4     ONLINE       0     0     0

Auch kann man aus dem einzelnen Device loop4 eine Mirror erzeugen:
zpool attach tpool /dev/loop4 /dev/loop5

zpool status tpool -v
  pool: tpool
 state: ONLINE
  scan: resilvered 22.5K in 00:00:00 with 0 errors on Thu Jan 30 21:45:03 2025
config:
    NAME        STATE     READ WRITE CKSUM
    tpool       ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        loop0   ONLINE       0     0     0
        loop1   ONLINE       0     0     0
        loop2   ONLINE       0     0     0
        loop3   ONLINE       0     0     0
      mirror-1  ONLINE       0     0     0
        loop4   ONLINE       0     0     0
        loop5   ONLINE       0     0     0

So wären die Daten, die im ZFS Stripe mirror-1 angelegt werden, sicherer.

Man kann darauf auch wirklich schreiben:

dd if=/dev/random of=/tpool/a.raw bs=1M count=1024 status=progress
1026555904 Bytes (1,0 GB, 979 MiB) kopiert, 7 s, 142 MB/s
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 7,37372 s, 146 MB/s

Leider konnte ich mich an das Verfahren der Trennung nicht mehr erinnern.
Also bleibt nur noch das Kopieren, evtl. über zfs send | zfs receive auf einen neuen Pool, um die Daten anschließen auf den alten/ neuerzeugten Pool zurück zu spielen.