Allgemeiner ZFS unter Debian Faden.

[bluestar]

Mit zfs send und zfs recv geht das ohne Probleme, wie gehst du denn im Detail vor?

[Knogle]

Mit zfs send und zfs recv geht das ohne Probleme, wie gehst du denn im Detail vor?

Ich will im Grunde rekursiv alle Datasets zum neuen Pool schieben der unencrypted ist.
Also im Grunde alles was auf dem pool "rpool" ist, soll auf den Pool "rpool0" drauf.

Hier mal ein

Code: Alles auswählen

zfs list

auf meinem System

Code: Alles auswählen

root@debian:/home/chairman# zfs list
NAME                             USED  AVAIL     REFER  MOUNTPOINT
bpool                            408M  3.23G       96K  /boot
bpool/BOOT                       394M  3.23G       96K  none
bpool/BOOT/debian                394M  3.23G      168M  /boot
rpool                           2.44T  1.08T      192K  /
rpool/ROOT                      20.2G  1.08T      192K  none
rpool/ROOT/debian               20.2G  1.08T     17.4G  /
rpool/home                      2.37T  1.08T     2.17T  /home
rpool/home/root                 4.87M  1.08T     1.25M  /root
rpool/opt                       1.60G  1.08T     1.16G  /opt
rpool/swap                      34.0G  1.11T      116K  -
rpool/tmp                       5.35M  1.08T     1.73M  /tmp
rpool/usr                       19.1M  1.08T      192K  /usr
rpool/usr/local                 18.9M  1.08T     11.7M  /usr/local
rpool/var                       7.30G  1.08T      192K  /var
rpool/var/cache                 2.90G  1.08T     2.90G  /var/cache
rpool/var/games                  196K  1.08T      196K  /var/games
rpool/var/lib                   2.84M  1.08T      192K  /var/lib
rpool/var/lib/AccountsService   2.65M  1.08T      248K  /var/lib/AccountsService
rpool/var/log                   4.35G  1.08T     1.35G  /var/log
rpool/var/spool                 6.47M  1.08T      308K  /var/spool
rpool/var/tmp                   34.4M  1.08T     34.3M  /var/tmp

Aktuell unter meinem Debian RAID 0 Pool mit ZFS ist die Performance ziemlich begrenzt. Wenn ich eine mit /dev/urandom 16G erzeugte Datei kopiere ist das ganze unterirdisch.
Mit einem mdadm RAID 0 und XFS komme ich auf 6GB/s.
Liegt das vielleicht daran, dass die ZFS Native Encryption im Gegensatz zu LUKS nicht hardwarebeschleunigt ist? Oder kann das an ZFS "liegen"?

[bluestar]

Ich will im Grunde rekursiv alle Datasets zum neuen Pool schieben der unencrypted ist.
Also im Grunde alles was auf dem pool "rpool" ist, soll auf den Pool "rpool0" drauf.

Eigentlich sollte das so klappen:

Code: Alles auswählen

zfs send rpool/ROOT | zfs receive -o encryption=off rpool0/ROOT

(Ich hab gerade keinen Testpool greifbar, sonst würde ich's noch mal probieren) Und diesen Schritt wiederholst du für alle Dateisysteme in der ersten Ebene:

* rpool/home
* rpool/opt
* rpool/swap
* rpool/tmp
* rpool/usr
* rpool/var

Aktuell unter meinem Debian RAID 0 Pool mit ZFS ist die Performance ziemlich begrenzt. Wenn ich eine mit /dev/urandom 16G erzeugte Datei kopiere ist das ganze unterirdisch.

Da wären ein paar Hardware-Facts und auch mal eine genaue Kopierbeschreibung sinnvoll.

Mit einem mdadm RAID 0 und XFS komme ich auf 6GB/s.

Eine Vermutung hab ich schon mal, dass hier statt kopiert nur Blocks neu referenziert werden um das genau zu analysieren müsstest du deinen Vergleichsaufbau exakt skizzieren.

Liegt das vielleicht daran, dass die ZFS Native Encryption im Gegensatz zu LUKS nicht hardwarebeschleunigt ist? Oder kann das an ZFS "liegen"?

Welche ZFS Version nutzt du denn?

[Knogle]

Vielen Dank, das werde ich mal probieren!!

Zu meinem Aufbau:
Jetzt in meinem System aktuell habe ich 4x NVMe SSDs vom Typ Seagate FireCuda 510 1TB. Die sind alle jeweils mit 4x PCIe 3.0 Lanes angebunden.
Der ZFS Pool wurde wie folgt erzeugt, und geht als stripe über die 4 SSDs.

Code: Alles auswählen

zpool create \
    -o ashift=12 \
    -O encryption=aes-256-gcm \
    -O keylocation=prompt -O keyformat=passphrase \
    -O acltype=posixacl -O canmount=off -O compression=lz4 \
    -O dnodesize=auto -O normalization=formD -O relatime=on \
    -O xattr=sa -O mountpoint=/ -R /mnt \
    rpool /dev/nvme[0-3]n1p4

Code: Alles auswählen

/tmp

ist bei mir nicht als tmpfs gemountet, sondern auf der Platte.
Daher habe ich in meinen Tests 3x eine 16GB Datei mit

Code: Alles auswählen

/dev/urandom

erstellt, und 3x mit

Code: Alles auswählen

/dev/zero

.
Die habe ich dann von

Code: Alles auswählen

/tmp

auf

Code: Alles auswählen

/home

kopiert.

Code: Alles auswählen

sudo modinfo zfs | grep version 

sagt

Code: Alles auswählen

version:        2.0.3-9
srcversion:     589A10A280F2E97C4C1E9F6
vermagic:       5.10.0-9-amd64 SMP mod_unload modversions 

Was weiterhin ziemlich dauert: Ich mülle /tmp ziemlich oft mit Buildprojekten zu, da ich froh bin, dass nach dem nächsten Start der Ordner wieder leer ist. Wie zuvor beim "Vanilla" Debian, ist mein /tmp nicht als tmpfs gemountet. Das Problem jedoch: Je nachdem wieviel da drin ist, dauert das löschen des Inhalts aus dem /tmp Ordner manchmal bis zu 1:30 Minuten. Beim ext4 war das aus irgendeinem Grund nie in Form irgendeiner Verzögerung beim Startvorgang spürbar. Kommt man also für /tmp doch nicht um ein tmpfs drum herum bei ZFS?

[bluestar]

Code: Alles auswählen

/tmp

ist bei mir nicht als tmpfs gemountet, sondern auf der Platte.
Daher habe ich in meinen Tests 3x eine 16GB Datei mit

Code: Alles auswählen

/dev/urandom

erstellt, und 3x mit

Code: Alles auswählen

/dev/zero

.
Die habe ich dann von

Code: Alles auswählen

/tmp

auf

Code: Alles auswählen

/home

kopiert.

in dem ZFS sind /home (rpool/home) und /tmp (rpool/tmp) zwei unterschiedliche Dateisysteme, du könntest mal von /tmp nach /tmp deine Testdateien kopieren und die Performance messen, das sollte deutlich schneller sein als von /tmp nach /home zu kopieren.

[Knogle]

Ah herzlichen Dank für den Hinweis. Was passiert da genau wenn man von einem Dataset auf ein anders schreibt?
Also wenn ich von /tmp auf /tmp schreibe, liege ich ebenfalls wie bei dem mdadm RAID0 bei ca. 5,4GB/s.

Ich bin gerade wieder bei dem Kopierproblem dabei.

Mit

Code: Alles auswählen

zfs send rpool/ROOT | zfs receive -o encryption=off rpool0/ROOT

werden auf dem Zielpool nur leere Datasets erstellt.

Was ich gestern probiert habe:

Code: Alles auswählen

zfs send -v -w -R  rpool/home@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/home/root@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/cache@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/games@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/log@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/tmp@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/opt@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/swap@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/usr@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/usr/local@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  bpool/BOOT@umzug1 | zfs recv -v -d   bpool0
zfs send -v -w -R  bpool/BOOT@umzug1 | zfs recv -v -d -F  bpool0
zfs send -v -w -R  bpool/BOOT/debian@umzug1 | zfs recv -v -d -F  bpool0

Das Problem dabei: Der wollte dann bei jedem der neuen Zielpools einen Key für Encryption haben.

Code: Alles auswählen

-o encryption=off

geht leider auch nicht, dann mackert er mit folgender Meldung.

Code: Alles auswählen

receiving full stream of rpool/home@zfs-auto-snap_daily-2021-10-11-0711 into rpool0/home@zfs-auto-snap_daily-2021-10-11-0711
cannot receive new filesystem stream: encryption property 'encryption' cannot be set or excluded for raw streams.

Auch mit

Code: Alles auswählen

-x encryption

klappt das nicht da ich die Encryption wohl nicht rauskriege.
Bei zfs send muss ich -w für Raw nutzen, da man laut der dortigen Fehlermeldugn keine encrypted Pools ohne -w für Raw übertragen kann.

[bluestar]

Ah herzlichen Dank für den Hinweis. Was passiert da genau wenn man von einem Dataset auf ein anders schreibt?
Also wenn ich von /tmp auf /tmp schreibe, liege ich ebenfalls wie bei dem mdadm RAID0 bei ca. 5,4GB/s.

Ich bin gerade wieder bei dem Kopierproblem dabei.

Du musst dir jedes ZFS Dataset wie ein eigenes Dateisystem auf einer Platte vorstellen, innerhalb des Datasets wird mit Referenzen kopiert (=schnell) und sobald Daten das Dataset verlassen, müssen diese echt dupliziert werden, was natürlich entsprechend länger dauert.

[bluestar]

Was ich gestern probiert habe:

Code: Alles auswählen

zfs send -v -w -R  rpool/home@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/home/root@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/cache@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/games@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/var/log@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/tmp@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/opt@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/swap@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/usr@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  rpool/usr/local@umzug1 | zfs recv -v -d   rpool0
zfs send -v -w -R  bpool/BOOT@umzug1 | zfs recv -v -d   bpool0
zfs send -v -w -R  bpool/BOOT@umzug1 | zfs recv -v -d -F  bpool0
zfs send -v -w -R  bpool/BOOT/debian@umzug1 | zfs recv -v -d -F  bpool0

Also -R und -w kannst du nicht verwenden, wenn du die Verschlüsselung beim Empfang deaktivieren möchtest, versuch es mal ohne.

[Knogle]

Hey danke, ich habe es am Ende hingekriegt indem ich das ganze mit rsync auf einen neuen Pool geschoben habe, und von dort dann wieder zurück.
Gibt es eigentlich jemanden der wieder zurück auf ein "normales" Dateisystem gewechselt ist, nach einem Exkurs zu ZFS?
Ich persönlich habe schon ein paar mal vom ZFS Snapshot Feature gebraucht gemacht, indem ich ab und zu mal einen Rollback machen musste, nachdem apt nach irgendeinem Update ein benötigtes ZFS Paket entfernt habe. Aber sonst aktuell nicht.
Deswegen werde ich wohl für meinen Daily wieder zurück auf EXT4/XFS wechseln, und ZFS wird bei mir dem TrueNAS Server und der pfSense vorbehalten bleiben.