[Sammelthread] ZFS Stammtisch

[ces]

Ein Problem mit keep month besteht bei allen Versionen bis gestern.
Behoben ist das Problem erst in der 22.dev vom 22.3. und in der 22.02b und 22.03b.

Ahh, ok, besten Dank für's nochmal drüber gucken und Fixen!

 

[Bierjpg]

Ok, noch eine Frage zu ZFS:
Gibt es eine Möglichkeit eine art "Master-dataset" zu erzeugen, welches die Gesamtauslastung des Pools anzeigt?

Ich möchte z.b. die Datasets:
Karibik 100 GB Kapazität
Karibik/ISOs 5gb belegt
Karibik/Bilder 4gb belegt
Karibik/Daten 10gb belegt
Karibik/NotebookBackups 1gb belegt
etc anlegen. Damit ich die getrennt von einander Konfigurieren kann.

Wenn ich nun eine Samba Freigabe für /mnt/Karibik erstelle (mountpoint von dem Storage)
wird mir unter einem Windows Client nur der freie Speicher angezeigt und nicht wie viel belegt ist. (was ja auch an sich richtig ist, da in Karibik keine Daten liegen....
Also: 0gb belegt / 80gb Kapazität
Ich würde allerdings gerne die Gesamtgröße des Storages und die Auslastung sehen können.
Also: 20gb belegt / 100gb Kapazität

Ist dies möglich zu realisieren?
Muss ich hier mit sub datasets Arbeiten?
Karibik/root/ISOs
Karibik/root/Bilder

 

[Luckysh0t]

@Bierjpg
Also ich sehe bei meinem ersten Dataset die gesamte Kapazität vom Pool inkl. belegt, bei dem dem ich danach angelegt habe, ist der maximale Speicher das was insgesamt Frei ist (Zum Zeitpunkt der anlegung).Nutze allerdings auch keine Reservierung etc.

 

[Trambahner]

Bei mir (FreeBSD als Basis) genauso wie bei Lucky.

 

[gea]

Ok, noch eine Frage zu ZFS:
Gibt es eine Möglichkeit eine art "Master-dataset" zu erzeugen, welches die Gesamtauslastung des Pools anzeigt?

Ich möchte z.b. die Datasets:
Karibik 100 GB Kapazität
Karibik/ISOs 5gb belegt
Karibik/Bilder 4gb belegt
Karibik/Daten 10gb belegt
Karibik/NotebookBackups 1gb belegt
etc anlegen. Damit ich die getrennt von einander Konfigurieren kann.

Wenn ich nun eine Samba Freigabe für /mnt/Karibik erstelle (mountpoint von dem Storage)
wird mir unter einem Windows Client nur der freie Speicher angezeigt und nicht wie viel belegt ist. (was ja auch an sich richtig ist, da in Karibik keine Daten liegen....

Prinzipiell sollte sich SAMBA überall gleich verhalten, egal ob FreeBSD, Linux oder Solarish. Allenfalls zwischen SAMBA und dem Solarish ZFS basierten SMB Server kann es ein unterschiedliches Verhalten geben. Unter OmniOS wird mir aber auch frei von.. angezeigt.

Insgesamt ist es aber so bei ZFS:
- Ein ZFS Pool ist ein "Parent" ZFS Dateisystem daß so groß ist wie die Nutzkapazität der Platten (abzüglich Redundanz).

- Legt man Dateisysteme darunter an, so haben die im Gegensatz z.B. zu Windows Partitionen keine bestimmte Größe sondern können den gesamten Pool belegen. Wächst der Pool nachträglich, können auch die Dateisysteme entsprechend wachsen.

- Möchte man das nicht, kann man Quotas setzen um den Platz je Dateisystem (User|Projekt) zu begrenzen.

- Möchte man einen garantierten Platz je Dateisystem, so kann man Reservierungen setzen. Die Reservierung reduziert den für andere Dateisysteme verfügbaren Speicher.

ps
SAMBA weiß nichts von ZFS, es sieht nur "einfache Ordner" im Dateisystem. Es verhält sich daher teils anders als z.B. Solarish wo ein SMB Share immer eine Eigenschaft eines ZFS Dateisystems ist.

 

[CommanderBond]

Kann man TrueNAS und Omnios eigentlich auch „mischen“ ? Hintergrund ist ich habe einen Gen10P und betreibe dort aktuell 4x14TB. Will den PCIe Port wovon es nur einen gibt aber für eine schnellere Netzwerkkarte benutzen, ergo bleibt nur der USB Port fürs OS übrig. OmniOS will damit zumindest bei diesem Gerät nicht so recht funktionieren.
Daher mein Plan TureNAS zu installieren. Das ganze ist nur ein Backupserver, sprich dort sind Backups und ein Filmarchiv.
Der Hauptserver soll OmniOS sein.

Frage: Kann ich Replications dann nutzen und sie von OmniOS an TrueNAS schicken oder geht das nicht?

 

[mrpasc]

Generell funktioniert ZFS send/receive Betriebssystem-Unabhängig. Wahrscheinlich wird aber das in Napp-IT integrierte Replication nicht out of the box funktionieren, da ist evtl. Eigenes scripting notwendig.
Hinweis: Bei den aktuellen Truenas Versionen, egal ob Core oder Scale wird auch dringend von USB Sticks als Boot device abgeraten. Nimm einen USB3 mSata oder NVMe Adapter und ne kleine gebrauchte mSata oder NVMe SSD. Ich boote meine TueNasen von Intel Optane M10 32GB Sticks, die kriegst du bei ebay für kleines Geld.
Zusatz - Idee: Falls du eine 10GBit Base-T Karte verwenden willst wirf einen Blick auf das hier:
QNAP QM2-2P10G1TA. 2 NVMe + 1 10GB Base-T auf einer Karte. Am Ende dieses Artikels werden Vor- und Nachteile schön erklärt.

HPE ProLiant MicroServer Gen10 Plus Ultimate Customization Guide

Our ultimate customization guide for the HPE ProLiant MicroServer Gen10 Plus where we show what can be done with CPUs, memory, storage, NICs, and iLO

www.servethehome.com

Aber Achtung: ist ein Aquantia Chipsatz, funktioniert mit Truenas Scale (Debian) aber nicht mit Core (BSD)

 

[gea]

Frage: Kann ich Replications dann nutzen und sie von OmniOS an TrueNAS schicken oder geht das nicht?

Ja, z.B. mit zfs send via ssh oder netcat z.B.

Fast ZFS Send with Netcat

The general way to send ZFS data sets to remote nodes is normally achieved by sending the ZFS stream through ssh. Example: zfs send zones/UUID@snapshot | ssh root@10.10.11.5 zfs recv zones/UUID T…

blog.yucas.net

 

[CommanderBond]

Generell funktioniert ZFS send/receive Betriebssystem-Unabhängig. Wahrscheinlich wird aber das in Napp-IT integrierte Replication nicht out of the box funktionieren, da ist evtl. Eigenes scripting notwendig.
Hinweis: Bei den aktuellen Truenas Versionen, egal ob Core oder Scale wird auch dringend von USB Sticks als Boot device abgeraten. Nimm einen USB3 mSata oder NVMe Adapter und ne kleine gebrauchte mSata oder NVMe SSD. Ich boote meine TueNasen von Intel Optane M10 32GB Sticks, die kriegst du bei ebay für kleines Geld.
Zusatz - Idee: Falls du eine 10GBit Base-T Karte verwenden willst wirf einen Blick auf das hier:
QNAP QM2-2P10G1TA. 2 NVMe + 1 10GB Base-T auf einer Karte. Am Ende dieses Artikels werden Vor- und Nachteile schön erklärt.

HPE ProLiant MicroServer Gen10 Plus Ultimate Customization Guide

Our ultimate customization guide for the HPE ProLiant MicroServer Gen10 Plus where we show what can be done with CPUs, memory, storage, NICs, and iLO

www.servethehome.com

Aber Achtung: ist ein Aquantia Chipsatz, funktioniert mit Truenas Scale (Debian) aber nicht mit Core (BSD)

Hab sogar noch ne M10 meine ich. Punkt ist halt der dass ich den PCIe Schacht für was anderes benötige. Mit nem USB Stick hatte ich zumindest vor einem Jahr mal versucht OmniOS zu installieren was nicht von Erfolg gekrönt war. Ist auch nicht der erste Server bei dem das so ist. Das Problem scheint mit USB3 zu tun zu haben weil bei Servern wo ich die Ports auf USB 2.0 stellen kann läuft es ohne Probleme.
Wenn ich Zeit und Lust habe probier ich es vllt nochmal aus aber ich vermute ganz stark ein NVMe USB Adapter wird hier nichts nützen

 

[mrpasc]

Der Gen10+ hat doch einen internen USB2 Slot?
Probier doch da mal nen guten USB Stick als Boot drive? SanDisk Cruzer Fit wird oft empfohlen. Gibt's noch als USB2.
SanDisk Cruzer Fit USB... https://www.amazon.de/dp/B07MDXBTL1?ref=ppx_pop_mob_ap_share

 

[besterino]

Muss das einfach mal los werden: (M)ein Abschied von Oracle Solaris.

Es ist jetzt leider doch so weit, ich mustere sehr schweren Herzens Oracle Solaris aus. Seit (erst?) ca. 2016 ist es der zuverlässige und für mich sehr lieb gewonnene Unterbau für alles rund um mein "zentrales Storage" - einmal installiert & halbwegs verstanden tat es das was es soll und bei IT doch so selten ist: es lief und lief und lief und lief. Ohne Schluckauf, ohne Datenverlust, ohne (ungeplante) Unterbrechung. Und das, obwohl ich nur mit der (halbwegs) freien Version ohne Updates unterwegs war. Zunächst in der Version 11.3, später dann auch (teilweise) mit 11.4. Für mich ist Oracle Solaris nach wie vor das non-plus-ultra in Sachen ZFS bzw. Datenintegrität-/sicherheit und Features - und die frei zugängliche Doku dazu ist auch der absolute Hammer. Kombiniert mit Napp-It das Beste aus allen Welten. Wie gesagt: für mich.

Mit der Zeit hat sich allerdings doch eine gewisse Diskrepanz zwischen "will ich" und "macht auch Solaris mit" offenbart: Gerade bei der Unterstützung von neuer(er) Hardware sah & sieht es mit Solaris eher düster aus - zumindest für Home-Anwender (die auch mal abseits der Kompatibilitätslisten einkaufen wollen/müssen) und in der freien Version, der bis vor Kurzem jegliche Updates seit Release verschlossen blieben und schon die Release-Version sehr wählerisch war.

Zuletzt hatte ich noch Hoffnung, dass mit der Umstellung bei Solaris 11.4 auf regelmäßige(re) Updates auch für die freie Version Besserung kommt. Aber leider nicht für mich:

1. Immerhin gibt es jetzt teilweise funktionale Treiber für die ConnectX-4/5/6/7 NICs. Teilweise, weil mit Solaris in einer VM SR-IOV (immer noch) nicht funktioniert.

2. Mit NVMe's oder anderen Storage-Komponenten sieht es leider aber immer noch finster aus: mein Avago (LSI) 9305/24i wird trotz Updates immer noch nicht gescheit erkannt und steckt man die falsche NVME ins System, bootet weder der Installer noch ein vorher installiertes System. Und "falsche" NVMEs sind dummerweise quasi alle, die ich habe (alles m.2): Intel, Samsung, WD, ADATA... (sowohl aus dem Consumer oder OEM/Datacenter Regal). Solaris hätte da wohl gerne was Professionelleres in Form von u.2 & Co. - damit kann ich aber leider nicht aufwarten.

3. Auch scheint Solaris mit meiner - zugegeben weit jeglicher QVL liegenden - Grund-Hardware ganz eigene Probleme zu haben: auch ohne sonstige Hardware-Sonderlocken schmeisst Solaris in einer VM auf einem TR3960X Fehlermeldungen, zu denen selbst google nichts Passendes findet (z.B. "Warning: too many mc's" oder behauptet, dass irgendwelche DIMM-Riegel keine "unique ID" hätten - lustig bei einer VM). RAM-Warnungen passen aber nicht zu meiner Vorstellung eines sauberen Storage-Setups. (Und nein, der (ECC)RAM ist völlig ok, weder der Host noch Tests noch sonstwas meldet irgendwelche Fehler.)

Dass es nicht (nur) an meiner individuellen Konfiguration liegt, zeigt der Direktvergleich mit TrueNAS: gleiche Hardware, gleiches Setup (ESXi-VM), und alles wird erkannt & läuft, ohne Fehlermeldungen.

In der Zukunft dürfte es wohl auch nicht mehr wirklich besser werden: Solaris-Support ist schon bei Oracle selbst endlich/zweifelhaft, auch vmware unterstützt es m.W. seit ESXi-Version 7 auch nicht mehr (offiziell) als Gast-OS - die guest additions sind schon irgendwann seit 6.7 nicht mehr weiterentwickelt worden. Und die Zusammenarbeit mit Windows (SMB-Direct & Co.) dürfte auch nicht besser werden.

Lange Rede kurzer Sinn: ich probier' mein Glück jetzt mal mit TrueNAS (Core). Core, weil FreeBSD in meinen Augen immer noch näher am Original "dran" ist als Linux. Und ein anderes "Solarish" habe ich nicht mehr näher in Betracht gezogen, weil ich mit OmniOS/Illumos ähnlich schlechte Erfahrungen gemacht habe (Support für die ConnectX sehr zweifelhaft). Auch bei TrueNAS ist nicht alles perfekt (insb. zu viel Gelumpe an Bord, das ich nicht brauche, einige ZFS-Features fehlen und wieder SAMBA nötig), aber die Nachteile sind für mich verschmerzbar(er).

Hab bereits die wesentlichen Storage Pools umgezogen / neu aufgesetzt, NFS als VM-Storage läuft und auch die wesentlichen SMB-Freigaben rennen wieder. Insgesamt hat mich die Migration zu TrueNAS "from scratch" deutlich weniger Zeit gekostet, als die vorangegangenen Versuche, Solaris 11.4 zur Zusammenarbeit zu überreden... Für eine gewisse Übergangszeit bleiben nun nur noch zwei Solaris Backup-Pools inkl. passende Solaris-VM in der Schublade.

Trotzdem: Schadeschadeschade. Oracle's Solaris wird immer einen besonderen Stellenwert bei mir haben. Selten kommt man heutzutage gefühlt noch so nah ran an den Maschinenraum eines OS und greift alles so sensationell unproblematisch ineinander wie hier... Back to the roots & console rulez irgendwie immer noch!

 

[Digi-Quick]

Moin Besterino,
Ich könnte mir vorstellen, daß XigmaNAS deinen Ansprüchen sogar noch etwas näher kommt als TrueNAS, könnte allerdings sein, daß TrueNAS die aktuellere Codebase nutzt (die wechseln sich da gerne ab).

 

[besterino]

Ach Du, eins nach dem anderen. Wenn’s einmal läuft, pack ich das die nächsten 5 Jahre nicht mehr an…

Aktuell kämpfe ich (mal wieder) mit ESXi und der Connectx-4 - konkret gelingt es mir uns Verrecken nicht, SR-IOV auf beiden Ports zu aktivieren…

 

[Luckysh0t]

@besterino
Ich schätze mal dass du das hier schon gefunden hast ?

NVIDIA Networking Docs

docs.nvidia.com

 

[Trambahner]

Xigmanas würde ich denken, dass da bald ne Version auf Basis FreeBSD 13 kommt und damit OpenZFS per default. Zumindest haben die Admins da schon ne Versionsnummer 13.x.x.x. in der Signatur.

 

[mrpasc]

Truenas Core 13 ist aber doch auch schon ne Weile als Beta und seit kurzem als Release Canditate verfügbar. Ist auch FreeBSD 13

 

[besterino]

@Luckysh0t …jojo, da bin ich gefühlt schon weit drüber hinaus…

Zumindest funktioniert SR-IOV wirklich nur auf einem Port und das auch nur, wenn ich die max. Virtual Functions auf 4 beschränke - obwohl eigentlich jeder PORT 8 können sollte?! Firmware ist aktuell, Treiber auch… ESXi bei der Gelegenheit auch mal auf den aktuellen Stand gebracht. Ich bin mir 100%ig sicher, dass ich irgendwann mit der NIC schonmal 4+4 virtual functions funktionsfähig (!) hatte - aber evtl. auf nem anderen Mainboard, da bin ich grad nicht mehr sicher…

Naja, hab jetzt brute-force den 2. Port komplett per pci-passthrough in die VM geknallt. Außer der VM braucht den aktuell eigentlich eh keiner…

Muss vielleicht doch mal ein gescheites Supermicro Epyc Board her… mir gehen eh schon wieder die CPU-Lanes aus… alles Käse.

Immerhin, alle disks stehen endlich bereit für alles Weitere:

Spoiler

*nerv* gerade festgestellt, dass TrueNAS nichtmal nen DHCP-Server nativ kann und man dann schon für sowas nen Plugin/VM braucht... wirklich alles Käse. Vielleicht muss ich doch nochmal OmniOS ne Chance geben...?

 

[Bierjpg]

Ich selbst setze ja jetzt auf Debian 11 + OpenZFS aus den Debian 11 Paketquellen. Das ganze rennt bisher Solide. Abgesehen, dass ich noch im meinen ersten Schritten mit ZFS stecke. Ich wollte ein solides Betriebssystem.

Wie habt ihr Spezial_Small_Blocks gesetzt?
Ich habe es jetzt auf 4k eingestellt.
Damit sollten alle kleinen Dateien, wie Textdokumente etc auf den SSDs landen.

Ich bin aktuell am überlegen einen Zweiten Pool für VMs aufzusetzen mit diesen SSDs:

Micron 3400 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für Micron 3400 2TB, M.2 2280 / M-Key / PCIe 4.0 x4 ✔ Produktinfo ⇒ Kapazität: 2TB (entspricht ca. 1862.65GiB bzw. 1.82TiB, weiterführende Informationen hierzu ) • Bauform: … ✔ Solid State Drives (SSD) ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Allerdings fehlt mir hier etwas an Informationen wie viel Power-Loss Protection notwendig ist.

Es gibt ja mehrere Stufen.
1. Keine Power-Loss Protection ---> Bei Stromausfall kann das Dateisystem beschädigt werden, wenn grade an den SSD Internen Metadaten gearbeitet wird.
2. Power-Loss Protection (data at rest) ---> An sich Marketing, allerdings geht hier nur der Cache verloren und das Dateisystem / Internen Metadaten sind sicher.
3. Power-Loss Protection ---> Cache ist sicher. Daten auf der SSD sind sicher.

Da die Micron 3400 keinen DRAM drauf hat. Muss sie alle Daten eigentlich direkt wegschreiben. Die internen Metadaten sind sicher. Es könnten wenn ich das richtig sehe nur die letzten paar KB verloren gehen, welche zur SSD gesendet wurden.
Hier ist die Frage wie ZFS reagiert....

Najo soweit dazu

 

[gea]

Allerdings fehlt mir hier etwas an Informationen wie viel Power-Loss Protection notwendig ist.

Es gibt ja mehrere Stufen.
1. Keine Power-Loss Protection ---> Bei Stromausfall kann das Dateisystem beschädigt werden, wenn grade an den SSD Internen Metadaten gearbeitet wird.
2. Power-Loss Protection (data at rest) ---> An sich Marketing, allerdings geht hier nur der Cache verloren und das Dateisystem / Internen Metadaten sind sicher.
3. Power-Loss Protection ---> Cache ist sicher. Daten auf der SSD sind sicher.

Da die Micron 3400 keinen DRAM drauf hat. Muss sie alle Daten eigentlich direkt wegschreiben. Die internen Metadaten sind sicher. Es könnten wenn ich das richtig sehe nur die letzten paar KB verloren gehen, welche zur SSD gesendet wurden.
Hier ist die Frage wie ZFS reagiert....

Es gibt den kritischen Zustand:

- Das System stürzt während des Schreibens ab oder der Strom fällt aus. Kritisch ist auch Garbage Collection, die interne Optimierung der SSD durch den Controller. Auch da werden Daten umkopiert die im worst case bei Stromausfall verloren sind, https://hardwrk.com/blog/trim-vs-garbage-collection-was-ist-der-unterschied

ZFS versucht zwar sein Dateisystem mit Copy on Write zu schützen. Dabei werden bei Datenänderung ZFS Blöcke immer neu geschrieben und nur im Erfolgsfall aktiviert. Ein Absturz beim Schreiben führt da nur dazu dass der alte Datenstand gültig bleibt. Das funktioniert aber nur, wenn nicht außerhalb der Kontrolle von ZFS Daten verändert werden.

Mechanische Festplatten und SSD mit "voller" Powerloss Protection sind sicher. SSD die das nicht garantieren sind nicht sicher. Im Zweifel sind nur die Datacenter SSD von Markenherstellern mit garantierter Powerloss Protection sicher.

Man muss sich immer im Klaren sein. Schnelle billige SSD gehen nur mit Abstrichen bei der Sicherheit. Das sieht man daran dass billige Desktop SSD oft "bessere" Werte haben als Datacenter SSD. Da wird dann nicht nur weniger "geschönt" sondern die garantierte Sicherheit kostet Aufwand und Performance. Da geht es nicht nur um Absicherung eines Dram Caches mit einem Condensator sondern auch um Aufwand im Controller und der Firmware.

Auch das Fehlen eines Caches ist keine absolute Sicherheit. Hätte eine derartige SSD volle Powerloss Protection, würde das der Hersteller angeben. Gut sieht man das bei Intel und Optane. Die haben keinen Cache und sind alle vermutlich unkritisch. Bei den "Gamer" Modellen wird plp aber nicht garantiert. Kann in Einzelfällen Marketing sein wie bei der Optane 900.

Wenn man mit Datensicherheit nicht spekulieren will, ist garantierte plp bei SSD ein Muß genau wie ECC bei RAM. Auch ZFS kann nur so sicher sein wie die Hardware auf der es betrieben wird. Fehler auf der Hardware können auch ZFS beschädigen, auch wenn ZFS meist gutmütiger reagiert als ext4 oder ntfs.

 

[Luckysh0t]

@besterino
Nutzt du esxi 6.x oder 7 ?

Du lässt deine Storage VM auch DHCP Server spielen ?

Habt ihr in unterforen auch eine https warnung ?

 

[gea]

*nerv* gerade festgestellt, dass TrueNAS nichtmal nen DHCP-Server nativ kann und man dann schon für sowas nen Plugin/VM braucht... wirklich alles Käse. Vielleicht muss ich doch nochmal OmniOS ne Chance geben...?

OmniOS ist keine NAS Distribution sondern ein vollwertiges Server Betriebssystem auch mit DHCP, https://omnios.org/info/isc-dhcp.html und anderen Tools z.B. via pkgsrc, http://pkgsrc.joyent.com/packages/SmartOS/

Wobei ich DHCP @work via AD und zuhause via Telekom Router nutze.

Im Vergleich zu Linux sind die angebotenen Apps aber deutlich geringer. Schwerpunkt sind Server Anwendungen der Firmen die hinter Illumos stehen (Joyent, Nexenta sowie Citrus/ UK und Oetiker/ Schweiz bei OmniOS). Was Solaris und OmniOS einzigartig macht ist der Grad der Integration von ZFS in die Betriebssysteme und Dienste wie FC/iSCSI, NFS und insbesondere SMB sowie der "tut einfach" Faktor auch bei den halbjährigen OS sowie den Security und Bugfix Updates alle 2-4 Wochen. Liegt nicht zuletzt daran dass OmniOS ein eigenes Repository je halbjähriges OS stable Release pflegt (LTS zwei Jahre). Das hat nichtmal Bezahl-Solaris.

 

[besterino]

@Luckysh0t 6.7 und Jain: mein Hauptnetz wird vom Router versorgt. Ich hätte aber gerne noch ein spezielles Storage-Netz. Dafür wäre eine eigene VM doch sehr over the top und ein simpler DHCP-Server genau an einer bestimmten NIC (für nur dieses Subnetz) genau das, was ich gerne hätte. Ist aber vor allem Bequemlichkeit… zur Not kann ich den paar Clients auch einfach feste IPs geben und fertig.

 

[Bierjpg]

Es gibt den kritischen Zustand:

- Das System stürzt während des Schreibens ab oder der Strom fällt aus. Kritisch ist auch Garbage Collection, die interne Optimierung der SSD durch den Controller. Auch da werden Daten umkopiert die im worst case bei Stromausfall verloren sind, https://hardwrk.com/blog/trim-vs-garbage-collection-was-ist-der-unterschied

Wenn ich das richtig verstanden habe hilft hiergegen die von Micron angegebene Power-Loss Protection (data at rest). Sollte also eigentlich kein Risiko darstellen.

https://www.micron.com/-/media/client/global/documents/products/white-paper/ssd_power_loss_protection_white_paper_lo.pdf

Sprich alles was Intern auf der SSD an Garbage Collection etc angeht ist sicher.

ZFS versucht zwar sein Dateisystem mit Copy on Write zu schützen. Dabei werden bei Datenänderung ZFS Blöcke immer neu geschrieben und nur im Erfolgsfall aktiviert. Ein Absturz beim Schreiben führt da nur dazu dass der alte Datenstand gültig bleibt. Das funktioniert aber nur, wenn nicht außerhalb der Kontrolle von ZFS Daten verändert werden.

Hier wird es Interessant.
Da die Micron SSD ja garkeinen DRAM hat, muss alles was zur SSD gesendet wird recht schnell weg geschrieben werden.
Wenn jetzt die letzten 0.2 Sekunden fehlen wäre das in meinem Anwendungsfall nicht von Relevanz ( da ehh jeder Job der auf den VMs lief abgebrochen wurde...)

Mechanische Festplatten und SSD mit "voller" Powerloss Protection sind sicher. SSD die das nicht garantieren sind nicht sicher. Im Zweifel sind nur die Datacenter SSD von Markenherstellern mit garantierter Powerloss Protection sicher.

Schon klar. Daher habe ich ja auch entsprechende SSDs für den Main Pool genommen.

Man muss sich immer im Klaren sein. Schnelle billige SSD gehen nur mit Abstrichen bei der Sicherheit. Das sieht man daran dass billige Desktop SSD oft "bessere" Werte haben als Datacenter SSD. Da wird dann nicht nur weniger "geschönt" sondern die garantierte Sicherheit kostet Aufwand und Performance. Da geht es nicht nur um Absicherung eines Dram Caches mit einem Condensator sondern auch um Aufwand im Controller und der Firmware.

Wir reden bei der Micron SSD eher von etwas im Prosumer / Workstation bereich und nicht im Gaming/billig Segment. Hier hat Micron Crucial aufgestellt

Auch das Fehlen eines Caches ist keine absolute Sicherheit. Hätte eine derartige SSD volle Powerloss Protection, würde das der Hersteller angeben. Gut sieht man das bei Intel und Optane. Die haben keinen Cache und sind alle vermutlich unkritisch. Bei den "Gamer" Modellen wird plp aber nicht garantiert. Kann in Einzelfällen Marketing sein wie bei der Optane 900.

Wenn man mit Datensicherheit nicht spekulieren will, ist garantierte plp bei SSD ein Muß genau wie ECC bei RAM. Auch ZFS kann nur so sicher sein wie die Hardware auf der es betrieben wird. Fehler auf der Hardware können auch ZFS beschädigen, auch wenn ZFS meist gutmütiger reagiert als ext4 oder ntfs.

Genau das ist die Frage. Wie viel kann! beschädigt werden wenn die letzten 0,3 Sekunden an gesendeten Daten verloren gehen.
Ich werde vermutlich 4 SSDs in einem Raid Z1 laufen lassen und regelmäßige snapshots aufs main Storage senden.

Die Frage ist also, Was kann Brennen, wenn die letzten 0.3 Sekunden an gesendeten Daten verloren gehen?

 

[gea]

Die Frage ist also, Was kann Brennen, wenn die letzten 0.3 Sekunden an gesendeten Daten verloren gehen?

Das Problem nicht nur aber vor allem bei VMs ist die Konsistenz des Gast Dateisystems. Ein Pool der ca 100 MB/s sync und damit sicher wegschreiben kann, schreibt in 0,3s 30 MB. Das sind dann nicht nur Daten sondern auch Metadaten. Stimmen die nicht mehr ist das Dateisystem korrupt. ZFS hält die zwar doppelt und ist damit nicht so anfällig wie andere Dateisysteme. Sind aber beide Kopien der Metadaten defekt, kann das auch bei ZFS einen Pool Verlust bedeuten.

Snapshots und Backup helfen nicht. Wie soll man wissen welcher Snapshot und welches Backup noch gut ist und welches defekt? Copy on Write und Prüfsummen bei ZFS decken ja nicht die Konsistenz des Gast Dateisystems ext4 oder ntfs ab sondern nur von ZFS selber.

 

[Bierjpg]

Das Gast Dateisystem ist dabei nicht von Relevanz. Ob der Datenstrom 0.3 Sekunden Später oder früher abbricht hat die selben Folgen. ---> einen Unsafe shutdown.
Hier greifen dann die Festplatten Prüfung von dem Gastsystem. ....

Die Frage ist, kommt ZFS damit ohne weiteres zurecht.

 

[eehm]

Welche 'Record Size" würdet ihr für folgendes Szenario empfehlen?

- NVMe Mirror für VMs (NFS-Datastore für ESXi)
- viele sync-Wirtes (ESXi)

Aktuell habe ich 128 KiB eingestellt. Ist das ein guter Wert oder sollte ich besser in Richtung 4-16 KiB gehen?

 

[gea]

Das Gast Dateisystem ist dabei nicht von Relevanz. Ob der Datenstrom 0.3 Sekunden Später oder früher abbricht hat die selben Folgen. ---> einen Unsafe shutdown.
Hier greifen dann die Festplatten Prüfung von dem Gastsystem. ....

Die Frage ist, kommt ZFS damit ohne weiteres zurecht.

ZFS kommt dank Copy on Write perfekt mit einem plötzlichen Stromausfall zurecht. Das Dateisystem ist sicher - aber nur wenn bestätigte Schreibvorgänge auch tatsächlich auf Platte sind - normalerweise garantiert durch sync write spätestens beim nächsten Reboot.

Hier liegt genau das Problem. Diese Sicherheit kostet Aufwand und Performance mit powerloss protection. Wenn das nicht ohne wenn und aber funktioniert ist dies eben nicht garantiert und Datenkorruption möglich - außerhalb der Kontrollmöglichkeit von ZFS.

Gastdateisysteme sind erheblich kritischer. Wenn da zwischen dem Schreiben von Daten und dem zugehörigen Update der Metadaten deas System abstürzt ist das Dateisystem korrupt. Mangels Prüfsummen und Copy on Write ist das da nicht vermeidbar und nichtmal sicher feststellbar. Aus Sicht von ZFS kann aber alles in Ordnung sein.

ZFS schützt nicht vor defekten Dateien (das sind die Gastdateisysteme aus ZFS Sicht) sondern nur vor defektem ZFS Dateisystem.

Beitrag automatisch zusammengeführt: 10.04.2022

Welche 'Record Size" würdet ihr für folgendes Szenario empfehlen?

- NVMe Mirror für VMs (NFS-Datastore für ESXi)
- viele sync-Wirtes (ESXi)

Aktuell habe ich 128 KiB eingestellt. Ist das ein guter Wert oder sollte ich besser in Richtung 4-16 KiB gehen?

Schlechter Plan.
Alle ZFS Eigenschaften wie z.B. Prüfsummen, compress, encrypt, dedup basieren auf ZFS Blöcken in recsize. Bei so kleinen Werten arbeiten die extrem ineffektiv. Hinzu kommt dass ein Schreibvorgang in Blöcken in recsize erfolgt. Wenn man sich mal z.B. einen Atto Performancetest anschaut merkt man, dass die Performance auch einer NVMe bei 4-8K Blöcken unterirdisch schlecht ist und erst ab ca 64K gut wird. Im Prinzip würde man dafür sorgen dass ZFS async write so niedrig ist wie sync write, z.B. https://www.servethehome.com/wp-content/uploads/2012/11/Samsung-840-Pro-256GB-SSD-ATTO-Benchmark.png

Bei VMs und Gastdateisystemen die intern auf 8k ausgelegt sind, kann es aber Sinn machen die recsize kleiner zu machen damit weniger Daten gelesen/geschrieben werden müssen. Nie jedoch unter 32-64K. Umgekehrt kann bei "normalen, größeren Dateien" eine recsize > 128K optimaler sein.

128K ist ein guter Kompromiss und daher default.

 

[Trambahner]

Ich hab auch default 128K überall, auch wo VMDKs drauf sind. Nur bei Datasets mit großen Medienfiles 1M.

 

[eehm]

Nie jedoch unter 32-64K. Umgekehrt kann bei "normalen, größeren Dateien" eine recsize > 128K optimaler sein.

Danke für den Hinweis, dann werde ich es einfach bei den 128 KiB lassen oder ggf. mal höchstens 64 KiB versuchen.
Die Performance ist bei Lesen sowieso ganz gut nur beim Schreiben ist es nicht so prikend. Aber mit besseren SSDs wäre es sicher noch besser. Bin grad im Testen mit alten 500GB Consumer SSDs

Nur bei Datasets mit großen Medienfiles 1M.

Würde das bei Dateien zwischen 25-70 MB schon Vorteile bringen?
Oder ist das bei einem Foto-Archiv am Ende so und so von der Performance her egal ob ich 128 Kib oder 1 MiB einstelle?

 

[Bierjpg]

ZFS kommt dank Copy on Write perfekt mit einem plötzlichen Stromausfall zurecht. Das Dateisystem ist sicher - aber nur wenn bestätigte Schreibvorgänge auch tatsächlich auf Platte sind - normalerweise garantiert durch sync write spätestens beim nächsten Reboot.

Hier liegt genau das Problem. Diese Sicherheit kostet Aufwand und Performance mit powerloss protection. Wenn das nicht ohne wenn und aber funktioniert ist dies eben nicht garantiert und Datenkorruption möglich - außerhalb der Kontrollmöglichkeit von ZFS.

Diese Sicherheit ist in diesem Anwendungsfall nicht von Nöten. Wichtig ist:
A: das Dateisystem ist nicht zerstört. ---> Man kann ohne weiteres auf alle Daten zugreifen.

Die Virtuellen Maschinen erkennen selbst, dass sie einen Stromausfall hatten und können ihre Dateisysteme Reparieren. Wie viele Windows installationen laufen auf gammel SSDs ohne PLP? Wie viele Linux Systeme tun dies? Sterben sie deshalb wie die Fliegen? Nein.

Solange ZFS an sich überlebt ist alles gut.

Gastdateisysteme sind erheblich kritischer. Wenn da zwischen dem Schreiben von Daten und dem zugehörigen Update der Metadaten deas System abstürzt ist das Dateisystem korrupt. Mangels Prüfsummen und Copy on Write ist das da nicht vermeidbar und nichtmal sicher feststellbar. Aus Sicht von ZFS kann aber alles in Ordnung sein.

ZFS schützt nicht vor defekten Dateien (das sind die Gastdateisysteme aus ZFS Sicht) sondern nur vor defektem ZFS Dateisystem.

Das ist Klar. Allerdings macht es hier absolut KEINEN Unterschied ob ZFS die letzten 0.3 Sekunden geschrieben hat oder nicht. Für das Gastsystem sind BEIDE Situationen das gleiche. Es hat einen instant Power loss und muss sich davon erholen.