[Sammelthread] ZFS Stammtisch

Hier beim ersten Durchgang:

Screenshot 2025-12-27 125858.jpg


Und beim zweiten:

Screenshot 2025-12-27 130736.jpg


Beides mal vom napp-it 1 Micron 5300 Pro auf napp-it 2 Micron 5300 Pro. Läuft atm nichts auf den betreffenden SSD.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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.
 
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:

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:

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).
 
Zuletzt bearbeitet:
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.
 
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:



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:

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
 
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.
 
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.
 
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.
 
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.
 
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?
 
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.
 
Gibt es eigentlich bei OpenZFS eine Möglichkeit, einen abgebrochenen Replication Stream (initiiert über napp-it) wieder aufzunehmen / fortzusetzen?
 
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.
 
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.
 
In der replication log Übersicht (Menü Jobs: replicate) oder dem last log (Menü Jobs: Datum) sollte die Ursache ersichtlich sein.
 
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. :fresse:
Macht einen leicht nervös sowas... wobei ZFS/TrueNAS da eh unkompliziert ist, aber trotzdem. :rolleyes:


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... :rolleyes:
 
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).
 
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.
 
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.
 
OmniOS r151056k (2026-01-14)
Weekly release for w/c 12th of January 2026.

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.
 
Also unsere "beliebte PCIe x16 zu 2x M.2 + PCIe x4 Bifurication-Riser-Karte" ist so ne Sache...
...
1768584609673.png
So, ich hab hier jetzt einen Fehler, weswegen das Pool "not healthy" ist.
1768584631252.png
Einen Scrub hab ich laufen lassen, hat sich dadurch nicht geändert.

Bekomm ich diesen Checksummenfehler irgendwie korrigiert, so dass das Pool wieder healthy ist?
Im Idealfall mit der TNS GUI?
 
Also unsere "beliebte PCIe x16 zu 2x M.2 + PCIe x4 Bifurication-Riser-Karte" ist so ne Sache...

Das Ding lief bei mir überhaupt nur, wenn PCIe gen auf 3 begrenzt ist. Bei gen4 haufenweise Buserrors und Grakas die oben drin stecken brechen mir auf gen1 und geruckel ein.
=> Das Ding ist bei mir insta nach nach Versuchen in den Elektroschrott gegangen.

Vorsicht auch bei der Asrock Rack RB4M2 für 15 Euro und drunter. Gen3 läuft, Gen4 nicht in allen der m2-Steckplätzen; nur auf denen mit kurzen Leiterbahnen. Nicht umsonst gibts davon eine neuere PCIe gen4-Version.
 
Meine CPU kann eh nur PCIe 3.0 ...

Ich "brauche" das Ding halt, damit ich die Kiste effektiv vollstopfen kann. Geht zwar auch anders, aber mir wäre es lieb, wenns so gehen würde.

Ändert aber nix an meinem Problem, das jetzt nun mal da ist. :fresse:
 
Hab die relevanten Kisten alle auf die Asus Hyper M2 gen5 umgestellt. Läuft problemfrei. Keine Lust auf Bus-Stress und korrupte Daten.
Klar, die hat keinen x8 Slot.
 
Ja, das ist die Variante B... aber wie bekomm ich den Fehler da nun raus? Laufen tuts ja und korregierbar sollte das ja sein...
 
#zpool clear tank

tank = poolname. Wenn der "RAIDZ1" sein sollte (Screenshot sagt es ja so), dann also "zpool clear RAIDZ1" auf der Shell.

Das löscht den Errorcount des entsprechenden Pools.
Gui weiss ich leider nicht, da ich Truenas nicht einsetze.
 
Zuletzt bearbeitet:
Code:
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.33-production+truenas] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       KINGSTON SFYRD4000G
Serial Number:                      50026B7686FXXXXX
Firmware Version:                   EIFK31.7
PCI Vendor/Subsystem ID:            0x2646
IEEE OUI Identifier:                0x0026b7
Total NVM Capacity:                 4,000,787,030,016 [4.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4,000,787,030,016 [4.00 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            0026b7 686f7c3f65
Local Time is:                      Sat Jan 17 10:51:04 2026 CET
Firmware Updates (0x12):            1 Slot, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005d):     Comp DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x08):         Telmtry_Lg
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     84 Celsius
Critical Comp. Temp. Threshold:     89 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     8.80W       -        -    0  0  0  0        0       0
 1 +     7.10W       -        -    1  1  1  1        0       0
 2 +     5.20W       -        -    2  2  2  2        0       0
 3 -   0.0620W       -        -    3  3  3  3     2500    7500
 4 -   0.0620W       -        -    4  4  4  4     2500    7500

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        27 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    1,405,234 [719 GB]
Data Units Written:                 995,483 [509 GB]
Host Read Commands:                 11,875,918
Host Write Commands:                18,861,285
Controller Busy Time:               44
Power Cycles:                       60
Power On Hours:                     10,180
Unsafe Shutdowns:                   54
Media and Data Integrity Errors:    0
Error Information Log Entries:      107
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 2:               53 Celsius

Error Information (NVMe Log 0x01, 16 of 63 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS  Message
  0        107     0  0x0016  0x4004 0x102c            0     0     -  Invalid Field in Command
  1        106     0  0x100d  0x4004 0x102c            0     0     -  Invalid Field in Command
  2        105     0  0x0007  0x4004      -            0     0     -  Invalid Field in Command

Self-test Log (NVMe Log 0x06)
Self-test status: No self-test in progress
Num  Test_Description  Status                       Power_on_Hours  Failing_LBA  NSID Seg SCT Code
 0   Short             Completed without error               10100            -     -   -   -    -
 1   Short             Completed without error                9779            -     -   -   -    -
 2   Short             Completed without error                9313            -     -   -   -    -
 3   Short             Completed without error                9145            -     -   -   -    -
 4   Short             Completed without error                8977            -     -   -   -    -
 5   Short             Completed without error                8809            -     -   -   -    -
 6   Short             Completed without error                8641            -     -   -   -    -
 7   Short             Completed without error                8473            -     -   -   -    -
Hm, viele Unsafe Shutdowns, die andere ausm Mirror hat "nur" 7, davon gehen mindestens 3 auf die Reboots zurück. TrueNAS lässt dich mit dem Fehler nämlich nicht rebooten, da er beim runterfahren versucht das Pool zu mounten um es unmounten zu können, was natürlich nicht geht, wenns ein Kontaktproblem ist. Hätte man wsl. irgendwie forcen können. Hab halt einfach Hard-Reset gemacht über den NanoKVM. Bad Practice und so. :hmm: :fresse:

Diese Power Cycles bzw. Unsafe Shutdowns waren wohl echt total unbemerkt, die 2. SSD hat nur 13 Power Cycles und 7 unsafe shutdowns.
Krass, wie ZFS/TrueNAS das wegbügeln, dass man das nicht mal merkt...


Mal sehn, ob der Adapter jetzt richtig steckt.
Ich bin schon am überlegen ihn rauszuwerfen und ne Hyper Card zu nehmen (mit 3x SSD drauf, mit dem 5750G kann ich ja nur 3) und den HBA entsprechend schmal anzubinden (mit PCIe 3.0x1 oder x2 oder x4, mal sehn, wie das Setup so aussieht und was 10GbE mäßig noch kommt). Hätte den HBA gern an CPU Lanes gehabt... so muss ich mir die Sache genauer ansehen.
 
Ich betreibe seit 6 Jahren einen Homeserver mit OmniOS als Archiv und Datenspeicher im 24/7 Betrieb und lizensiertem napp-it. Ich habe dabei 6 WD Red Pro 4TB Disks in einem RAIDZ2 Pool laufen. Nun ist eine Disk ausgefallen und ich überlege bei dieser Gelegenheit alle Disks in 4TB WD Red SSDs zu tauschen. Macht dann überhaupt noch ein RAIDZ2 Sinn oder sollte ich den Pool anders aufbauen? Wenn ich SSDs verwende, sollte ich dann Parameter bei der Pool Gestaltung ändern oder die Defaultwerte nutzen?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh