Ahh, ok, besten Dank für's nochmal drüber gucken und Fixen!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.
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: this_feature_currently_requires_accessing_site_using_safari
Ahh, ok, besten Dank für's nochmal drüber gucken und Fixen!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.
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....
Frage: Kann ich Replications dann nutzen und sie von OmniOS an TrueNAS schicken oder geht das nicht?
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.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.
Aber Achtung: ist ein Aquantia Chipsatz, funktioniert mit Truenas Scale (Debian) aber nicht mit Core (BSD)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 iLOwww.servethehome.com
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....
*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...?
Wenn ich das richtig verstanden habe hilft hiergegen die von Micron angegebene Power-Loss Protection (data at rest). Sollte also eigentlich kein Risiko darstellen.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
Hier wird es Interessant.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.
Schon klar. Daher habe ich ja auch entsprechende SSDs für den Main Pool genommen.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.
Wir reden bei der Micron SSD eher von etwas im Prosumer / Workstation bereich und nicht im Gaming/billig Segment. Hier hat Micron Crucial aufgestelltMan 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.
Die Frage ist also, Was kann Brennen, wenn die letzten 0.3 Sekunden an gesendeten Daten verloren gehen?
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.
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?
Danke für den Hinweis, dann werde ich es einfach bei den 128 KiB lassen oder ggf. mal höchstens 64 KiB versuchen.Nie jedoch unter 32-64K. Umgekehrt kann bei "normalen, größeren Dateien" eine recsize > 128K optimaler sein.
Würde das bei Dateien zwischen 25-70 MB schon Vorteile bringen?Nur bei Datasets mit großen Medienfiles 1M.
Diese Sicherheit ist in diesem Anwendungsfall nicht von Nöten. Wichtig ist: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.
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.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.