[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: 27.12.2025

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: 27.12.2025

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.

 

[gea]

Letztlich also ein Netzwerkproblem. Insbesondere wenn man mehrere nics im Server hat, gibts da gerne Probleme, vor allem wenn die im gleichen subnet sind. Bei ESXi muss man mit vmkernel extra aufpassen.

Hauptsache Problem gefunden und gelöst.

 

[besterino]

Bei ESXi war ich mit den virtuellen NICs bei ca. 25Gbit an einem harten Limit. Mehr ging nur mit SRIOV oder NIC per Passthrough durch.

 

[besterino]

Vor allem für mich:

Nach einem beherzten "pkg update" auf meinem Backup Solaris 11.4 Host zu Oracle Solaris "11.4.81.193.1" war die Napp-It Weboberfläche nicht mehr erreichbar. Der Browser zeigte mir nur "TLS-Handshake mit [IP] wird durchgeführt..." und brach dann ab mit "Fehler: Netzwerk-Zeitüberschreitung"

Also hab ich die beiden Befehle nach gea's Website ausgeführt:
ln -s /lib/libssl.so /usr/lib/libssl.so.1.0.0
ln -s /lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0

Ein reboot danach allein half nicht (wie so häufig bei Solaris), sondern ich musste über poweroff einen Neustart machen. Dann war die Weboberfläche wieder da, aber jetzt begrüßt mich ein freundliches "sudo: PAM account management error: Permission denied sudo: a password is required."

Nappit war noch ein etwas angestaubtes Napp-It Pro 22.03b... *hust*
Da die Weboberfläche ja nicht erreichbar war, hab ich das über die Konsole mit "wget -O - www.napp-it.org/nappit | perl" auf den aktuellen Stand gebracht.

Danach musste ich noch einmal ein neues Passwort für napp-it vergeben (sudo passwd napp-it) und ich war wieder online. Wahrscheinlich hätt's schon das getan ohne das Napp-it Update.

@gea: Jetzt bin ich auf Pro 22.03h - kann ich einfach die aktuelle 26.01 runterladen und aktivieren oder bräuchte ich eine neue Lizenz?

 

[gea]

Die ln auf das aktuelle OpenSSL und das passwort für den user napp-it sind für neuestes Solaris nötig. Der user napp-it kann sich zwar nicht anmelden und wird nur für den webserver genutzt, sudo verlangt aber jetzt dennoch ein pw.

Für das Update auf 26.01 kann man den alten Key nehmen oder einen 2day evalkey.

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Solaris

napp-it.org - ZFS NAS SAN Server mit einer durch den Benutzer anpassbaren Weboberfläche // All In One server = virtualisierter lauffähiger ZFS-Server

www.napp-it.de

 

[besterino]

Gibt es eigentlich bei OpenZFS eine Möglichkeit, einen abgebrochenen Replication Stream (initiiert über napp-it) wieder aufzunehmen / fortzusetzen?

 

[gea]

ja, gibt es mit bookmarks.
Habe ich aber noch nicht in napp-it eingebaut. Dabei wird der Ziel ZFS snap angelegt, auch wenn die Replikation nicht erfolgreich war, so dass man die Übertragung fortsetzen kann. Ist dann halt nicht mehr so klar wie bisher. Jetzt bedeutet ein Ziel Snap dass die Übertragung erfolgreich war.

 

[besterino]

Ok, wenn ich das richtig verstanden habe, muss man das mit einem Parameter explizit vorgeben. Mit Napp-it ist komischer weise die Replikation eines größeren Datasets (~2TB) 2x nicht erfolgreich durchgegangen - manuell mit snap anlegen und den dann manuell über die CMD mit send|receive rüber replizieren dann schon.

 

[gea]

In der replication log Übersicht (Menü Jobs: replicate) oder dem last log (Menü Jobs: Datum) sollte die Ursache ersichtlich sein.

 

[pwnbert]

Also unsere "beliebte PCIe x16 zu 2x M.2 + PCIe x4 Bifurication-Riser-Karte" ist so ne Sache...

Hab da die 2 SVDEVs fürs Fusion Pool oben und... erstmal bissl geschreckt weil das Pool plötzlich offline war.
Habs jetzt mal neu gesteckt, evtl. ist sie schlecht im Slot gesessen (bauartbedingt aber so eine Sache).
Waren aber gleich beide Drives weg, nicht nur eins, drum gehe ich irgendwie davon aus, dass es irgendwas "vorn" bei den "common pins" sein muss...


Scrub dauert jetzt mal nen Tag. Bin gepannt.
Macht einen leicht nervös sowas... wobei ZFS/TrueNAS da eh unkompliziert ist, aber trotzdem.


Das ist halt ein bissl die Schattenseite vom Adaptergebastel.

Jetzt bin ich am Überlegen, wie ich das zukünftig mach... eigentlich wollte ich ja diese 2 SSDs + HBA mit dem Adapter im x16 Slot unterbringen, damit ich das gesamte TrueNAS in dem einen Slot hab.
Ob ich 1x davon auf den M.2 (CPU) Sockel am Mainboard stecken soll? Dann "zerfällt" mir der Mirror stattdessen. Weiss nicht, was besser ist.
Ein wenig ungut fühlt sich das danach an...

 

[besterino]

Ich hatte 5 der reinen m.2 Bifurcation Karten im Einsatz - 3x x16 auf 4x4m.2 und 2x auf 2x4m.2, 3x Asus, 1x AsrockRack, 1x Supermicro, von PCIe Gen3 bis Gen5. Ich hatte mit keiner irgendwelche Issues (betrieben mit ADATA, Samsung, Lexar und Corsair NVME).

Problematisch war nur, wenn man eine bestimmte Intel PCIe SSD mit anderen mischen wollte (wollte die Intel nicht).

 

[pwnbert]

Davon sprechen wir.

 

[BobbyD]

Davon sprechen wir.

Keine Probleme bisher. Ich will aber nicht ausschließen, dass sich das Teil negativ auf ASPM der angeschlossenen Geräte auswirken kann. Hab das aber nicht genauer verifiziert und die Karte aktuell auch nicht im Einsatz.

 

[pwnbert]

Ist auch erst nach 1/2 Jahr Betrieb aufgetreten. Vor ein paar Wochen. Einfach rebootet ohne was anzufassen und war wieder online. Jetzt nochmal. Hab jetzt neu gesteckt.

Macht einen trotzdem nervös, wenn das SVDEV vom 60tb Pool offline ist.

 

[gea]

OmniOS r151056k (2026-01-14)
Weekly release for w/c 12th of January 2026.

Release Notes

illumos based server OS with ZFS, Bhyve, DTrace, Crossbow, SMF and Linux zone support

omnios.org

This update requires a reboot

Security Fixes

Curl updated to version 8.18.0.
The bhyve mouse driver could de-reference a NULL pointer in some circumstances.

Other Changes

SMB Active Directory joins now fall back to seting the machine password via LDAP if kerberos fails. Many AD sites block kerberos for this.
NVMe devices used as a system boot device would previously end up with a single I/O queue, limiting performance.
NVMe devices could incorrectly return an error on queue saturation that is interpreted by ZFS as a device failure.

The IP Filter fragment cache table could become corrupt, resulting in a kernel panic.