[Sammelthread] ZFS Stammtisch

[AliManali]

Hier beim ersten Durchgang:

Und beim zweiten:

Beides mal vom napp-it 1 Micron 5300 Pro auf napp-it 2 Micron 5300 Pro. Läuft atm nichts auf den betreffenden SSD.

 

[gea]

Falls es Probleme mit einer einzelnen Platte oder einem Anschluss geben sollte, sieht man das nur unter Last im Vergleich zu den anderen Poolplatten. Man muss das auch lokal testen und nicht mit virtuellen Platten eines NFS shares, sondern auf dem System wo die Platten lokal angeschlossen sind.

Der erste Durchlauf ist unwichtig, nur der zweite ist wichtig.

 

[AliManali]

Wie gesagt, das Problem besteht sowohl auf der Ziel SSD als auch auf den Ziel SAS Pools. Wenn ich napp-it neu starte, ist das Problem weg. Wenn es mal langsam ist, kann ich auch mit dd ein Testfile schreiben. Das schreibt dann gerade mal mit 60MB/s auf die SSD. Starte ich napp-it neu, mit 490 MB/s.

Beitrag automatisch zusammengeführt: Gestern um 15:26

4kn oder 512e ist unter ZFS egal, beide werden identisch mit ashift 12 genutzt. Umformatieren ist bei ZFS kein Thema, ganz im Gegenteil eher kontraproduktiv, wäre aber z.B. bei Windows 7 oder XP nötig weil das keine 4kn kann sondern nur 512e.

Wo sehe ich nochmal, was für ein ashift ich verwendet habe für die Platten? Ich habe das auf default gelassen.

Ich trau da echt Dir eher als Gemini. Aber die beharrt darauf, dass ich die HDD umformatieren soll, und dadurch das Problem gelöst wird:

Spoiler: KI Antwort

Das ist ein klassischer "Gea-Moment" – technisch absolut präzise, aber er bezieht sich hier rein auf die logische Ebene von ZFS (das ashift-Alignment), während wir über die physikalische Ebene des HBAs (die 520-Byte-Sektoren) sprechen.

Die "Übersetzung" von Geas Aussage:​

Gea hat recht: Ob eine Platte dem System 512e (emuliert) oder 4kn (nativ) meldet, ist ZFS egal, solange man ashift=12 (für 4K-Blöcke) nutzt. Das sorgt dafür, dass die Schreibvorgänge sauber ausgerichtet sind.

ABER: Das gilt nur für Platten, die bereits im "Standard-Format" (512 oder 4096 Byte) sind. Deine Platten haben aktuell 520 Byte. Das ist kein ZFS-Problem, sondern ein SCSI/HBA-Problem.

• 520 Byte = 512 Byte Daten + 8 Byte Prüfsumme (Data Integrity Field - DIF).
• ZFS will aber 512 Byte (oder 4096).
• Der HBA muss also bei jedem einzelnen Schreibvorgang diese 8 Byte "Sonderlocke" berechnen oder ignorieren.

Warum Gea "kontraproduktiv" sagt:​

Er meint damit: Wenn du eine Platte hast, die physikalisch 4K Sektoren hat, ist es dumm, sie auf 512 Byte zu zwingen, weil die Platte dann intern "Read-Modify-Write" Zyklen machen muss. Das macht alles extrem langsam.

Das Missverständnis auflösen:​

Du musst die Platten nicht von "512 auf 4k" umformatieren, sondern von "520 (SAS-Spezial) auf 512 oder 4096 (Standard)".

Solange sie auf 520 Byte stehen, passiert Folgendes:

1. Der Solaris-Treiber sieht eine Platte mit einer "unsupported sector size".
2. Er versucht sie trotzdem anzusprechen, aber der HBA-Chip (dein LSI 3008) muss Schwerstarbeit leisten, um das ZFS-Format in das 520-Byte-Format der Platte zu quetschen.
3. Das ist der Grund, warum dein HBA "dicht" macht und am Ende sogar die SSD mit ausbremst.

Dein nächster Schritt (um Gea abzuholen):​

Frag ihn mal konkret:

"Die Platten kommen aus einem NetApp/EMC System und sind aktuell auf 520 Byte formatiert. Sollte ich sie mit sg_format auf 512 oder 4096 umstellen, um die Latenz am HBA zu verringern?"

Wetten wir? Dann wird er sagen: "Ah, 520 Byte! Ja, das muss weg. Das ist kein Standard-Speicherformat für normale Betriebssysteme."

Soll ich dir schon mal den Befehl vorbereiten, mit dem du eine der SAS-Platten testweise auf echte 512 Byte (oder 4k) umformatierst? (Das dauert pro Platte leider ein paar Stunden, aber danach ist der "Spuk" am HBA vorbei).

 

[Trambahner]

4kn oder 512e ist unter ZFS egal, beide werden identisch mit ashift 12 genutzt.

Ganz "egal" kann ich nicht ganz bestätigen. Beides ist zwar ashift=12, bei den SN850X hatte ich nach umformatieren des Namespace von default 512e auf 4kn etwas besseren Durchsatz unter PVE 8 / Debian12. Da reden wir aber im Bereich von vielleicht 10-15%, nicht um Faktoren.
Bei PVE 9 / Debian 13 hab ichs nicht verglichen mit den gleichen SSDs.

 

[gea]

Wie gesagt, das Problem besteht sowohl auf der Ziel SSD als auch auf den Ziel SAS Pools. Wenn ich napp-it neu starte, ist das Problem weg. Wenn es mal langsam ist, kann ich auch mit dd ein Testfile schreiben. Das schreibt dann gerade mal mit 60MB/s auf die SSD. Starte ich napp-it neu, mit 490 MB/s.

Beitrag automatisch zusammengeführt: Gestern um 15:26

Wo sehe ich nochmal, was für ein ashift ich verwendet habe für die Platten? Ich habe das auf default gelassen.

Ich trau da echt Dir eher als Gemini. Aber die beharrt darauf, dass ich die HDD umformatieren soll, und dadurch das Problem gelöst wird:

Spoiler: KI Antwort

Das ist ein klassischer "Gea-Moment" – technisch absolut präzise, aber er bezieht sich hier rein auf die logische Ebene von ZFS (das ashift-Alignment), während wir über die physikalische Ebene des HBAs (die 520-Byte-Sektoren) sprechen.

Die "Übersetzung" von Geas Aussage:​

Gea hat recht: Ob eine Platte dem System 512e (emuliert) oder 4kn (nativ) meldet, ist ZFS egal, solange man ashift=12 (für 4K-Blöcke) nutzt. Das sorgt dafür, dass die Schreibvorgänge sauber ausgerichtet sind.

ABER: Das gilt nur für Platten, die bereits im "Standard-Format" (512 oder 4096 Byte) sind. Deine Platten haben aktuell 520 Byte. Das ist kein ZFS-Problem, sondern ein SCSI/HBA-Problem.

• 520 Byte = 512 Byte Daten + 8 Byte Prüfsumme (Data Integrity Field - DIF).
• ZFS will aber 512 Byte (oder 4096).
• Der HBA muss also bei jedem einzelnen Schreibvorgang diese 8 Byte "Sonderlocke" berechnen oder ignorieren.

Warum Gea "kontraproduktiv" sagt:​

Er meint damit: Wenn du eine Platte hast, die physikalisch 4K Sektoren hat, ist es dumm, sie auf 512 Byte zu zwingen, weil die Platte dann intern "Read-Modify-Write" Zyklen machen muss. Das macht alles extrem langsam.

Das Missverständnis auflösen:​

Du musst die Platten nicht von "512 auf 4k" umformatieren, sondern von "520 (SAS-Spezial) auf 512 oder 4096 (Standard)".

Solange sie auf 520 Byte stehen, passiert Folgendes:

1. Der Solaris-Treiber sieht eine Platte mit einer "unsupported sector size".
2. Er versucht sie trotzdem anzusprechen, aber der HBA-Chip (dein LSI 3008) muss Schwerstarbeit leisten, um das ZFS-Format in das 520-Byte-Format der Platte zu quetschen.
3. Das ist der Grund, warum dein HBA "dicht" macht und am Ende sogar die SSD mit ausbremst.

Dein nächster Schritt (um Gea abzuholen):​

Frag ihn mal konkret:


Wetten wir? Dann wird er sagen: "Ah, 520 Byte! Ja, das muss weg. Das ist kein Standard-Speicherformat für normale Betriebssysteme."

Soll ich dir schon mal den Befehl vorbereiten, mit dem du eine der SAS-Platten testweise auf echte 512 Byte (oder 4k) umformatierst? (Das dauert pro Platte leider ein paar Stunden, aber danach ist der "Spuk" am HBA vorbei).

Ganz "egal" kann ich nicht ganz bestätigen. Beides ist zwar ashift=12, bei den SN850X hatte ich nach umformatieren des Namespace von default 512e auf 4kn etwas besseren Durchsatz unter PVE 8 / Debian12. Da reden wir aber im Bereich von vielleicht 10-15%, nicht um Faktoren.
Bei PVE 9 / Debian 13 hab ichs nicht verglichen mit den gleichen SSDs.

Könnte ich mir nur vorstellen mit herstellerspezifischen SAS Formaten wie 520 Byte

ansonsten mit den Befehlen
zpool iostat -vly 3 2
zpool -rv
den Pool und die Plattenauslastung analysieren. Meist findet man damit Performance Problem wegen einzelner Platten

zdb -C | grep ashift
zeigt die ashift der vdevs

 

[AliManali]

Habe noch die Firmware v 14.00 drauf. Versuche gerade alles, um die v16 drauf zu kriegen. Bringe weder FreeDOS zum laufen, noch die EFI Shell. Gebe alles. Glaube ich muss mal den HBA noch in den Lab Rechner einstecken, wenn das so weiter geht.

 

[AliManali]

Habe jetzt die Broadcom LSI 3008 v16.00.14 drauf. Problem wurde besser aber noch nicht immer komplett gelöst.

Das Problem war/ist scheinbar folgendes: die vmkernel für die NFS Shares liegen in anderen VLANs, bzw. noch an der Produktiv Firewall. Die beiden 10 Gbit NICs am Switch hinter der Lab Firewall. Ich dachte eigentlich wenn ich die Shares direkt zu der 10 Gbit NIC/Portgruppe mache, spielt das keinen Rugel, ob die vmkernel in anderen Netzen liegen. Anscheinend aber doch... Witzig ist, dass wenn ich napp-it neu starte es ganz ordentlich läuft. Erst beim zweiten Copy Job bricht die Leistung massiv ein. Kann mir da auch nicht wirklich einen Reim darauf machen.

Ist aber kein Beinbruch. Wenn ich das Netzwerk dann umgebaut habe, werden die napp-it wieder je nur eine NIC haben, und die vmkernel in der entsprechenden Portgruppe sein.

Kopiere ich lokal zwischen den Pools läuft es sehr geschmeidig. z.B. von SSD zu dem SAS Pool mit 250-300 MB/s.

ashift ist überall auf 12.