[Sammelthread] ZFS Stammtisch

[gea]

Hi

Also nochmals für Dummies, kurz und knapp. Wurde ja schon kreuz und quer diskutiert, und von @gea ein SOAP fix in napp-it eingebaut, bezüglich der Autosnapshot Funktion, welches von einer VM ein ESXi Snap macht, ein ZFS Snap auf napp-it anlegt, und danach den ESXi snap wieder löscht. Verstehe den Sinn nicht ganz dahinter, also irgendwie schon. Aber Autosnap von ZFS wurde ja offensichtlich schon vor dem SOAP Feature genutzt. Bin auch noch auf der LTS Version von napp-it. Das darf auch nicht nach aussen telefonieren, und hat von daher noch keine Updates gesehen.

Was passiert jetzt, wenn ich von einem ZFS Filesystem, wo ein paar (laufende) VMs drauf liegen auf welche eh nur selten geschrieben wird, einen Snap mache? Ist der Snap dadurch korrupt? Bezieht sich das Problem nur auf den vram, bzw. die .lck Dateien? Oder liegen die Einschränkungen tiefgreifender? Was muss ich genau tun, um Autosnaps nutzen zu können? Bislang habe ich alle VMs händisch runter gefahren, und dann einen Snap über alles gemacht. Reicht für mich auch, weil wie gesagt, da wird eigentlich nichts geschrieben auf die VMs.

Die VMs pro Platte liegen alle zusammen auf je einem Pool. Hätte ich da besser für jede VM einen eigenen Pool gemacht? RAID gibt es nicht.

Gruss und danke



Anhang anzeigen 1031589

Das Problem:
Ein ZFS Snap ist wie Netzstecker ziehen. Ein ZFS Dateisystem selber geht dabei nicht kaputt sondern bleibt bei dem gültigen Stand vor dem Stromausfall als ist auch ein Snap valide. Das gilt aber nicht für VMs mit ihrem Gastdateisystem. Da kann ein Snap korrupt sein wenn man den während eines Schreibvorgangs erstellt. Die VM selber läßt sich durch sync write absichern, nicht jedoch die VM im Snap. Wie oft man einen Fehler hat läßt sich wohl statistisch ermitteln. Ist jedoch ein ungutes Gefühl wenn man nicht genau sagen kann ob ein ZFS Snap gut oder schlecht ist. Um sicher zu gehen kann man die VM vor dem Snap herunterfahren oder einen sicheren ESXi Snap in den ZFS Snap integrieren. ESXi Snaps (quiesce oder hot memory sind sicher) um bei Bedarf nach einem Rollback darauf zurückzugehen. Das mach die ESXi snap Funktion in napp-it und das ist Vorraussetzung für snapbasiertes sicheres Hot Backup. ESXi Snaps sind per VM.

Am einfachsten ein NFS Share für alle VMs anlegen.

Beitrag automatisch zusammengeführt: 30.09.2024

Hab hier was zur Z1/Z2 Konfiguration mit Laufwerksanzahl gefunden, weil wir das Thema erst hatten. ine

ZFS/The problem with RAIDZ.md at main · jameskimmel/ZFS

Stuff about ZFS. Contribute to jameskimmel/ZFS development by creating an account on GitHub.

github.com

Sieht ja weniger toll aus erstmal, aber inwiefern ist das in der Realität überhaupt zutreffend, vor allem mit TrueNAS?

Hat mit TrueNAS nichts zu tun sondern ist ein ZFS Problem. Seit man aber Compress immer aktiviert, ist es ein Nicht Problem da die Größe eines komprimierten ZFS Datenblocks variabel ist. Die "Golden Number von 2^n Datenplatten" per Raid-Zn war vor vielen Jahren eine Empfehlung bei vdevs ohne Compress. Heute einfach nehmen was da ist und Compress aktivieren.

10 Jahre alt aber aktuell:

How I Learned to Stop Worrying and Love RAIDZ

The popularity of OpenZFS has spawned a great community of users, sysadmins, architects and developers, contributing a wealth of advice, tips…

www.delphix.com

 

[AliManali]

Danke @gea. Wenn ich napp-it auf den neuesten Stand bringen will, reicht es da über das Webinterface update auszuführen? Oder muss ich da omnios noch separat per SSH updaten? Wenn ja wie? Hätte am liebsten eine möglichst stabile Version, die wird sicher wieder jahrelang keine Updates erfahren. napp-it darf im Normallfall auch nicht nach aussen telefonieren.

Nutze napp-it free v23.dev auf omnios v11 r151046. War einfach die ESXi AiO LTS von Deiner Website, erst vor wenigen Wochen herunter geladen. Habe gesehen, dass da die SOAP ESXi Snap Funktionen ja schon dabei sind. Oder kann ich das bedenkenlos so belassen bei der Version?

 

[gea]

OmniOS Updates und napp-it Updates gehen getrennt.
Bei OmniOS sollte man immer die aktuelle stable oder long term stable nutzen. Napp-it muss man nur updaten wenn ein neueres OmniOS das erfordert oder ein neues Feature/Bugfix damit verbunden ist.

 

[pwnbert]

Ohje, ich überlege gerade, ob ich 2x SN850X 4TB kaufen soll als Special-VDEV-Mirror (für 4x 20TB Z1, evtl. upgrade auf 5).

 

[Trambahner]

SN850X? Da empfehle ich per Terminal vor jeglicher Nutzung unter Unixoiden auf nativ 4K (statt der werkseitig gelieferten 512e-Konfig) umzuformatieren. Das geht bei den 850ern und bringt Performance.

Mit Linux und NVME hab ich auf Hardwarelevel nie die sequentiellen Raten gesehen wie unter Windows CDM-Bench, Mit dem 4K-Format bei der SN850X kommt das dann auch so an mit lowlevel-Tests wie #DD ....
Unter ZFS seh ich etwa 2-2.5 GiB/s bei den 850ern pro SSD.

Ich hab zwei 4TB 850X im kleinen Proxmox als regulärer Mirror (also nicht als Special vdev) für die VMs drin.

#nvme id-ns -H /dev/nvmeXXXX    # listet nur die Namespaces, hier wird nix an daten geaendert

LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)

> nur 512er Sektoren

LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good  (in use)
LBA Format  1 : Metadata Size: 0   bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better

> auch 4K Sektoren möglich.

#nvme format --lbaf=1 /dev/nvmeXXXX   # lba format=1 = 4K bloecke, löscht alle Daten auf der SSD

 

[pwnbert]

SN850X?

Ist nicht unbedingt meine 1. Wahl für den Zweck (da nur mittelmäßig PBW, zwar nicht wenig, aber auch nicht üppig), aber momentan für 250€ im Prime Day zu haben.

Da empfehle ich per Terminal vor jeglicher Nutzung unter Unixoiden auf nativ 4K (statt der werkseitig gelieferten 512e-Konfig) umzuformatieren. Das geht bei den 850ern und bringt Performance.

Wie macht man das? Also wenn ich z.B. ein Linux installiere, in der Live-Umgebung das Beschriebene ausführen, bevor man das Ding per Calamares formatiert?


Bin mir nicht sicher wegen dem SVDEV... dann könnte ich ja eigenltich überhaupt nur ein großes Hybrid-Pool machen und da meine Datasets drauflegen, und könnte auf ein extra SSD Pool verzichten (für Fotoordner, Handybackup-Ordner und so), oder?
Hab bissl Sorge die Sache unnötigkompliziert zu machen und damit unnötig Risiko ins Pool zu bringen, aber andererseits sollte das ja solid funktionieren?

Bin mir da überhaupt nicht sicher, da auf meinem "großen" Pool eigentlich fast nur große Dateien sind... könnte evtl. auch die 2 TB Version nehmen, aber das fühlt sich für mich so falsch an, wegen den knappen PCIe Slots...

Andererseits... was für eine Größe nimmt man denn als SVDEV "Grenze"?
Blöde Frage, oder? Weil Nutzungsabhängig?
Wsl. müsste man ALLE Dateien indexieren und eine Statistik erstellen, dann könnte man wohl sagen, bis zu welcher Größe die kleinsten sagen wir 0,5-1TB sind (dann ist noch Platz für Wachstum, Metadaten und Freiraum). Da kommt dann theoretisch ein Wert raus, 100kb, 20mb, oder was auch immer... das wäre wohl der passende Wert?
==> Gibts dafür irgend ein Programm?

 

[Trambahner]

Kannst Du direkt auch in Proxmox oder TrueNas Scale (das sind ja im Kern Debian-Linuxe) machen, bevor du sie per Zpool-Kommando oder Gui nutzt.
Die SN850X haben einen Vorteil: sie sind recht gut bei sequentiellen Transfers bei kurzen Warteschlange. Weil: wo hast im Homelab daheim schon Warteschlangen grössergleich 4.
Und ZFS serialisiert ja Zugriffe nach Möglichkeit, lange Warteschlangen mit Random-I/O tritt daher nicht so auf daheim.

Ich würd das gern ja mal mit Crucial T705 (gen5 SSDs) testen, aber nicht bei den Preisen die dafür aufgerufen werden.
Btw, 249 für ne 4TB SN850X ist zwar aktuell bester Retail-Preis, aber die waren schon deutlich günstiger. Meine waren 219,- mein ich.
---

Special Vdev selber hab ich keine Erfahrung; ich hab nur einmal kurz das Einrichten getestet "um der Wissenschaft willen" quasi. aber nutze immer komplett getrennte Pools.
HDD Raidz2 für große Files und Coldstorage, SSD-only Mirrors für VMs und ständig benutzte Arbeitsdateien.

 

[pwnbert]

Kannst Du direkt auch in Proxmox oder TrueNas Scale (das sind ja im Kern Debian-Linuxe) machen, bevor du sie per Zpool-Kommando oder Gui nutzt.

Meine Frage war darauf aus, dass ich im Desktop schon eine SN850X hab, auf der ein frisches EndeavourOS drauf ist (neu installieren würde mich nicht stören), allerdings BTRFS dort.

Btw, 249 für ne 4TB SN850X ist zwar aktuell bester Retail-Preis, aber die waren schon deutlich günstiger. Meine waren 219,- mein ich.

Ja, ist der Bestpreis aktuell für TLC mit DRAM.
Vor 1 Jahr gabs 4TB 870 Evo für 170€, wünschte, ich hätte mehr gekauft.

Hab mir auch überlegt fürs Proxmox (wo div. VMs draufkommen, TNS würde ich von der 250gb SSD am HBA booten, also die Bestückung gegen Bare-Metal nicht ändern) dann nen ZFS Mirror zu machen.
Kann da leider gar nicht einschätzen, welche Größe ich brauche.
Real reicht mir 1 TB wsl. für alle VMs. Wsl. würden 2 TB SSDs hierfür reichen.

Ist dann eh schon ein ziemliches Problem bezüglich Bifurication.
edit: Insofern wären mir SATA oder SAS SSDs lieber, aber SATA ist ja teuer als M.2 und SAS bekommt man quasi gar nix. Hätte 2x 4TB 870Evo hier, die ich theoretisch auch als SVDEV nehmen könnte direkt am HBA, aber ob die nen Geschwindigkeitsvorteil bringen würden? Mh...

 

[pwnbert]

Spannend.
Hab mal ein Z1 mit Special VDEV gemacht aus 2x 8TB und 1x 10TB WD red/gold und 1x Samsung 980 (nonpro) 1TB, Smallblocksize 1M, LZ4, 128k alles Standard.

Ich hab mir nen Ordner gesucht zum kopieren, der verschiedenes Enthält, auch viel Kleinzeug, ist ein alter manueller Handy-Backup-Ordner.

Kopiert auf mein 3er Z1 mit SVDEV sieht das so aus:
Interessant ist vor allem der Einbruch am Ende, diese Whatsappfotos der Zeit sind so 50-300kb groß.

Auf mein 4er Z1 mit HC560 (natürlich weit schnellere Platten) sieht das so aus:

Hier auf eine Micron 7400pro 1tb (Einfachdatenträger):

Kontrolle, am W10 Rechner von FireCuda 530 auf Samsung 980pro:
Screenshot leider zu spät gemacht, aber der Bereich, welcher vorhin immer 20-30mb/s war war hier ca. 70-80mb/s. An der Quelle (allein) kanns also nicht liegen.



Quelllaufwerk ist eine FireCuda 530 4TB als PCIe 4.0x4, NTFS (möglicherweise ist hier das Problem?), W10.
Ziel M.2 und dem 4er Z1: TrueNAS baremetal, 2.5 GbE Onboard E3100, Onboard SATA
Ziel 3er Z1 mit SVDEV: TrueNAS auf Proxmox, 2.5 GbE USB3 RTL8126B, LSI 9207



... ich hätte mir das irgendwie anders vorgestellt.
Klar, im NAS Betrieb ist das Lesen ja oft deutlich wichtiger als das Schreiben und die Sache mit den Metadaten wsl. recht praktisch beim Suchen/Sortieren etc. (so stelle ich mir das zumindest vor).
Aber irgendwie unerwartet, dass die M.2 (klar, weder die Micron noch die 980 sind besonders schnell, was besseres hab ich gerade nicht frei) kaum schneller ist als dein HDD only Pool.
Mich überrascht, dass das Z1 (4x HC560) relativ gut performed... daran gibts überraschend wenig auszusetzen, so zum Thema "spinning rust"..


Also, an welcher Grenze bin ich hier? Ist es das 2.5 GbE? Ein "glatter Stream" sollte ja problemlos gehen, muss also irgendwie an was anderem liegen. Ist es Samba? Das File-Handling vom Windows? Evtl. ne Kette?


PS: Ja, das war jetzt nur geschriebene Last, keine gelesene, welche eigentlich wichtiger wäre. Dafür müsste man aber wohl den ARC abschalten, da man ja sonst ziemlich verfälscht mischt.
Könnte ich auf der Testgurke mal machen, auf der produktiven eher nicht.
Wie ich die Sache mit dem "Metadaten-lesen" sinnvoll "testen" könnte? Bin da für Vorschläge offen.


tl,dr: Fürs erste haut mich das SVDEV nicht so vom Hocker, nähere Betrachtung ist notwendig.

 

[pwnbert]

Nochwas, was ist eigentlich von der Idee zu halten, die SSDs in einem M.2 Mirror zu mischen? Also FireCuda 530, KC3000, SN850X... (2 davon nach Marktlage).
... um sich gegen einen Synchrontod durch Firmwarebug etc. zu schützen?

Von den Leistungswerten her sind diese SSDs am Papier ja recht ähnlich (meine Benches zwischen FireCuda 530 und SN850X haben auch keine massiven Abweicher ergeben)...
Ist das dann von der Lese-Leistung her eher meh, oder kann bzw. sollte man das machen?
Oder doch lieber 2 gleiche Drives, wie es die Oldschool-Raid-Empfehlung ist?

 

[gea]

Nochwas, was ist eigentlich von der Idee zu halten, die SSDs in einem M.2 Mirror zu mischen? Also FireCuda 530, KC3000, SN850X... (2 davon nach Marktlage). ... um sich gegen einen Synchrontod durch Firmwarebug etc. zu schützen?

wenig,
dafür gibts Backup auf den HD Pool das man eh machen sollte

Ein Firmware Risiko sehe ich als sehr gering an.
Ansonst ist es ZFS egal, Es nutzt jede Platte im vdev unabhängig von den anderen.

Beitrag automatisch zusammengeführt: 10.10.2024

Spannend.
Hab mal ein Z1 mit Special VDEV gemacht aus 2x 8TB und 1x 10TB WD red/gold und 1x Samsung 980 (nonpro) 1TB, Smallblocksize 1M, LZ4, 128k alles Standard.

Was soll denn überhaupt erreicht werden?

Eine smallblocksize von 1M sorgt ja dafür dass alle ZFS Daten und Metadaten die komprimiert kleiner sind als 1M auf dem special vdev landen. Das ist ja bis auf multi-GB Videos praktisch alles. Wenn einem dann die Peformance bei Dateien <=1M nicht reicht, so liegt das ausschliesslich an Sachen wie deren Qualität, deren Füllrate oder zu wenig RAM. Auch sind "Desktop" SSD bei steady write, small io und concurrent read/write meist recht schlecht. Für größere Dateien eventuell reecsize auf 1M stellen. Für small blocksize=1M sehe ich überhaupt keine Anwendung. Typisch wäre für mich sbb bis 128K und recsize 256K oder mehr.

Für SSD vor allem "Typ Desktop" unbedingt Trim einschalten. Kostet zwar auch Performance - sonst werden die aber noch schneller lahm als sie es bereits im Server sind. Ideal für special vdev sind "sehr gute NVME", die besten sind die Optane falls man die günstig findet.

 

[pwnbert]

wenig,

Okay. Dachte auch wegen den unterschiedlichen TBW, einer write-amp die sich (je nach Controller) evtl. unterschiedlich auswirkt etc., dass der Verschleißzustand nicht ganz Synchron ist... man versucht ja auch oft verschiedene Chargen zu mischen etc. für diverse "Raids", um das Risiko für Synchronausfälle wg. Chargenfehlern zu minimieren. Daher mein Gedankengang.

Was soll denn überhaupt erreicht werden?

Diese komische Ansammlung an Datenträgern? Das ist, was ich rumliegen hatte, und zu Testzwecken im Testserver (MC12LE0 etc.) zusammengesteckt hab. Bevor ich das "produktiv" verwende, mag ich mich damit ja bissl vertraut machen und Sachen ausprobieren in einem Risikofreien Umfeld.

Eine smallblocksize von 1M sorgt ja dafür dass alle ZFS Daten und Metadaten die komprimiert kleiner sind als 1M auf dem special vdev landen. Das ist ja bis auf multi-GB Videos praktisch alles.... Für small blocksize=1M sehe ich überhaupt keine Anwendung.

Das ist wohl richtig und mir selbstverständlich auch bewusst.
Es ist allerdings so, dass "Multi-GB Videos" einen großten Teil des Speicherplatzbedarfs ausmachen, ebenso Fotos. Auch so ein .jpg ist ja kaum noch zu komprimieren (wohl 1.0x ratio). Insofern würden Bilder >~1MB auf den HDDs landen und kleinere am SVDEV - lieg ich da jetzt falsch?
Angenommen ich verwende eine 4tb SSD als SVDEV, ziehe davon 1tb für die Metadaten ab, 1tb Freiraum, so bleiben mir 2tb. Ich hab keine 2tb "kleine Dateien".

Insofern dachte ich, ich probier das mal, und zwar gleich mit einer großzügigen Smallblocksize.

so liegt das ausschliesslich an Sachen wie deren Qualität, deren Füllrate oder zu wenig RAM

Ich bitte dich um eine Begriffserklärung, damit stehe ich in dem Zusammenhang gerade auf der Leitung.
(RAM hat meine Testgurke tatsächlich nur 12gb, mein baremetal TNS Filer hat aber 128gb... sollte ja zum Schreiben nicht so das Ding sein?)

 

[gea]

Auf dem special vdev landen alle ZFS Datenblöcke <= small blocksize. Bei entsprechender recsize sind das ganze Dateien.

Ein special vdev ist dauerhafter Ablageort entsprechender Daten inkl. der dazugehörigen Snaps. Man sollte da den Bedarf < 1M Dateien nicht unterschätzen. Das wächst immer, schrumpft nie. Auch haben vor allem Desktop SSD Performance Probleme wenn sie voller werden (Performance wird schlechter je voller die SSD, gilt auch für HD vdevs aber SSD sind deutlich empfindlicher wegen der Page/Block Problematik).

Auch ist der Performancevorteil von SSD umso größer je kleiner die Datei. Bei Videodaten und single user kann ein HD Pool so schnell sein wie ein SSD Pool.

RAM ist auch beim Schreiben kritisch. 12GB bei TN ist ja allein schon unter der normalen Empfehlung für Debian + TN GUI (16GB). Da bleibt nicht soviel für Schreibcache (RAM) und Lesecache (Metadaten, muss man auch vor dem Schreiben lesen).

Wenn man nicht gerade extrem viele kleine Dateien hat, würde ich für Metadaten eher mit <5% rechnen als 25%.

zu SSD.
Es gibt große Unterschiede bei SSD im Serverbetrieb (steady write, mixed read write, 4k write). Unabhängig von den wünsch dir was Angaben im Datenblatt kann das bedeuten dass man 5k iops hat oder 500000 oder 50MB/s oder 2000 MB/s sequentiell.

 

[pwnbert]

Das wächst immer, schrumpft nie.

Meinst du weil man idR. nix löscht?

Meine äußerst naive Beobachtung war, dass die Kopiergeschwindigkeit schon bei Daten <5mb keiner wird, <1mb richtig, drum dachte ich ich setzt die Smallblocksize gleich mal auf 1mb, weil ich da den größten Effekt erwartet habe (welcher aber so nicht eingetreten ist, wie sich das mein naives Consumer-Hirn vorgestellt hat ).

RAM ist auch beim Schreiben kritisch. 12GB bei TN ist ja allein schon unter der normalen Empfehlung für Debian + TN GUI (16GB). Da bleibt nicht soviel für Schreibcache (RAM) und Lesecache (Metadaten, muss man auch vor dem Schreiben lesen).

Ja, das ist mir schon klar, aber die 128gb baremetal Maschine hat sich im Grundsatz (mit der Micron 7400pro SSD) nicht anders verhalten als die 12gb VM, insofern dachte ich naiv, dass das nicht der Flaschenhals sein wird.


=> So, eine Grundsatzfrage noch, wenn ich dich schon dran hab, und ich deine Antworten so schätze:
Wenn ich am Pool Ordner hab mit vielen Dateien drin (>5000 in 1 Ordner, ob das so eine sinnvolle Struktur ist, steht auf einem anderen Blatt), dann dauert das erstmal eine Zeit, bis ich die Auflistung im Windows-Explorer hab (vom baremetal Linux Clienten hab ichs noch nicht versucht), neu sortieren (nach Name, Länge, Datum...) braucht auch mal etwas.
Wenn ich paar mal drin war, gehts dann aber recht fix.
=> Liegt das am Metadata-Arc-Cache oder liegt das an der Funktionsweise vom SMB, weil am Clienten gewisses Zeug gecached wird?
=> Wenn ich vom Clienten aus (jetzt mal als Beispiel Win10 per Windows-Explorer) mit der Suchfunktion am Netzlaufwerk eine Datei suche, wirkt sich in diesem Fall das Metadata-VDEV massiv aus?

LG und vielen Dank, dass du immer bemüht bist, so informativ zu antworten.

 

[gea]

Storage wächst immer, schrumpft nie (niemand löscht was inkl der zugehörigen Snaps).
Klar sind 4TB special vdev Luxus. Gern nimmt man da halt Optane und das ist dann nicht günstig mit höheren Kapazitäten oder schwer gebraucht zu bekommen. Ein kleines schnelles special vdev bringt mehr als ein großes langsameres weil bei großen Dateien ein Plattenpool kaum langsamer ist bei ausreichend RAM.

Metadaten beim Listen großer Ordner könnten im Client gecacht werden. Zunächst ist da aber Arc oder besser persistent L2Arc oder noch besser special vdev das Mittel der Wahl um das zu beschleunigen. Bei vielen Usern dürfte ein multithreaded SMB Server (Solaris, Windows) Vorteile gegenüber singlethreaded SAMBA haben.

Ich würde nie von Metadaten vdev reden sondern immer von special vdev, da das Ablegen kleiner Dateien den wichtigeren Performanceschub bringt. Metadaten aktueller Daten liegen eh im Arc wenn man nicht gerade wenig RAM oder einen Mailserver mit 10M Dateien und 10k Usern hat. Da brauchts tatsächlich ein special vdev oder zur Not ein persistent L2Arc um dass schnell zu bekommen.

 

[pwnbert]

Klar, Optane würde dann tatsächlich nur für Metadata sein oder ggf. ne kleine Smallblocksize. Aber ich hab keine und so wirds vmtl. auch bleiben, billiger werden die irgendwie nicht... und ne gute M.2 wird ja immer noch um Zehnerpotenzen besser sein als eine "Rotationsspeicher"... so war mein Gedanke.

Ein kleines schnelles special vdev bringt mehr als ein großes langsameres weil bei großen Dateien ein Plattenpool kaum langsamer ist bei ausreichend RAM.

Ich verstehe. Optane sind für mich in der Beschaffung leider unrealistisch, der Preis bei M.2 TB SSDs ist "im gewöhnlichen Bereich" ja recht linear, daher der Gedanke gleich ne Nummer größer zu machen.

oder besser persistent L2Arc

Das hatten wir schon, das hab ich ja schon eingerichtet, mit nicht merkbarem Erfolg (außer vllt. man will es sich einbilden).
Man kann im ARC doch eine Mindestgrenze für Metadaten festlegen, also dass Metadaten bevorzugt werden, das habe ich imho auch gemacht (kann jetzt nicht nachsehen). Insofern fürchte ich, dass die Metadaten vom ARC nicht in den L2arc wandern und somit auch nie persistent sind, da beim Shutdown der ARC wohl nicht in den L2arc "gedumpt" wird (zumindest bei TNS...). Keine Ahnung ob der L2arc (=metadata only) irgendwie aus dem ARC befüllt werden kann, mein Gefühl ist, dass das so nicht funktioniert, kann aber nix handfestes dazu sagen.

Nur so viel, das "fake Metadata-SVDEV" per L2arc=metadata-only ist offensichtlich kein toller Geheimtip, wie du mir schon vor längerer Zeit vorhergesagt hast (probiert hab ichs trotzdem).

, da das Ablegen kleiner Dateien den wichtigeren Performanceschub bringt.

Also meinst du, dass 128kb ein guter Grenzwert sind? Was ist denn so die Größe, ab der ein flottes HDD Pool wirklich mies ist?

 

[gea]

Klar, Optane würde dann tatsächlich nur für Metadata sein oder ggf. ne kleine Smallblocksize. Aber ich hab keine und so wirds vmtl. auch bleiben, billiger werden die irgendwie nicht... und ne gute M.2 wird ja immer noch um Zehnerpotenzen besser sein als eine "Rotationsspeicher"... so war mein Gedanke.


Also meinst du, dass 128kb ein guter Grenzwert sind? Was ist denn so die Größe, ab der ein flottes HDD Pool wirklich mies ist?

Einfach mal ein Crystal Disk oder anderen Benchmark ansehen bei dem mit unterschiedlich großen Datenpacketen gearbeitet wird. Da sieht man dann dass alles unterhalb von 64K QD1 richtig schlecht wird (auch bei normalen SSD, eben bis auf die Optane die da viel weniger einbricht). Bei single user/home weniger gravierend, bei Multiuser und vielen Dateien ein ko Kriterium.

 

[pwnbert]

Noch eine vllt. hier nicht ganz passende Frage, aber was kauft man heute im Datacenter, wenn man keine Optane mehr bekommt?
Also angenommen ich möchte heute eine aktuelle Neuware kaufen für diesen Zweck, was wäre das? Im Bereich sagen wir unter 2000€?
Nicht, dass ich das jetzt für den Homeserver haben will, aber natürlich bin ich neugierig, was man denn heute im "ernsthaften" Umfeld für diesen Zweck verwendet.

 

[gea]

Bei Geizhals SAS3 bzw NVMe (PCi/U.2/3) als Interface wählen, dann max 2000 Euro setzen, dazu Kapazität, PLP, DWPD (1, 3 oder 10) und gewünschte 4k write iops (Optane hat 500k). Die Auswahl wird dann sehr schnell sehr übersichtlich.

Oder schnell die letzten 480x oder 580x Optane aufkaufen. Deren direkte Zelladressierung (kein Trim, kein Garbagekollection, kein Block erase vor Page write) ist normalem Flash einfach überlegen. Eine Schande dass die EoL sind. Sind halt extrem teuer für die gebotene Kapazität und nur wirklich nötig für ganz spezielle ZFS Highend Aufgaben wie Slog oder special vdev - kein Massenmarkt.

oder

DapuStor Xlenstor2 X2900P 800GB Review The 100 DWPD Next-Gen SLC Optane Alternative

If you are looking for a SLC NAND based alternative with Optane being sunset, the DapuStor Xlenstor2 X2900P is fast with a 100 DWPD rating

www.servethehome.com

 

[pwnbert]

Bei Geizhals SAS3 bzw NVMe (PCi/U.2/3) als Interface wählen, dann max 2000 Euro setzen, dazu Kapazität, PLP, DWPD (1, 3 oder 10) und gewünschte 4k write iops (Optane hat 500k). Die Auswahl wird dann sehr schnell sehr übersichtlich.

Naja, da kommt aber auch das ganze "normale" TLC Zeug raus, die ganzen Samsung PM, MIcron 7400/7450 und so Zeug.
Sowas ist ja ein absoluter Papiertiger: https://geizhals.at/kioxia-cm7-v-en...tb-kcmyxvug3t20-a3203376.html?hloc=at&hloc=de
Meine Consumer-Augen sehen hier auch nur "normalen" TLC 3d-NAND...

Die ganzen besseren Consumer PCIe 4.0 M.2 haben ja auch alle 1.000.000 4k IOPS am Papier... tu mir da bissl schwer durchzublicken.

 

[Trambahner]

Für die Metadaten hab ich an den HDD-Pool einen L2Arc (da persistent und ich den Rechner damit nur bei Bedarf hochfahre) mit Metadata-Only angefügt.
Hat Dateisuchen und Freefile-Syncs mit den Clients deutlich beschleunigt.
Hat auch den Vorteil, dass ich den L2Arc jederzeit wieder wegnehmen kann wenn ich die PCIe-Lanes anderweitig brauch. Mit Special Vdev gehts das Afaik nicht.

 

[pwnbert]

Und wie fütterst du den L2arc? Wird der nicht nur beschrieben, wenn der Arc "übergeht"? Und wenn man ne Metadata Größe im Arc zusichert, wird er das nie tun... weisst, was ich meine?

 

[gea]

Hat auch den Vorteil, dass ich den L2Arc jederzeit wieder wegnehmen kann wenn ich die PCIe-Lanes anderweitig brauch. Mit Special Vdev gehts das Afaik nicht.

special vdev kann man nachträglich wieder entfernen - sofern alle vdevs gleichen ashift haben.

 

[Trambahner]

Ah. Wusste ich noch nicht mit der Entfernbarkeit. Wieder was gelernt.

@pwnbert Die Settings sind alle auf default, der L2Arc auf secondarycache=metadata . Mehr hab ich nicht eingestellt. Aber beschrieben wird er, sieht man
im zpool status + Iostat.

 

[pwnbert]

Ja, ich hab ja auch so ein Setup gebastelt mit eurer (speziell gea) Unterstützung (müsste man hier einige Seiten zurück gehen).
Auch bei mir wird irgendwas reingeschrieben und liegt irgendwas drin, allerdings konnte ich nüchtern und ehrlich betrachtet keine große Veränderung feststellen.

Ich hab über ein Tuneable gelesen, wo man eben eine gewisse Menge Speicherplatz im ARC für Metadaten zusichern kann:

ZFS ARC metadata size minimum

I have a large 100s TB ZFS system that is suffering from slow read performance - it has 768GB RAM, but only uses a tiny fraction of that for metadata (

www.truenas.com

Heisst unter TrueNAS Scale aber anders als unter TrueNAS Core, muss man aufpassen.
arc_meta_min irgendwie, muss daheim nachsehen, was ich da rein geschrieben hab. Ich meine ich hab ~8gb dafür zugesichert.
Hast du dir das schon angesehen?

 

[gea]

Ich seh das wie in der Formel 1.
Den Spoiler leicht zu modifizieren, kann die Zentelsekunde pro Runde bringen die den Sieg ausmacht. Für normalen Gebrauch sind derartige Tunings aber praktisch irrelevant, manchmal kontraproduktiv weil es sein kann dass ein kleiner Aspekt verbessert wird, die overall Performance aber verschlechtert wird.

Die Defaults in ZFS sind sehr praxisgerecht. Nur bei "untypischen" Anwendungen macht es Sinn davon abzuweichen. Das Begrenzen der Read/Write Cache Nutzung macht eigentlich keinen Sinn. Man ist ja froh wenn möglichst viel aus dem Cache bedient wird und nicht von Platte. Die Arc Optimierung auf read last/read most Datenblöcke sorgt eh für eine Anpassung für den aktuellen Workload egal ob für Metadaten oder last io. Lediglich bei sehr vielen Usern mit sehr vielen volatilen Dateien sollte man Anpassungen vornehmen, dann aber eher in Richtung special vdev oder L2Arc um die Metadaten persistent schnell zu haben und auch sonstige small io zu beschleunigen. Die Defaults von ZFS ändern sich eh um neueren Entwicklungen gerecht zu werden. Das Herumdrehen an den vielen Stellschrauben von ZFS ist selten sinnvoll, meist nur mit geringen Verbesserungen - immer mit der Gefahr das es insgesamt schlechter wird.

Ist die Tuningursache wenig RAM, dann nicht versuchen den möglichst effektiv zu nutzen, sondern mehr RAM einbauen. Damit löst man das Problem statt es nur etwas zu verringern. Basiert der Tuningwunsch auf einem Workload, erst überlegen ob ein L2Arc, Special Vdev, Slog oder eine anderer Recsize nicht ausreicht oder die Situation gar grundlegend verbessert.

 

[pwnbert]

Ich meinte im ARC dem Metadata-ARC ein gewisses Minimum zuzusichern, damit die Metadaten nicht von "normalen" Daten aus dem RAM verdrängt werden, so war mein Verständnis dafür, irre ich da?

Ist die Tuningursache wenig RAM, dann nicht versuchen den möglichst effektiv zu nutzen, sondern mehr RAM einbauen.

Es gibt hier, bei uns Homeusern, ja einige Leute, die z.B. so Intel N100 usw. verwenden, wo man auf 1 RAM-Modul begrenzt ist...
Ist halt nicht, wofür ZFS gemacht ist, aber hat sich nun so ergeben...

 

[gea]

Selbst mit einem Modul gehen oft 32GB und selbst mit 16GB sehe ich keinen Grund Arc Caching zu beschneiden. Zudem wurde L2Arc ja primar dafür konzipiert in Low RAM Situationen mehr Cache zu bieten. SSD Vdevs oder Special vdevs sind auch mit wenig RAM sehr schnell. Weitere Optionen sind resourcensparende Setups z.B. Proxmox/Debian statt TN. Free-BSD dürfte auch resourcenschonender sein, Illumos noch mehr.

 

[pwnbert]

selbst mit 16GB sehe ich keinen Grund Arc Caching zu beschneiden.

Wer hat davon gesprochen, meinst du damit jetzt wen anderen, oder mich?

Ich meinte kein Begrenzen des ARC sondern innerhalb des ARC eine Mindestmenge für die Metadaten zuzusichern... darauf bin ich mal gestoßen und das fand ich sinnvoll.

 

[gea]

Eine Reservierung für Metadaten bedeutet eine Verringerung des Cache für normale Daten.
Könnte zwar mit sehr vielen Dateien was bringen, kaum jedoch @home mit wenig Dateien und Usern. Dann bremst das eher weil die eigentlichen Daten seltener im Cache sind. Mit vielen Usern oder Dateien gibt es bessere Methoden.