[Sammelthread] ZFS Stammtisch

Ich habe in meinem RAIDZ2 ein einzelnes vdev mit 4x 12TB und 6x 14TB die 12TB-Platten durch 16er ersetzt. Einzeln mit Resilver nach jedem Tausch.
Nachdem alles fertig war, war die Anzeige der Größe noch wie zuvor, daher habe ich auf "Expand" gedrückt, was mit einem Fehler abbrach, dass sdb in Verwendung sei und man neustarten solle.
Nach dem Neustart wurde dann sda wieder als unassigned disk angezeigt, war aber im vdev trotzdem als online drin, das vdev war dennoch degraded.
Nun läuft wieder ein Resilver, um die sda wieder neu zu integrieren.

Eine Idee was da passiert ist und wie ich die Erweiterung dann erfolgreich durchführe? Ich tippe auf die Partitionen - da sind wohl ehem. Swap Paritionen drauf....

Infos:
Version:
TrueNAS-SCALE-23.10.1.3

Code:
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
Daten       109T  91.5T  17.6T        -         -     0%    83%  1.00x  DEGRADED  /mnt



NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0  14.6T  0 disk 
└─sda1        8:1    0  10.9T  0 part 
sdb           8:16   0  14.6T  0 disk 
└─sdb1        8:17   0  10.9T  0 part 
sdc           8:32   0  14.6T  0 disk 
└─sdc1        8:33   0  10.9T  0 part 
sdd           8:48   0  14.6T  0 disk 
└─sdd1        8:49   0  10.9T  0 part 
sde           8:64   0  12.7T  0 disk 
├─sde1        8:65   0     2G  0 part 
└─sde2        8:66   0  12.7T  0 part 
sdf           8:80   0  12.7T  0 disk 
├─sdf1        8:81   0     2G  0 part 
└─sdf2        8:82   0  12.7T  0 part 
sdg           8:96   0  12.7T  0 disk 
├─sdg1        8:97   0     2G  0 part 
└─sdg2        8:98   0  12.7T  0 part 
sdh           8:112  0  12.7T  0 disk 
├─sdh1        8:113  0     2G  0 part 
└─sdh2        8:114  0  12.7T  0 part 
sdi           8:128  0  12.7T  0 disk 
├─sdi1        8:129  0     2G  0 part 
└─sdi2        8:130  0  12.7T  0 part 
sdk           8:160  0  12.7T  0 disk 
├─sdk1        8:161  0     2G  0 part 
└─sdk2        8:162  0  12.7T  0 part

Ein
Code:
parted /dev/sdX resizepart 1 100%
für alle neue Platten mit anschließendem Neustart hat gereicht. Jetzt passts.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die habe ich mir auch bestellt. Evtl würde ich sogar probieren, neben dem kleinen SLOG noch den Rest als L2ARC-Parition zu nutzen.
 
Zuletzt bearbeitet:
Ich brauche wie gesagt nur eine. Reicht mir in dem Fall aus. Frage ist halt ob sie ne gute Wahl ist. Weil bei Thomas Krenn ja abgeraten wird.
TK hat nicht abgeraten, ich denke, Intel hat diese bei VMware einfach nur nicht für vSAN zertifizieren lassen, da sie nicht für diesen Zweck auf den Markt gebracht wurde. Deshalb auch der Punkt mit "no HCL".
Das eine dir reicht kannst nur du wissen, ich habe nur die Speichergröße korrigiert. 188 GB vs 118 GB ist dann doch ein Unterschied :).

Die habe ich mir auch bestellt. Evtl würde ich sogar probieren, neben dem kleinen SLOG noch den Rest als L2ARC-Parition zu nutzen.

Hatte ich mir auch erst überlegt, allerdings benötigt ein L2ARC auch wieder RAM und bis der zum Tragen kommt - zumindest bei meinem PVE, dümpelt die nur so hin. Ob es jetzt ein 118 GB Slog besser macht, sei mal dahingestellt ^^.

Allerdings werde ich mir davon wohl noch welche bestellen. Und meine betagte Crucial c300 128 GB damit ersetzten, die aktuell mein Solaris im Filer beherbergt
 
Zuletzt bearbeitet:
Pack mal Oracle Tablespaces and Logs drauf auf ne 900P/905P/P48yyX/P58yy=> wonnnnnderful. Gibt nix besseres für sowas ausser RAM. In StarWars-Worten "powerr......unlimittteddd powerrrrrrrrr".
Oder halt als Slog-Device für ZFS.
Die P1600X ist dafür sicher auch gut geeignet, solang die DB nicht zu gross und zu viele sequentielle Zugriffe anfallen (Oracle kann z.B. multiblock-reads für Full Table Scans, nicht nur 8k-weise).

Es ist so eine ******, dass dieser Geschäftszweig begraben wurde.
 
Zuletzt bearbeitet:
Gibt es eigentlich sinnvolle Gründe sich für oder gegen eine 512e HDD zu entscheiden wenn es auch eine 4kn Version gibt ? Mal aktuelle Preisunterschiede außenvorgelassen, die ich aktuell der Verfügbarkeit geschuldet sehe. Geht um die Toshiba MG09ACA 18 TB.
 
Ich wüßte keine.
ZFS nutzt sowohl bei 512e wie bei 4Kn physical 4K mit ashift 12.
 
Kann man die 512e nicht sogar eingenhändig "umformatieren"? Bei Toshiba weiß ich das nicht zu 100%, aber WD bzw HGST lässt das ohne großen Aufwand zu.
 
"Umformatieren?" Hast Du mal einen Link, was Du meinst / wie das geht? Ich hatte nämlich neulich erst geschaut, ob man Windows irgendwie zwingen kann, eine bestimmte Sectorsize und entsprechendes Alignment zu verwenden, war aber nicht erfolgreich.
 
War Seagate und nicht WD/HGST, aber grundsätzlich geht das:


Der Thread zeigt ein paar Kommandos dazu. Aber das Ändern der Sektorgröße führt unweigerlich dazu, dass die Platte dann leer ist. Also immer vorher sichern. ;) Und, meine 5-Minuten-Onlinerecherche zeigen gefühlt ein Bild, dass der Weg von 512 auf 4096 kein Problem ist, der Weg zurück aber schon.

Für weitere Recherche bietet sich auf jeden Fall die Suche nach "sg_format" und und "hdparm" an. Das Arch Wiki hat dazu auch ein bisschen was zum Lesen:

 
Danke! Ist aber leider auch nicht das, was ich suchte. =) Formatieren mit bestimmten Sektorgrößen geht ja quasi immer. Ich suchte eine Möglichkeit, die HDD vom OS anders zu erkennen, also das, was in dem Thread bei smartctl zu Logical block size und Physical block size rauskommt, zu manipulieren. Sorry, hier eher Offtopic.
 
Unter ZFS kann man mit ashift=9 ein neues vdev als 512B anlegen.
 
Es gibt da ein paar Problemchen bei Nutzung von zfs send/receive und der nativen (Open)ZFS Verschlüsselung, die du dir vielleicht vorher ansehen solltest.
Ein paar Problemchen ist gut. Vielen Dank für den Hinweis. Ich mache exzessiv Backups auf andere Dateisysteme und hoffe, dass mir der Laden nicht abbrennt. Aber das ZFS noch "einige Problemchen" hat, war mir bekannt. So lange es keine SILENT data corruption ist, geht es ja sogar noch.
 
Möchte hier nochmal wiederholen, was auch bei früheren "Problemchen" schon galt:
OpenZFS für Linux, FreeeBSD, Mac und Windows haben eine mittlerweile vollkommen neue Codebase (Fork) im vgl. zu Illumos. Openindian, OmniOS, SmartOS, Nexenta etc
Letzteres wird in sehr großen Umgebungen in Produktion erfolgreich eingesetzt, auch mit Verschlüsselung.
Man muss hier sehr strikt unterscheiden, ZFS ist nicht gleich ZFS.
cu
 
Prinzipiell gibt es keine fehlerfreie Software.

Es ist aber auch mein Eindruck dass die Stabilität von ZFS mit Oracle Solaris am Besten ist, gefolgt von Illumos. Wahr ist aber auch dass erkannte Fehler in ZFS on Linux relativ schnell angegengen werden. Da hat mal halt eine große Entwicklerbasis. Unschön ist aber dass jede der x Linux Distributionen auf einem anderen Release Stand ist und kritische Bugfixes erst mit Verspätung wenn überhaupt integriert werden oder nur irgendwann ein neues Major Release kommt.
 
Guten Abend,

ich bin noch unerfahren, was die zfs Welt angeht.
Aktuell läuft bei mir eine Owncloud-Instanz, an der ein per Passthrough durchgereichter Raidcontroller hängt.
Darüber läuft ESX 7 im aktuellen Build.

Controller: ist ein DELL PERC H710 an dem aktuell 3x 512 GB Desktop Samsung 850 SSDs hängen. Der Controller ist auf Admin Mode geflashed und wird im aktuellen 7er ESX als Avago (LSI) Logic Fusion-MPT 6GSAS SAS2308_2 PCI-Expres ausgelesen.
Board: B450 TOMAHAWK MAX II.
Der Controller steckt im 3.0 x16 Port
Eine alte nvidia GPU steckt im PCIe 2.0 x4
Eine WD Blue 1TB hängt per SATA am Board.
Es ist keine M2 verbaut.

Es gibt 2 Datastores:
D1 --> WD Disk, auf der auch ESX und die Owncloud VM läuft.
D2 --> Raidz mit dem 3 SSDs von oben. (hier bin ich mir nicht sicher, welchen Z ich gewählt habe, find die Einstellungen gerade nicht -.- )

Nun bin ich auf der Suche, nach dem Flaschenhals im System.

Zum Testen habe ich eine Windows Server VM laufen.

Wenn die VM in D1 läuft, sehen die Werte gut aus:
1708898411171.png

Migriere ich die VM in D2, ist Schreibrate extrem schlecht, hab mich sehr gewundert, warum es so ewig dauert bis die paar GB drüben sind.

1708898461248.png


Hat wer Idee, was hier nicht stimmt?
Wo setzt ich an?
 
Wie gibst du denn den datastore von der OwnCloud zurück an den ESXi? Per NFS?
Sieht so aus als ob auf dem RaidZ sync-writes stattfinden. Die Werte würden zu deinen SSDs passen. Beim Schreiben auf ein RaidZ1 hast du immer nur die Schreibleistung einer SSD (beim lesen liest er von allen drei, passt ja auch).
Viel mehr Schreibleistung kannst du bei sync writes von diesen SSDs nicht erwarten.
Schnellste, aber auch unsicherste Lösung: den Pool aus den drei SSDs auf async fest umstellen. Bei einem Stromausfall / Absturz besteht aber die Gefahr korrupter Daten in den VMs.
Etwas teuerer / umständlicher: nochmal 3 dieser SSDs auftreiben ( mit etwas Geduld sollten die auf eBay oder Kleinanzeigen für nen zwanziger das Stück zu haben sein) und den Pool als striped Mirror aufbauen.
Oder die Samsung für ein anderes System verwenden und auf NVMe (da aber anständige mit TLC und DRAM Cache oder gleich Enterprise) wechseln.
 
Ja definitiv per NFS3 Datastore.

Das das Dateisystem drunter wartet, bis die Daten tatsächlich geschrieben werden, kann ich mir noch herleiten.
Aber warum geht die Performance so in den Keller?
Zielt es hier eher auf die random write Performance ab, anstatt die sequenzielle write Performance?
Falls ja muss ich mich definitiv mal nach andern SSDs umschauen -.-
2x1-2TB reicht da.
NMVe bekomm ich mit dem Controller leider nicht betrieben.
Beitrag automatisch zusammengeführt:

Was kauft man sich da, als SSDs, wenn die 1Gbit Leitung der begrenzende Faktor ist?
 
Zuletzt bearbeitet:
Was kauft man sich da, als SSDs, wenn die 1Gbit Leitung der begrenzende Faktor ist?
Lautstärke, Stromverbrauch

Ich würde mir heute keine HDD in der Größe 1 oder 2 TB mehr kaufen... Aber ist nur meine Meinung...

Ein RaidZ1 aus 3 512GB SSD finde ich aber ebenso dumm. Imo hat man da sogar ein höheres Ausfallrisiko als bei einem Mirror. Denn wenn mir ein Datenträger ausgestiegen ist habe ich bei Z1 2 Datenträger die beide Fehlerfrei funktionieren müssen damit der Pool Online bleibt. Bei Mirror ist es nur eine.
 
guten Morgen und danke für das Kompliment.
Ich habe nicht vor HDDs zu kaufen und bin gerade am experimentieren.
Bei 3 disks die ich noch da hatte, kann man doch nix anderes als nen RAID5 bzw RaidZ-1 bauen.
Ok eine raus und Mirror wäre ne Option.
 
Ok viele Möglichkeiten.
Ein Mirror aus 3 Platten ist mir komplett neu.
Was aktuell richtig gut ist, sind die Lesewerte, auf die ich ungern verzichten möchte.
Aber ich werde weiter testen.

Nach meinem Empfinden habe ich folgende Optionen:

Mirror mit 2 bzw. 3 Platten n+1/2, (wird die zweite dann als Hot Spare verwendet oder einfach nur 2x gespiegelt?) welcher am Ende nur die Kapa einer Platte bereitstellt. --> Performancemessung folgt
Z1 --> wie gehabt mit richtig guter Leserate aber mieser Schreibperformance dafür die Kapa von 2 Platten -->
Es ist echt irre, wie schnell eine Windows VM booten kann, wenn die Leseperformance so hoch ist.
Mal sehen wie die Performance aussieht, wenn sync-write deaktiviert ist.

Auf was ich am Ende definitiv nicht verzichten möchte ist das sync-writes Feature.
Aus meiner Sicht, ist das eins der Pro Argumente zfs überhaupt einzusetzen.
Wobei @gea geschrieben. das man das Feature nur benötigt, wenn es notwendig ist. hmm
 
Zuletzt bearbeitet:
der zil(ZFS Write Cache) liegt ja schon auf einer SSD, das erhöt den Speed leider auch nicht weiter.
 
Mirror mit 2 bzw. 3 Platten n+1/2, (wird die zweite dann als Hot Spare verwendet oder einfach nur 2x gespiegelt?) welcher am Ende nur die Kapa einer Platte bereitstellt. --> Performancemessung folgt
Z1 --> wie gehabt mit richtig guter Leserate aber mieser Schreibperformance dafür die Kapa von 2 Platten -->
Es ist echt irre, wie schnell eine Windows VM booten kann, wenn die Leseperformance so hoch ist.
Mal sehen wie die Performance aussieht, wenn sync-write deaktiviert ist.

Auf was ich am Ende definitiv nicht verzichten möchte ist das sync-writes Feature.
Aus meiner Sicht, ist das eins der Pro Argumente zfs überhaupt einzusetzen.
Wobei @gea geschrieben. das man das Feature nur benötigt, wenn es notwendig ist. hmm

ZFS kann n way Mirror, also auch Mirrors mit 3 Platten Damit können n-1 Platten ohne Datenverlust ausfallen Die Schreibleistung eines n way Mirrors ist wie eine Platte. Lesend (iops und seqentiell) ist es aber n * Einzelplatte da ZFS von allen Platten gleichzeitig lesen kann.

ZFS ist wegen Copy on Write crashsicher. Stromstecker beim Schreiben ziehen hat in 99,999? % der Fälle (100% Siccherheit kann es nicht geben. Es gibt immer ein statistisch sehr kurzes Zeitfenster in dem auch CoW Probleme bekommen kann) keine Auswirkung auf das Dateisystem. Es bleibt der Datenstand vor dem Crash valide. Für einen Filer braucht man nur dann sync wenn man auch den Spezielfall absichern möchte dass ein Write z.B. eines Office Dokuments zum Zeitpunkt des Crashed bereits vollständig im ZIL/ Slog war. Dann wird dieses komplett beim Reboot nachgeholt.

Transaktionen oder VM Dateisysteme sind aber nicht sicher. Da kann es passieren dass bestätigte Schreibvorgänge die im Ramcache liegen verloren gehen und ein VM Dateisystem nach dem Crash korrupt ist. Die Wahrscheinlichkeit dafür ist viel höher. Genau dafür hilft sync write da damit eben keine bestätigten Schreibvorgänge verloren gehen.
Beitrag automatisch zusammengeführt:

der zil(ZFS Write Cache) liegt ja schon auf einer SSD, das erhöt den Speed leider auch nicht weiter.

ZIL/Slog ist kein Schreibcache!

Warum:
In einen Schreibcache wird schneller geschrieben als auf das normale Storage. Der Inhalt des Caches wird dann in in Intervallen verzögert auf ein Storage geschrieben. Das passiert bei einem ZIL/Slog nicht. Da werden lediglich bestätigte Schreibvorgänge protokolliert (sind ein paar GB) . Da wird nie gelesen außer beim Reboot um unvollständige bestätigte Schreiborgänge nachzuholen.

Ein ZIL/Slog kann damit die allgemeine Performance nicht verbessern, ganz im Gegenteil. Es geht nur darum dass die Performance bei sync write nicht zu sehr einbricht. Wenn man sync aktiviert (nur dann wird überhaupt protokolliert), dann erfolgt das Schreiben weiterhin ganz normal und schnell über den RAM Schreibcache. Zusätzlich werden alls bestätigten Schreibvorgänge protokolliert. Im Ergebnis muss als alles zweimal geschrieben werden. Einmal auf den Pool und einmal in das Protokoll. Das muss langsamer sein.

ZIL ist dabei ein kleiner Bereich auf dem Pool auf dem ohne Fragmentierung so schnell wie der Pool es halt erlaubt geschrieben werden kann. Mit einem Slog erfolgt die Protokollierung stattdessen auf diesem Laufwerk das viel schneller sein kann als das Pool ZIL.
 
Zuletzt bearbeitet:
Danke für die Erklärung :coffee3:
Bis auf meine FirmeHP ist aktuell nichts wirklich produktives nach außen im Einsatz, da gibt es nur statischen Content der per Ansible jederzeit wieder läuft, also wer hier ein korruptes Dateisystem relativ egal.
Interessant wird es, wie es sich mit einer Nextcoud Instanz verhält.
Gibt es bezahlbare SSDs (1-2TB reichen), die trotzdem gute Schreibwerte mit aktiven copy on write liefern?
Wenn ich daheim bin, schau ich mir als erstes die Performance an, wenn es deaktiviert ist.
Theoretisch könnte ich auch M2 in dem leeren Slot verbauen und das SLOG drauf legen.
 
Bloede Frage: Bin aktuell dabei meine komplette Netzwerkinfrastruktur auf den aktuellen Stand zu bringen.
Nutze hier eine FreeNAS (core) VM auf meinem ESX als Storage. Soweit auch alles cool.

Kann ich die Buechse nun irgendwie Clustern auf eine Site B ?

Auf der 2. Site wuerde ein aehnlich großes Array platz finden, allerdings auf HDD basis. Soll eigentlich nur nen Backup zur Verbesserung der Verfuegbarkeit zu dem Filer hier sein.
Geht sowas mit FreeNAS grundlegend und mit ueberschaubarem Aufwand oder einfach bleiben lassen?
 
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