[Sammelthread] ZFS Stammtisch

Kichkich. Da hätteste ja auch fast die 32GB-Variante nehmen können. ;)

Sorry, war zu verlockend. Doof dass die Powerloss Protection nicht vorhanden ist. Wäre bestimmt ein Rückgabegrund (verkehrswesentliche Eigenschaft oder so).
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die fehlende PLP ist ja kein Problem, wenn man eine USV hat.Da investier ich die diff. lieber in eine USV und sichere so den ganzen Server als nur die SSDs kurzeitig ab.

Für welche die diese schon gekauft haben, eben wegen dem PLP ist das natürlich sehr ärgerlich..
 
In dem Fall wohl wirklich nichts - wobei ich dazu sagen muss, ich hatte schon mehr Stromausfälle als defekte Netzteile (0).
Aber klar, einmal ist immer das erste Mal.
 
Zuletzt bearbeitet:
Eine USV alleine ist sicher nicht die Lösung zumal das ohne redundante Netzteile (2. Netzteil am Netz) zusätzliche Ausfälle provoziert. Eher sinnvoll ist eine Risko/ Preisabwägung.

Wenn man sicheres Schreiben benötigt, muss man sync aktivieren weil sonst der gesamte Schreibcache gefährdet ist (sagen wir mal 4GB Daten die vom OS als "sind auf Platte" bestätigt sind). Für normale Platte bedeutet das aber einen Einbruch der Performance auf 20%

Für ein kritisches System ist es keine Frage. Der Hersteller muss bei einem Slog die Datenkonsistenz beim Stromausfall garantieren. Die überragende Performance von Optane läßt dann keine Alternativen offen und für meine ZeusRam habe ich mehr bezahlt als eine Optane 4800 kostet. Die 4800x ist also alternativlos bis Intel was billigeres bietet.

Das Slog muss aber nicht den gesamten Cacheinhalt garantieren sondern nur den letzten bestätigten Commit + dass der Controller keinen Mist beim Stromausfall macht = dass der Crash nicht die Daten im Log beeinträchtigt. Das Risiko ist also überschaurer. Ist zwar blöd wenn die eine fehlerhafte Aktion eine Finanztransaktion war oder ein Matadaten Eintrag der für die Konsistenz des Dateisystems wichtig ist. Im Fall der Optane (die ja keinen Cache hat und damit eine Sicherung über eine Spannungspufferung braucht) geht es um Firmwarequalität. Man kann ja hoffen dass die 900P ähnliche Qualität hat wie die 4800X (war ja die Intel Linie bis letzte Woche).

Die erste wirklich gute Slog, eine Intel X25 hatte ja auch kein PLP und war dennoch ein riesiger Fortschritt. Ich danke daher dass ich bei vielen Konfigurationen dennoch auf die 900P setze - bis Intel erneut eine günstige Optane mit PLP bringt.

Ergänzung
Die Optane erlaubt sync-write nahe an den Schreib-Werten die bisher für sync=disabled üblich waren. Ich überlege daher sync mit einer Optane auch bei einem normalen SMB Filer zu aktivieren. Das war bisher jenseits jeder Diskussion und führt auch da zu einer Verbesserung der Datensicherheit. Ist zwar nicht so gravierend wie bei Datenbanken oder VMs mit alten Dateisystemen aber dennoch kann es den Unterschied machen ob eine kleinere Datei beim Sichern mit Crash auf Platte ist oder verloren im Cache.
 
Zuletzt bearbeitet:
Nachdem mein primäres napp-it mit ZFS unter ESXi nun fast fertig aufgebaut ist, habe ich mich um mein Backupsystem N54L gekümmert, ohne Backup kann ich die Migration nicht abschließen.

Kurzbeschreibung:
ESXi 6.5 auf N54L mit 4x 3TB Platten per DMP an napp-it durchgereicht. Dort unter napp-it einen Pool mit je 2x mirrored Disks angelegt.

Problem:
Der Pool erschien mir sehr klein, habe mir die Platten noch mal genauer angeschaut. Die behaupten jeweils nur noch ~750GB zu haben (statt 3TB). Platten ausgebaut, unter Linux zeigt fdisk auch nur 750GB an.

Was kann ich tun, damit die Platten wieder mit voller Größe erkannt werden?
 
Moin, ich habe ja aktuell im ML310 4SSD + 4HDD am LSI-Controller an die Storage VM durchgereicht. Ich würde gerne um lediglich +1HDD erweitern, aber der LSI ist ja voll belegt. Auch ist eigentlich kein Platz mehr für eine weitere HBA-Karte.
Wäre es bedenklich die 5. HDD durch RDM durchzureichen (vom internen Controller) ? Gibt es da evtl. Probleme weil es direkt und RDM gemixt ist?
Danke für Euer Feedback :-)
 
Sollte gehen. ZFS ist das zunächst egal. Es nutzt alles was nach Blockdevice aussieht.

Physical RDM hat lediglich dem Nachteil dass
- die Platte über den ESXi Controller angesprochen wird. Damit het ZFS eventuell keine volle Kontrolle bei sync write
- die Platte eventuell dadurch etwas langsamer wird
- es komplizierter zum Einrichten ist.

@zapopost
eventuell die Partitionen z.B. mit parted/gparted löschen/ neu anlegen bzw die Platte mit einem Testtool des Herstellers testen.
 
@gea: danke, dann werde ich das bei Gelegenheit mal einrichten.. Sync write ist eh disabled und einrichten finde ich nicht ganz so schlimm. Wenn das sonst funktional passt, soll es mit recht sein.
 
Auf meinem Server läuft noch OmniOS r151022.

Kann ich auf direktem Weg, so wie hier plus Publisher-Wechsel auf r151024 beschrieben, auf OmniOSce r151024 wechseln oder muss ich erst auf OmniOSce r151022 gehen, dann auf r151024?
 
Ich habe da mal eine Frage: Wenn ich einen Pool, der derzeit aus einem Raid Z2 besteht um ein weiteres Raid Z2 erweitere, welches aus 2TB Platten bestehen würde, wie kann man später dieses Z2 durch ein größeres ersetzen? Einzeln die Platten tauschen und scruben ist mir klar. Aber kann man gezielt in einem Pool die Daten von nur einem VDEV auf ein neues kopieren oder geht sowas nicht?
 
Auf meinem Server läuft noch OmniOS r151022.

Kann ich auf direktem Weg, so wie hier plus Publisher-Wechsel auf r151024 beschrieben, auf OmniOSce r151024 wechseln oder muss ich erst auf OmniOSce r151022 gehen, dann auf r151024?

Das sollte direkt gehen
- Zertifikat updaten
- omnios repo abmelden
- neues 124 ce repo anmelden
- updaten per pkg update
- reboot

Dank Bootenvironment eh kein Problem

vgl auch seite 6
http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

- - - Updated - - -

Ich habe da mal eine Frage: Wenn ich einen Pool, der derzeit aus einem Raid Z2 besteht um ein weiteres Raid Z2 erweitere, welches aus 2TB Platten bestehen würde, wie kann man später dieses Z2 durch ein größeres ersetzen? Einzeln die Platten tauschen und scruben ist mir klar. Aber kann man gezielt in einem Pool die Daten von nur einem VDEV auf ein neues kopieren oder geht sowas nicht?

Ein ZFS-Pool ist quasi ein Raid-0 über den einzelnen Raid/vdev.
Die Daten werden automatisch und möglichst gleichmäßig über die vdevs verteilt, wie es auch bei einem einfachen Raid-0 passieren würde. Kopieren zwischen vdev geht nicht.

Wenn man ein neues vdev hinzufügt und alte Daten aus Performancegründen gleichmäßiger verteilen möchte, so geht das über erneutes Schreiben, z.B. Umbenennen eines Dateisystems, per zfs send auf den alten Namen replizieren und das umbenannte Dateisystem nach Erfolg löschen.
 
Hmm, doof^^
Also bleibt mir nur die HDDs dann nacheinander im VDEV austauschen oder als zweiten Pool laufen lassen.
Danke für die Info!
 
Neue Frage:
Bisher habe ich FreeNAS genutzt und überlege nun, OmniOS mit napp-it zu nutzen. Kann ich meinen Pool einfach importieren oder klappt das aufgrund unterschiedlicher ZFS Versionen nicht? Momentan nutze ich FreeNAS 11 U4 und der Pool ist auf der entsprechenden Version. Hab leider nix gesehen, wo mal die konkrete Version stehen würde...
Gea, du empfiehlst immer eine 64GB Disk. Ich will mir ein X11SSM-F kaufen und dafür einen 32GB SuperDOM (64GB gibt es nirgends zu kaufen, kann das sein?). Klappt das trotzdem? Unter FreeNAS habe ich bisher einen 8GB bzw. 16GB USB Stick benutzt.
 
OmniOS ist ein vollwertiges Unix und nicht auf minimalen NAS Betrieb abgespeckt.
Es belegt ca 16 GB. Für jedes Update wird aber ein Bootenvironment angelegt. Das wächst also mit Updates. Die Möglichkeit auf den Stand vor einem Update zurückzugehen möchte man nicht missen. Damit is man schnell bei 20 GB Platzbedarf.

Hinzu kommt ein Swapfile auf der Systemplatte. Oracle empfiehlt 1/4 RAM, um ein Dump-file nach einem Crash zu sichern nochmal das gleiche. Damit ist man je nach RAM bei 30-60 GB Platzbedarf wobei Dump nur nötig ist um einem Entwickler beim Debuggen zu helfen. Dann ist eine 32GB Bootplatte bis ca 48GB RAM ausreichend.

Ich würde aber eher zu einer SSD (oder M.2) greifen da DOMs relativ teuer sind und nicht so gut wie aktuelle SSD. Meine liebsten Bootplatten sind die Intel S3510 - sehr zuverlässig und mit Powerloss-Protection. Gibts mit 80GB, aber auch eine kleinere Samsung oder Sandisk ist ok. Montieren kann man eine SSD auch intern in einem 2,5"-Halter der wie eine pci-Karte am Slotblech befestigt ist.

Den Pool sollte man direkt importieren können. Ich hatte früher von Problemen gehört, wenn FreeNAS nicht die ganze Platte genutzt hat. Das scheint aber nicht mehr der Fall zu sein. SMB Rechte von SAMBA muss man halt durch NFS4/ Windows Rechte ersetzen.
 
Ich will wegen der Rechteverwaltung da weg. Ich kriegs einfach nicht gebacken und die Hilfe bringt mich auch nicht weiter^^ Deswegen wollte ich Napp-It (evtl. mit der ACL Extension) mal ausprobieren, ob ich damit besser klar komme.

Hmm ok. Auf eBay hab ich den DOM in 64GB gefunden. M2 dürfte das Board nicht haben, aber SATA Ports sind ja vorhanden, da könnte ich dann auch eine SSD anschließen. Muss ich mich also nochmal umorientieren. Gut, dass ich noch nicht alles bestellt habe :d
 
Ich will wegen der Rechteverwaltung da weg. Ich kriegs einfach nicht gebacken und die Hilfe bringt mich auch nicht weiter^^

Bis auf deny rules verhält sich der Solaris Kernel-SMB Server wie Windows.
Am einfachsten aus Windows per SMB und root verbinden und Rechte setzen.

Was eventuell etwas ungewohnt ist, wenn man nur SAMBA und Linux/Unix kennt sind die Vererbungsoptionen (nur dieser Ordner oder auch Unterordner/Dateien) und Windows SMB Gruppen (Gruppen die Gruppen enthalten können).
 
Hallo,

ich habe mal eine Frage bezüglich der Nettospeicherkapazität oder eben "total usable space". Ich habe 8xWD80EFZX (8TB) HDDs. Diese sollen in Raidz2 betrieben werden unter FreeNAS 11.0-U4. Ich habe die Konfiguration unter der GUI durchgeführt und erhalte am Ende eine Nettokapazität von 39,9TB. Rein rechnerisch müssten es 43.7TB sein. Wo ist der restliche Speicher hin? Bleibt der einem verwehrt, weil der Speicher von FreeNAS zurückgehalten wird? Welche Auswirkungen hat es eigentlich wenn ich den Pool zu 95% und mehr fülle? Klar die Performance würde darunter leiden aber 4TB habe ich nicht zu verschenken es sei denn es geht auf die Kosten der Datensicherheit.
Außerdem ist mir aufgefallen, dass die Sektoren der Platten logisch 512Byte groß sind aber eigentlich 4kB haben. Sollte ich den ashift auf den Wert 9 belassen?
 
Zuletzt bearbeitet:
Habe ich hier schon mal vorgerechnet, ist der Verschitt den du durch die ungünstige Konfiguration (6 Datenplatten + 2 Parity) verlierst. Entweder du lebst damit oder du gehst auf 2^n + Parity, z.B. 8+2, 4+2, oder 16+3.

Ich habe beim füllgrad die Erfahrung gemacht, das bei 85% ein Sweetspot erreicht ist an Ausnutzung der Kapazität. Wenn 85% überstiegen werden, werden Datenbanken so langsam, das es zu Timeouts kommen kann.
 
Zuletzt bearbeitet:
Sowas hatte ich mir fast gedacht. Kann ich diesen Verschnitt irgendwie errechnen?
Mit welcher Konfiguration würde ich denn mehr Space mit gleicher Datensicherheit bekommen? Ist dieser Verschnitt eine Eigenart von ZFS oder ist es bei allen Dateisystemen so?

PS: Ich nutze den Speicher als NAS also sind keine zeitkritischen Anwendungen vorhanden. Btw. kommt es auf die Kapazitätsgrenze des Dataset oder es Volume an?
 
Zuletzt bearbeitet:
Und das ganze ist hinfällig, wenn du LZ4 Kompression nutzt
How I Learned to Stop Worrying and Love RAIDZ | Delphix

Nicht nur dann. RAIDZ ist halt kein normales RAID, diese 2^n Regel ist genauso falsch wie 1GB Ram pro 1TB Plattenplatz. Das Verhältnis von Nutzdaten zu Parity und Padding muss man für jede Kombination von geschriebener Blockgröße und Anzahl Disks separat berechnen. Wie effizent das ganze also ist, hängt damit auch wesentlich davon ab wofür man den Pool benutzt. Wenn mehr Platz benötigt wird -> mehr Disks verwenden (wobei die Sicherheit bei gleichbleibender Parity natürlich mit jeder weiteren Disk sinkt).
 
Ich möchte den Pool hauptsächlich für Musik und Filme verwenden, genauso werden aber Dokumente und Fotos gespeichert, welche aber einen kleinen Bedarf an Speicher brauchen. Was ist der Vorschlag in diesem Fall? ;-)
 
Das klingt super. Ich bin nur verwirrt, was am Ende für mich gilt. Die physische Sektorgröße (4k) der HDDs oder die logische (512Byte)?

Ist etwas mehr Offtopic, da es keine ZFS sondern eine FreeNAS bezogene Frage ist: Wenn ich spezielle Anforderungen habe bei der Errichtung meines Pools und diesen auf der CLI erstellen möchte. Werden die Parameter dann vorab unter den "Tunables" angelegt?
 
Ashift solltest du bei deinen Platten, die 4k physische und 512B logische Sektoren haben auf jeden Fall auf 12 stellen, wenn das nicht automatisch passiert. In dem Spreadsheet gelten dann die Einträge mit 4096. Wenn deine ZFS Version eine Recordsize von 1M unterstützt würde ich die auch einstellen, da die Masse an Daten ja große Files sind. Du kannst deine Daten auch in verscheidene Filesysteme aufteilen und diese mit unterschiedlichen Recordsizes konfigurieren.

Ich habe noch nicht mit FreeNAS gearbeitet, aber ich vermute, dass mit mit den Tunables globale Parameter gemeint sind, die sich insgesamt auf das Filesystem auswirken. Ashift und Recordsize gibt man direkt als Option beim Erstellen in der CLI mit.
 
Zuletzt bearbeitet:
Ich kann die Recordsize nur für ein Dataset konfigurieren und nicht vorab beim erstellen des Pools. Ist das korrekt?

Also es geht dann mit
zpool create <pool> raidz2 /dev/da{0,1,2,3,4,5,6,7}
zfs set recordsize=1M <pool>

ZFS Record Size | Programster's Blog
 
Zuletzt bearbeitet:
zpool create <pool> raidz2 /dev/da{0,1,2,3,4,5,6,7}

zpool create -O recordsize=1M <pool> raidz2 /dev/da{0,1,2,3,4,5,6,7}

Durch die Vererbung bekommen alle neuen Datasets dann die gleiche recordsize sofern mans dann nicht nochmal händisch ändert.
 
Zuletzt bearbeitet:
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