[Sammelthread] ZFS Stammtisch

[gea]

Die SE für Solaris/OmniOS kann man z.B. mit einem kostenlosen evalkey auf 26.06 se free bringen. Napp-it se hat Solaris Features wie Comstar bei denen ich momentan nicht vorhabe sie auf cs zu portieren. SE erhält noch bugfixes und Anpassungen an neueres OmniOS. Der Focus ist aber eindeutig die any OS/multi host cs. Neueste cs Features werden nicht auf se portiert (z.B. integrierter webserver, cs-stream, filesync, Cluster Betrieb etc).

Anfangs war napp-it cs eine Ergänzung zu se, jetzt ist es umgekehrt. Beide Varianten arbeiten aber nebeneinander, man kann direkt wechseln. Die Zukunft sehe ich in cs, auch weil die Bedeutung von Solaris/Illumos sinkt, auch wenn es immer noch das stabilste ZFS ist und Illumos gerade Fast Dedup integriert.

Weitere Fragen gerne im napp-it cs Sammler.

 

[CommanderBond]

Was kann man noch mit 2 Optane P1600X mit 118GB anstellen sinnvolles?

So wie ich das sehe eigenen sie sich bei ZFS ausgezeichnet als SLOG wenn man einen langsammen HDD Pool hat beispielsweise.
Jetzt ist die Sache nur die dass ich auf HDDs eh nur noch große Videos und Backups speichere und "das alltägliche Zeit" was nicht so viel ist auf einem Sata SSD Mirror.
So zumindest mein Speicherkonzept eher das zu trennen was unterschiedliche Anforderungen hat.

Wenn ich richtig informiert bin würde mir ein SLOG also rein gar nichts bringen bei meinem Setup weil das aller meiste nur asycrone writes sind.

Würde ein eigenständiger Pool mit 2 Optanes Sinn ergeben um dort VMs abzulegen? Oder doch besser verkaufen?

 

[BobbyD]

@CommanderBond Was verbraucht denn so ein Teil an Strom?

 

[CommanderBond]

Steht im Datenblatt. Für mich ist das nicht relevant für meine Frage

 

[ludwinator]

Was schon was bringt, wäre die Optanes a specal devices laufen zu lassen für meta und evtl. dedup.
In den neueren ZFS Verisonen werden die dann auch zusätzlich als slog benutzt.
Reduziert auf jeden Fall die Fragmentierung auf spinning rust.

 

[BobbyD]

Steht im Datenblatt

Wenn dich der Verbrauch nicht stört, dann betreibe sie doch so weiter.
Ich würde sie für temporäre Downloads, TV-Aufnahmen, etc. benutzen, wenn der idle-Verbrauch nicht zu hoch ist. < 1.7 W ist jetzt nicht so viel, aber auch nicht so toll. 10Gbit scheinen sie ja knapp zu erfüllen.

 

[CommanderBond]

Sie sind ja aktuell nicht in Gebrauch sondern liegen in der Schublade rum. Die Frage ist nur irgendwas mit machen oder verkaufen.
TV-Aufnahmen habe ich auch nicht. Hab nur nen großen HDD "Archive" Pool und einen SSD-Pool für den Rest.

Am Ende gehts ja auch darum dass man irgendwas halbwegs sinnvolles damit macht. Ich glaube der HDD Pool würde davon nicht profitieren, da werden mal großes Dateien, 50GB oder mehr drauf geschrieben oder Backups gemacht was in der Woche auch in der Regel nur paar 100MB sind wenn überhaupt.

Hab paar VMs, HomeAssistant, InfluxDB (Datenbank) etc, da könnte ich mir vorstellen würde ich noch den größten Nutzen haben.

Als "Special Devices" zu benutzen da bin ich irgendwie auch skeptisch. Wenn ich nen Pool habe wo 2 HDDs ausfallen können dann hätte ich bei einem Mirror als Special Devices ja nur ein Laufwerk was ausfallen kann für kompletten Datenverlust.

So wie ich das sehe hat ZFS aber auch noch keinen "normalen" Schreibcache wo einfach alle Daten die reinkommen erstmal zwischengespeichert werden. Sprich wenn der Pool nur 300MB/s macht, man aber 10Gbit hat, zumindest für die ersten 100GB durch die Optanes hier das 10Gbit Ethernet ausgelastet werden könnte.

Dedup Table wäre nice, aber dann würde ich vermutlich nen Mirror Pool machen nur mit den beiden Optanes und dadrauf dann VMs packen...

Ich seh es vereinfacht bisschen so: HDD für große Dateien, Backups und Archive Krams, wo SSD (noch) wirtschaftlich keinen Sinn ergibt. Günstige SSDs für das allgemeine Zeug, und teure SSDs oder Optanes für so Dinge wie VMs, Datenbanken usw.

 

[gea]

Als "Special Devices" zu benutzen da bin ich irgendwie auch skeptisch. Wenn ich nen Pool habe wo 2 HDDs ausfallen können dann hätte ich bei einem Mirror als Special Devices ja nur ein Laufwerk was ausfallen kann für kompletten Datenverlust.

Special vdev macht man auch als Mirror. Ein Optane Mirror ist viel zuverlässiger als der HD Mirror

So wie ich das sehe hat ZFS aber auch noch keinen "normalen" Schreibcache wo einfach alle Daten die reinkommen erstmal zwischengespeichert werden. Sprich wenn der Pool nur 300MB/s macht, man aber 10Gbit hat, zumindest für die ersten 100GB durch die Optanes hier das 10Gbit Ethernet ausgelastet werden könnte.

Schreibcache ist bei ZFS ausschliesslich RAM. Ein Special vdev kann man allerdings fnicht nur für Metadata, Small Files sondern auch komplett für kritische Dateisysteme nehmen

Dedup Table wäre nice, aber dann würde ich vermutlich nen Mirror Pool machen nur mit den beiden Optanes und dadrauf dann VMs packen...

Special Vdev speichert auch dedup tables. Bei Dedup solte man aber nur Oracle Solaris Dedup2 oder OpenZFS Fast Dedup nehmen (wird in OmniOS gerade integriert)

Ich seh es vereinfacht bisschen so: HDD für große Dateien, Backups und Archive Krams, wo SSD (noch) wirtschaftlich keinen Sinn ergibt. Günstige SSDs für das allgemeine Zeug, und teure SSDs oder Optanes für so Dinge wie VMs, Datenbanken usw.

Darum Special Vdev, da kann man das flexibel je Dateisystem entscheiden wo was liegen soll.

 

[asm@s24]

Was kann man noch mit 2 Optane P1600X mit 118GB anstellen sinnvolles?

Allein die winzige Größe läßt mich sagen: gar nichts.
Hab für meinen z1 Rost-Pool im 2x2TB special vdev ~500G an small blocks und SSD-only-VMs. Und das rennt.

 

[CommanderBond]

Darum Special Vdev, da kann man das flexibel je Dateisystem entscheiden wo was liegen soll.

Aber das könnte ich doch bei einem reinen Optane Mirror Pool auch? Was wäre denn genau der Vorteil dem SATA SSD Pool die beiden Optanes als special vdev anzuhängen statt einfach nen weiteren pool zu bilden?

Die Optionen wären eigentlich jetzt: Eigenen Optane Pool machen. Oder Optane Pool als special vdev dem SSD SATA Pool unterordnen.

 

[gea]

Aber das könnte ich doch bei einem reinen Optane Mirror Pool auch? Was wäre denn genau der Vorteil dem SATA SSD Pool die beiden Optanes als special vdev anzuhängen statt einfach nen weiteren pool zu bilden?

Die Optionen wären eigentlich jetzt: Eigenen Optane Pool machen. Oder Optane Pool als special vdev dem SSD SATA Pool unterordnen.

Im Prinzip gilt bei mixed load/concurrent read/write als Hausnummer

HD: 50-100 MB/s, 100 iops, 10MB/s sync
SSD: 100-500 MB/s, 5000-30000 iops, 50 MB/s sync
Optane: >1GB/s, > 200000 iops, auch bei steady/concurrent read/write, 300 MB/s sync

Ideal ist damit ein Hybridpool hd + Optane bzw extra SSD pool für VMs (ohne Betrachtung sync write)

 

[CommanderBond]

Ideal ist damit ein Hybridpool hd + Optane bzw extra SSD pool für VMs (ohne Betrachtung sync write)

Was ist denn an einem Hybridpool mit Optane besser als nur Optanes allein?

Mir ist immer noch nicht klar wenn ich nur ein paar große Mediadateien auf meinen HDD Pool schiebe, inwiefern hier Optanes spürbar meine Performance verbessern können.
Ich speichere da nur große Dateien, sonst gar nichts.

Also ich will ja Verbesserung haben so wie ich es aktuell nutze, ich will keinen Hybridpool erstellen und mich dann daran anpassen was Sinn ergibt wenn man einen solchen Pool hat.

Mein Pool hat 4 HDDs und RaidZ2. Also wohlwollend 400MB/s. Selbst wenn eine Optane schneller ist nützt mir das bei Async Writes doch gar nichts. Der Pool wäre für mich immer noch genauso langsam weil die Optanes doch für async gar nicht benutzt werden?

 

[gea]

Für einen User bei Mediadaten wird weder ein Hybridpool noch ein Optane only pool spürbar was bringen, sieht anders aus wenn mehrere versetzt das gleiche Video schauen oder gar parallell schreiben. Insgesamt ist es halt so, ein Optane Pool ist meist relativ klein oder unbezahlbar, ein großer HD Pool mit special vdev ist für bestinmmte Dateisysteme oder Workloads nichr arg viel langsamer für den Bruchteil der Kosten.

 

[CommanderBond]

Irgendwie habe ich immer noch das Gefühl wir reden aneinander vorbei. Ich habe gar nicht vor alle meine Daten auf einen pool zu packen sondern mehrere pools parallel zu betreiben.

Aktuell sitzen meine VMs eh auf einem SSD Mirror Pool. Da wäre es in meinen Augen ein Schritt zurück sie von da auf einen HDD+Optane Pool zu packen.

Also ich trenne meine Mediadaten vom ganzen Rest. Nicht übers Dateisystem sondern die sitzen auf komplett verschiedenen Pools.. Ich betreibe ganz bewusst einen reinen HDD Pool und einen reinen SSD Pool bislang.

Dass ein Optane Pool klein ist stimmt, aber was wenn mir für VMs die 100GB einfach ausreichen?

Die VMs sollen eh auf keinen Fall auf irgendeinen Pool der in irgendeiner Form HDDs beinhaltet.

Würde es wenn überhaupt, also wenn einem die Kapazität der Optanes nicht ausreicht, dann nicht mehr Sinn ergeben SATA SSD + Optanes und den HDD Pool einfach so zu belassen wie er ist?

Für mich ist der HDD Pool eh nur Backup und Archiv so gesehen.. Da nun Optanes vorzuschalten ergibt für mein Verständnis so gar keinen Sinn, außer vielleicht sie würden wirklich als Schreibpuffer fungieren, was sie aber wie ich gelernt habe wohl nicht machen.

Archiv, Mediadaten, Backups => HDD Pool
VMs => Optane Pool
Dokumente, Bilder = > SSD Pool,

 

[gea]

Special Vdev ist für Dateien für die er konfiguriert wird (können Metadaten aber auch komplette VMs sein) kein Schreibpuffer, sondern endgültiger Speicherort auf die lesend und schreibend mit Optane Performance zugegriffen wird - ohne dass etwas umkopiert werden muss.

Ist aber wie vieles in ZFS eine Option, kann man nutzen, muss man nicht.

 

[CommanderBond]

Ja ich bin nur etwas skeptisch weil manche Dateien/Blöcke auf HDD, andere auf den Optanes erhöht ja alles die Komplexität. Ich denke mir ein Pool ganz klassisch ohne so "Sonderlocken" ist am Ende einfach zuverlässiger auch was potentielle Bugs angeht...

Nur wenn die VMs sowieso nicht auf einen Pool kommen sollen in dem auch HDD werkeln ist es denke ich so oder so eher uninteressant für mich. Da würde Optane + SATA SSD warscheinlich noch eher Sinn ergeben.

Bis auf Videos und Backups habe ich nur Daten die problemlos auf 2TB SSDs unterzubringen sind. Bei so kleinen Datenmenge brauche ich nicht mit HDDs anzufangen. Ja SSD Speicher kostet zwar immer noch ne Ecke mehr als HDD, ist mir bei so kleinen Mengen aber egal.

 

[asm@s24]

... erhöht ja alles die Komplexität. Ich denke mir ein Pool ganz klassisch ohne so "Sonderlocken" ist am Ende einfach zuverlässiger auch was potentielle Bugs angeht...

Vielleicht ist ZFS einfach überhaupt nix für Dich.

 

[gea]

Vielleicht ist ZFS einfach überhaupt nix für Dich.

Alles was mehr als 50% der ZFS Features hat, ohne ZFS zu sein, ist erheblich komplizierter als ZFS.
Das wäre dann wie "CDU/CSU Technologieoffenheit"=Ineffizienz und Dämlichkeit

 

[Pandora]

Mir ist immer noch nicht klar wenn ich nur ein paar große Mediadateien auf meinen HDD Pool schiebe, inwiefern hier Optanes spürbar meine Performance verbessern können.

Performance wohl nicht, aber die "flupdizität" Wollte das mit dem special vdev schon länger mal testen, aber theoretisch soll reines filebrowsing laut KI dann auf SSD niveau liegen. Musst du mal auslesen was du an Metadaten hast um zu sehen ob die Optane da überhaupt groß genug ist und profitieren tust dann auch nur bei neu geschriebenen Daten, verschieben lassen sich die Metadaten afaik nicht.

 

[HansBohne]

Naja privat==Familienzugriff reicht auch ein einfaches zfs bis 10 gbit locker

 

[gea]

Musst du mal auslesen was du an Metadaten hast um zu sehen ob die Optane da überhaupt groß genug ist und profitieren tust dann auch nur bei neu geschriebenen Daten, verschieben lassen sich die Metadaten afaik nicht.

Metadaten sollten nicht mehr als 0,5% der Daten ausmachen also 100GB bei einer vollen 20TB Platte. Gravierender sind small files, also z.B. Officefiles <= 128K. Da kann mehr zusammenkommen. Wenn man recsize<=smallblocksize setzt, wandern alle Daten z.B. auch große VMS auf das special vdev. Da kanns schnell eng werden.

Mit zfs rewrite kann man aber nachträglich Dateien zwischen hd vdevs uns flash special vdevs verschiebem

 

[asm@s24]

Wenn man recsize<=smallblocksize setzt, wandern alle Daten z.B. auch große VMS auf das special vdev. Da kanns schnell eng werden.

Umgekehrt. smallblocksize<=recsize.
Ich hab 512k / 1M und damit füll ich das 1TB svdev knapp zur Hälfte bei ~8TB gesamt. Wobei da sogar ~200GB VMs & LXC komplett draufliegen.
Wenn ich meinen Datenbestand analysiere, dann fällt auf, daß small blocks echt wenige sind. Ich halte den default von 128k für nicht mehr zeitgemäß. Der ist wie alt, 40 Jahre?

 

[gea]

Recsize ist die maximale Blockgröße (ausser bei Draid) die ZFS dynamisch verwendet. Smallblocksize definiert bis zu welcher Größe diese auf dem Special Vdev landen. Will man alle ZFS Blöcke auf dem Special Vdev, dann müssen alle ZFS Blocke kleiner oder gleich sein, also recsize<=smallblocksize.

128K recsize ist ein sehr guter Kompromis für beliebige Daten. Bei Videos ist 1M besser geeignet, bei VM Storage eher 32-64K

 

[CommanderBond]

aber theoretisch soll reines filebrowsing laut KI dann auf SSD niveau liegen. Musst du mal auslesen was du an Metadaten hast um zu sehen ob die Optane da überhaupt groß genug ist und profitieren tust dann auch nur bei neu geschriebenen Daten, verschieben lassen sich die Metadaten afaik nicht.

Ja nur brauch ich das nicht

Bei Videofiles kann man einfach auch tools wie Kodi usw nutzen, die erstellen dir dann ne Datenbank mit den Videos/Filmen die du hast. Da muss das ganze dann nur einmal gescannt werden und fertig.

Wenn man jetzt ganz viel Bilder hat und hauptsächlich per SMB drauf arbeitet oder Videoschnitt macht und sowas dann mags nochmal was anderes sein, aber bei so einem einfachen Archiv sehe ich den Mehrwert echt nicht.
Sinn ergibt das doch eigentlich erst dann wenn man soviele Daten hat wo man sich sagt einen SSD Pool in der Größe den will man sich nicht leisten, also baut man sich mit special vdevs dann etwas was leistungstechnisch in die Nähe kommt und muss nur paar Prozent der Gesamtkapazität als SSD/Optane kaufen.

Aber verstehe ich das richtig dass man das ganze auch wieder zurückbauen kann? Also ich kann special vdevs hinzufügen, aber auch wieder entfernen falls ich sie doch nicht mehr haben will?

 

[gea]

Sinn ergibt das doch eigentlich erst dann wenn man soviele Daten hat wo man sich sagt einen SSD Pool in der Größe den will man sich nicht leisten, also baut man sich mit special vdevs dann etwas was leistungstechnisch in die Nähe kommt und muss nur paar Prozent der Gesamtkapazität als SSD/Optane kaufen.

genau das ist der Sinn von Hybridpools mit großen langsamen hd vdevs + schnellen flash special vdev

Aber verstehe ich das richtig dass man das ganze auch wieder zurückbauen kann? Al
so ich kann special vdevs hinzufügen, aber auch wieder entfernen falls ich sie doch nicht mehr haben will?

Ja aber nur wenn der Pool nur aus Mirror besteht (kein Raid-Z) und alle vdev gleichen ashift haben