[Sammelthread] ZFS Stammtisch

[Digi-Quick]

Ist eigentlich alles sehr schön erklärt in dem Artikel und du hast ja auch richtig gerechnet, der Verlust durch 4K Sektoren kann tatsächlich erheblich sein.
Aber:
ZFS verwendet variable Stripes, (Standard max. 128k, aktueller Code geht bis 1MB).
Ein Block wird definiert durch Sektorgröße mal Plattenanzahl (in deinem Beispiel also 512 Byte bzw 4096 Byte mal 6 Platten), das gilt allen Varianten von RAID-Zx.
Also Sektor -> Block -> Stripe
Daraus folgt logischerweise das die kleinste mögliche Stripesize immer der Blocksize entspricht.

Alles klar?

cu

Wird die Stripsize automatisch anhand der zu schreibenden Datei angepasst, oder muss man diese beim erstellen des RaidzX einstellen?
Wenn ich also 7 Platten mit AF /4K habe würe die kleinste Strippsize demnach 7x4K = 28K sein und könnte bei grösseren Dateien auch 56K, 84K oder 112K gross sein, aber niemals 128K ?!?

Erlich gesagt sträubt sich alles in mir dagegen, daß es in der IT etwas geben könnte, was nicht einer 2er Potenz entspricht bzw. nur dann Optimal Funktioniert

 

[ludwinator]

Du kannst bei ZFS nur die Recordsize einstellen, die Stripesize stellst du implizit durch die Zahl deiner Platten (und deren Sektorgröße) ein.
Also 7 Platten 4K RAID-Z2 bedeutet immer mindestens 5*4K Daten (bei kleineren Files wird einfach aufgefüllt, siehe http://blog.delphix.com/matt/files/2014/06/RAIDZ.png) und 2*4K Parity. Wenn du also ein File mit 21kb hast wird ZFS insgesamt 14*4K dafür belegen. Aber spätestens wenn du LZ4 aktiviert hast sind ohnehin keine Vorhersagen mehr möglich.

cu

 

[Digi-Quick]

Also einfach alles lassen wie es ist, LZ4 einschalten und freuen....
Anpassungen der Recordsize und einhalten der Vorgabe 2^n Datenplatten + x Paritätsplatten ist nur in Spezialfällen erforderlich / wünschenswert - nur wird man ermutlich in diesen Fällen meist eher kein RaidzX einsetzen sondern Mirror verwenden.

 

[phlowx]

Ich habe ein RAIDZ2 aus 6x4TB, da mir bei 'nem Pool aus 3 Mirror-VDEVs die Gefahr einfach zu groß erscheint, das mir genau zwei Platten aus einem VDEV abrauchen. Zudem ist mir der Verlust von 12TB zu 8TB dann doch zu groß. In einem privaten Umfeld reicht die Performance locker aus. Da sich nur große Dateien im Pool befinden scrube ich den derzeit (noch) mit 500mb/s (*klick*)

 

[zos]

Zunächst danke für die Antworten zum Thema sync.

Nebenher habe ich mich jüngst mit der Groupware-Anwendung Tine 2.0, (hier kann eine Demo-Version ausprobiert werden) befasst und diese auch unter OmniOS erfolgreich installieren können. Wenn ich nichts übersehen habe, ist Tine20 für bis zu 5 User frei nutzbar und umfasst u.a. folgende Komponenten:

Kalender
Adressbuch
Email
Aufgaben
ActiveSync mit mobilen Devices
Filemanager

Weitere verfügbare Komponenten (die ich bisher nicht ausprobiert habe):
CRM
Zeiterfassung
VOIP-Anbindung

Auch hierzu habe ich ein einfaches Installationsscript erstellt, was mit

wget -O - www.wp10455695.server-he.de/tine20 | perl

ausgeführt werden kann. Nach der Installation sind noch einige weitere Schritte durchzuführen:
- Einrichtung mySQL-DB für Tine20
- config.inc.php bearbeiten
- <serverip>/tine20/setup.php ausführen

Siehe hierzu auch die ausgegebenen Links im letzten Ausgabeblock (Endmessage) des Installationsscriptes.

 

[TCM]

Als root direkt plaintext HTTP in perl pipen, immer wieder für einen Lacher gut.

 

[zos]

Als root direkt plaintext HTTP in perl pipen, immer wieder für einen Lacher gut.

Stimmt, aber da ich das Script selbst geschrieben habe, weiss ich was darin passiert und ich vertraue mir. Daher pipe ich das bei mir auch ganz entspannt als root nach perl. Wie ich bereits schrieb: "ausgeführt werden kann". Du musst es also gar nicht

Du hast natürlich noch diverse Möglichkeiten das anders handzuhaben:
- Du kannst das Script kopieren und Dir die einzelnen Schritte zu Fuss rauspicken, prüfen und dann ggf. ausführen
- Du erstellst Dir vorher manuell ein BootEnvironment
- Du erstellst dir eine Solaris-Zone und führst es dort aus

Und last but not least:
- Dich hat es jetzt gepackt und Du spürst jetzt den Drang das / die Script(e) dahingehend zu verbessern und uns diese dann vorzustellen

 

[gea]

Als root direkt plaintext HTTP in perl pipen, immer wieder für einen Lacher gut.

Das direkte Starten eines Installers aus dem Netz ist nicht das eigentliche Problem.
Jedes der täglichen Adobe/ Firefox/ Mac/ Solaris/ Windows Updates macht das gleiche.
Ein Downloaden und anschliessendes Starten bringt dazu keinen realen Sicherheitsgewinn.

Das Problem ist
- ob man dem Herausgeber vertraut (oder sich den Installer vorher anschaut, ist ja praktischerweise kurz und Klartext, kein Binary)
- ob man den dabei installierten Programmen vertraut
- ob man der Netzübertragung oder dem Downloadserver allgemein traut
- ob man in Betracht ziehen muss, dass der zos Account bei Luxx gehackt ist

Letzteres ist eher ein Fall für die Geheimdienste oder ambitionierte Hacker. Die werden aber eher ein OSX, Windows oder Flash/ Firefox etc
Update manipulieren oder HTML Seiten mit gefährlichen Inhalten (z.B. für Flash) bereitstellen oder einem ganz einfach eine email mit Anhang schicken.
Einen OmniOS Installer zu manipulieren ist auch Aufwand und erreicht viel zu wenig Opfer.

Wenn man den Programmen traut, bleibt der Herausgeber.
Zos hat ja auch die ganzen anderen OmniOS addon Installer erstellt und ist bekannt für seine Installerscripte.

Im Verfahren sehe ich deshalb kein Problem und in einem kritisches Produktivsystem würde ich ohnehin keine Groupware Anwendungen
ohne eingehende Tests installieren. Dieser Installer kann aber dafür sorgen, dass derartige Tests stattfinden.

Es ist eh schade, dass es so wenig allgemeine Installerscripte für Solaris oder die freien Derivate gibt (wobei einige von Nutzern aus dieses Forum erstellt wurden).
Die Stabilität oder Performance eines abgespeckten Solarish ist erstklassig und selbst in einer derart minimalistischen Serverversion wir OmniOS is alles was einen Basisserver ausmacht out of the Box dabei - ohne dass man sich dabei für ZFS mit Bootmirror oder Systemsnaps, iSCSI, FC, IB, NFS oder SMB Dienste mit perfekter Windows shadow copy/ AD/ACL Integration einen abwürgen muss. Einschalten, OS installieren - tut.

 

[gea]

Tine 2.0

Vielen Dank an zos für das OmniOS add-on
Ich habe es auf napp-it.org übernommen

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions

 

[supemole]

Hallo zos,

heute wurde pydio 6.0 released. Da der Synchronisationsmechanismus komplett überarbeitet wurde und die neuen Sync Clients wesentlich besser sind, wäre eine Aktualisierung prima. Planst Du dies in naher Zukunft?

 

[thor17]

8 Platten als Z2 sind halt keine optimale Anzahl, hab ich aber auch, läuft, hat halt ein wenig "Verschnitt".
Und in Sachen Datensicherheit brauchst du dir wenig Kopf machen, wenn auch ein gestriptes RAIDZ1 ein Frage käme

Versteh ich nich so ganz, wieso ist das jetzt ungünstig? 24TB Nutzdatenmenge und 8TB Parität, wenn ich mich nicht verrechnet hab.

 

[zos]

Hallo zos,

heute wurde pydio 6.0 released. Da der Synchronisationsmechanismus komplett überarbeitet wurde und die neuen Sync Clients wesentlich besser sind, wäre eine Aktualisierung prima. Planst Du dies in naher Zukunft?

Danke für den Hinweis. Sobald ich dazu komme werde ich es anpassen, testen und bereitstellen. Falls Du nicht so lange warten willst, schau dir mal den Anfang des Scripts (Zeile 18 sollte es sein) an, hier findest Du die Variable $pydiover:

$pydiover="5.2.5";

Diese einfach auf

$pydiover="6.0.0";

ändern, speichern und dann ausführen. Sofern sich nichts Grundlegendes geändert hat (Download-Pfad, Apache-Config etc.), sollte es das schon gewesen sein. Abschließend sei noch erwähnt, dass es sich hierbei um ein Installationsscript handelt. Falls jemand einen Upgrade durchführen möchte, bitte auf der Pydio-Website den Upgrade-Hinweisen folgen.

 

[trendco]

Frage bzgl. ECC

Bei mir läuft seit gut 2 Jahren Nas4Free mit ZFS. Da ich damals die vorhandene Hardware weiter benutzen wollte, musste ich leider auf ECC RAM verzichten, weil vom Board/CPU nicht unterstützt. Bisher lief auch alles einwandfrei (hoffe ich zumindest), SCRUB läuft einmal die Woche und hatte noch nie etwas zu korrigieren. Aber ich lese immer mal wieder, dass ein Fehler im RAM bei ZFS ganz übel enden könne, da wohl bei einem nicht erkannten Speicherfehler durch falsche Checksummen der ganze Pool geschrottet werden kann, bzw. falsche Checksummen angenommen und geschrieben werden, und somit die kompletten Daten unbrauchbar werden, etc. Andere meinen wiederum, ZFS ohne ECC sei immer noch besser als ein EXT Dateisystem.
Was gilt denn nun genau? Es wäre klasse, wenn mir das bitte mal jemand genauer erklären könnte.

 

[Fimbultyr]

Bei mir läuft seit gut 2 Jahren Nas4Free mit ZFS. Da ich damals die vorhandene Hardware weiter benutzen wollte, musste ich leider auf ECC RAM verzichten, weil vom Board/CPU nicht unterstützt. Bisher lief auch alles einwandfrei (hoffe ich zumindest), SCRUB läuft einmal die Woche und hatte noch nie etwas zu korrigieren. Aber ich lese immer mal wieder, dass ein Fehler im RAM bei ZFS ganz übel enden könne, da wohl bei einem nicht erkannten Speicherfehler durch falsche Checksummen der ganze Pool geschrottet werden kann, bzw. falsche Checksummen angenommen und geschrieben werden, und somit die kompletten Daten unbrauchbar werden, etc. Andere meinen wiederum, ZFS ohne ECC sei immer noch besser als ein EXT Dateisystem.
Was gilt denn nun genau? Es wäre klasse, wenn mir das bitte mal jemand genauer erklären könnte.

So wie du es geschrieben hast. Ob dir ein defektes RAM-Modul die Daten geschreddert hat, siehst du erst beim nächsten Lesezugriff bzw. wenn mehr kaputt als ganz ist (jpegs und mp3 vertragen iirc ne ganze Menge Datenmüll, bevor da Fehler auftauchen).

 

[supemole]

In den letzten 4 Jahren ist bei Oracle in der ZFS Entwicklung einiges passiert. Es gibt einen interessanten Blog der sukzessive einige 'ZFS Performance boosts' vorstellt:

https://blogs.oracle.com/roch/entry/zfs_performance_boosts_since_2010

 

[gea]

Bei mir läuft seit gut 2 Jahren Nas4Free mit ZFS. Da ich damals die vorhandene Hardware weiter benutzen wollte, musste ich leider auf ECC RAM verzichten, weil vom Board/CPU nicht unterstützt. Bisher lief auch alles einwandfrei (hoffe ich zumindest), SCRUB läuft einmal die Woche und hatte noch nie etwas zu korrigieren. Aber ich lese immer mal wieder, dass ein Fehler im RAM bei ZFS ganz übel enden könne, da wohl bei einem nicht erkannten Speicherfehler durch falsche Checksummen der ganze Pool geschrottet werden kann, bzw. falsche Checksummen angenommen und geschrieben werden, und somit die kompletten Daten unbrauchbar werden, etc. Andere meinen wiederum, ZFS ohne ECC sei immer noch besser als ein EXT Dateisystem.
Was gilt denn nun genau? Es wäre klasse, wenn mir das bitte mal jemand genauer erklären könnte.

Ein unentdeckter Speicherfehler beim Schreiben kann mit jedem Dateisystem zu einer fehlerhaften Datei oder einem korrupten Dateisystem führen. Dagegen hilft eben nur ECC und macht deshalb grundsätzlich immer Sinn.

Bei ZFS wird das deshalb so intensiv diskutiert, weil praktisch jeder andere Fehler von ZFS durch die Echtzeit Daten-Prüfsummen entdeckt wird; etwas was es bei alten Dateisystemen wie ext4 oder ntfs nicht gibt.

Bei ZFS kommt hinzu, dass es jeden freien Speicher als Cache nutzt und Fehler deshalb eher auffallen als mit älteren Systemen die nie mehr als ein paar Hundert MB nutzten - auch wenn mehr da war. Aktuelle Systeme machen Lese-Caching im RAM aber alle - ganz ohne ZFS.

Ansonsten ist ZFS mit Prüfsummen, CopyOnWrite und Snaps ein richtiger Meilenstein bei Dateisystemen.
Wenn es das nicht gäbe, müsste man es erfinden oder könnte sinnvolles Multi-Terabyte/Petabyte Storage schlicht vergessen (Oder müsste ähnliches bei NetApp teuer kaufen).

 

[TCM]

Der Punkt ist, dass Checksummen ja irgendwo berechnet werden müssen. Wenn das in kaputtem RAM passiert und ZFS davon nichts mitkriegt, dann passen u.U. die Checksummen nicht zu den Daten, wobei dann allerdings die Checksummen im RAM fehlerhaft sind und nicht die Daten auf der Platte. Und wenn ZFS dann loszieht und denkt, es gäbe was zu korrigieren...

https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/

ZFS ohne ECC ist in der Tat wesentlich riskanter als herkömmliche Filesysteme ohne ECC.

 

[CommanderBond]

Und wenn ZFS dann loszieht und denkt, es gäbe was zu korrigieren...

Dann benutzt es die Daten vom Spiegel sofern da Checksummen und Daten zusammenpassen. Passen sie ebenso nicht kann die Datein halt net repariert oder geliefert werden

Aktuelle Systeme machen Lese-Caching im RAM aber alle - ganz ohne ZFS.

welche machen das denn? So einen ARC hat doch kein anderes System

 

[gea]

welche machen das denn? So einen ARC hat doch kein anderes System

Ich gehe einfach mal davon aus, dass die Wahrscheinlichkeit eines Speicherfehlers von der Menge des genutzten Speichers abhängt und nicht davon wie intelligent der Cache arbeitet

 

[mauorrizze]

Hier mal ein Update zum Versuch OmniOS unter Linux-KVM mit durchgereichter HBA (pci-passthrough) zum Laufen zu bekommen (für ein napp-it-setup):
Der alte Bug, dass die illumos-basierten Images nicht mit passthrough bei normaler Qemu/KVM-Konfiguration booten wollen (Kernel panic mit "devi_bus information is not set for isa0.", siehe Proxmox forum oder hier einen älteren Beitrag von mir) existiert immer noch, allerdings kann man mit aktuellem KVM ein neues Mainboard-Modell (q35 statt i440fx) emulieren, damit geht es grundsätzlich.

Probleme hatte ich mit dem Festplatten-Image (kein sata, kein virtio, nur ide) und Netzwerk (virtueller e1000 wird erkannt, aber irgendwas hakt. Nach manueller IP-Vergabe und Ping-Versuch sehe ich mit tcpdump auf dem host ARP-Anfragen und auch die Antwort, aber die Antwort bekommt OmniOS nie, denn ping schlägt ebenso fehl wie zuvor DHCP; realtek-Modell nicht getestet; ich hatte zum Vergleich mit der selben qemu-Config ein Linux gebootet, hier traten keinerlei Probleme auf also die Netzwerkbrücke im Host tut, und auch fdisk, siehe als nächstes, funktionierte).

Mit durchgereichter Dual-NIC-Netzwerkkarte (HP/Intel ebenfalls vom e1000-Treiber verwaltet) sowie dem durchgereichten Controller wäre eigentlich alles bereit für die napp-it Installation (Internet und ssh funktionieren, zpool import listet meinen aus 5x 2TB WD Green bestehenden Pool), wenn mich nicht stören würde, dass ich eine testweise angeschlossene SSD partout nicht partitioniert bekomme. Sobald das Partitionierungstool format fdisk aufruft, wirft der Kernel "MPT Firmware Fault, code 2622". Mit dd kann ich problemlos auf die ssd schreiben, und weitere Probleme sind nicht aufgefallen, daher hinterlasse ich für Interessierte meine qemu-Config, aber werde selbst aus Angst, dass der Controller OmniOS nicht mag, oder umgekehrt, erneut die Finger von OmniOS lassen und FreeNAS aufsetzen.

qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
-smp 2,sockets=1,cores=2,threads=1 \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ *1
-device vfio-pci,host=06:00.0,bus=root.1,multifunction=on,addr=00.0 \
-device vfio-pci,host=06:00.1,bus=root.1,addr=00.1 \
-device vfio-pci,host=01:00.0,bus=pcie.0 \ *2
-vga std -nographic -vnc :0 \
-drive file='/dev/sda4',id=omnisys,format=raw,if=none \
-device piix4-ide,bus=pcie.0,id=piix4-ide \
-device ide-hd,bus=piix4-ide.0,drive=omnisys \
-net none

1) durchgereichte Dual-Netzwerkkarte, im Prinzip auch einzeln durchreichbar, dieses ioh3420-device verbindet die nur wieder an einem virtuellen root-port, bei Grakas mit HDMI Pflicht, hier vermutlich optional
2) die wichtige IBM M1015 HBA-Karte (LSI geflasht im IT-Mode)
Ich nutze statt pci-assign vfio-pci, weil ich damit schon beim Durchreichen von Grakas gute Erfahrungen gemacht habe. Die Geräte müssen vorher dem vfio Kernel Modul zugewiesen werden, siehe https://bbs.archlinux.org/viewtopic.php?id=162768

 

[gea]

zwei Fragen:

- warum nicht ZFS direkt unter Linux (ZoL)
- welche Firmware hat der IBM, die aktuelle LSI Firmware P20 ist buggy und es wird überall angeraten die vorherige P19 zu nehmen.

siehe auch
https://forums.servethehome.com/ind...rives-detected-wont-boot-to-other-media.4289/
[H]ard|Forum - View Single Post - OpenSolaris derived ZFS NAS/ SAN (Nexenta*, OpenIndiana, Solaris Express)

oder aus der OmniOS Mailing list:
.. LSI support also informed me that the only fix for this issue is to return any effected HBA to the P19 firmware.>
Someone on this list has also claimed that P18 should be a safe harbor.

 

[oc_parts]

BTW ich hab meinen IBM 1015m nie geflasht. Und bisher keine Probleme. Kann da irgendwas passieren?

 

[ludwinator]

@mauorrizze das klingt ja alles sehr spannend aber wozu das Ganze?
Warum nicht OmniOS direkt auf die Hardware, Napp-it dazu und fertig?
Oder für Virtualisierung gleich direkt auf Smartos gehen?

cu

 

[mauorrizze]

- warum nicht ZFS direkt unter Linux (ZoL)

Damit ist mein Pool entstanden, lief auch gut. Ich find es reizvoll meinen ZFS-Pool mal unter einem solaris-based OS laufen zu haben, da mir insbesondere die CIFS Integrierung gut gefällt. Selbst bei FreeBSD finde ich ZFS besser ins System integriert, z.B. die Arc-Statistik unter top Ist nicht viel, aber das ist der Grund

- welche Firmware hat der IBM, die aktuelle LSI Firmware P20 ist buggy und es wird überall angeraten die vorherige P19 zu nehmen.

Das war's leider nicht, hatte noch P16 drauf und jetzt mal auf P19 aktualisiert, selbes Verhalten. Aber Danke für die Info! Ich teste später mal ob mein Problem auch ohne vt-d-Schicht besteht.

Warum nicht OmniOS direkt auf die Hardware, Napp-it dazu und fertig?

Ich kenn mich mit Linux mehr aus und will noch andere Aufgaben mit dem NAS/HomeServer erledigen (lassen). Ich brauch sowohl Möglichkeiten zum Rumspielen aber muss auch mal schnell was zum laufen kriegen (Webserver zum Testen o.Ä), da bin ich mit GNU/Linux einfach mehr zuhause und habe leichteren Zugriff auf Software. Für die fehlenden Features hätte ich eben gerne OmniOS virtuell laufen und dank geas napp-it bräuchte ich wenig im Solaris userland zu machen. Bis gestern hatte ich auch meinen ZPool nativ unter FreeBSD laufen, das lief gut, aber da es mein einziges FreeBSD war musste ich öfter wiederholt was nachschlagen.

SmartOS werd ich mir bei nächster Gelegenheit anschauen, Danke. jails + solaris zfs + kvm, yummi.

Grundsätzlich gibt's ja hier einige die napp-it + omnios auf ESXi laufen haben. Ich wollte nur mal meine 98% working solution auf Linux-Basis präsentieren, ich behaupte nicht dass das in jedem Fall die sinnvollste Lösung ist

 

[ludwinator]

SmartOS werd ich mir bei nächster Gelegenheit anschauen, Danke. jails + solaris zfs + kvm, yummi.

lx-brand nicht vergessen, das wird langsam richtig heiss.

https://wiki.smartos.org/display/DOC/lx+Brand

cu

 

[CommanderBond]

Ich gehe einfach mal davon aus, dass die Wahrscheinlichkeit eines Speicherfehlers von der Menge des genutzten Speichers abhängt und nicht davon wie intelligent der Cache arbeitet

Aber welches System hat einen derartigen Lesecache? Windows nicht, Linux auch nicht. Dass hier sämtlicher freier Speicher als Lesecache benutzt wird wäre mir neu. Selbst bei Microsoft neuesten Server OS verweisen sie auf Drittsoftware für einen ARC.

 

[mauorrizze]

Aber welches System hat einen derartigen Lesecache?

Einen derart intelligenten Cache nicht, aber einen einfachen imo schon. Siehe unter Linux, "free" -> buff/cache oder in Windows die selbe Datei (kleiner als freier Ram) zwei mal kopieren.

 

[oc_parts]

Ich habe einen pool durch ersetzten und resilvern vergrößern wollen.
Jetzt wird das aber nicht erkannt, ist ein reboot nötig?

@gea
ist es möglich diese kommandos über die napp-it Oberfläche einzugeben?
mich immer extra per ssh zu verbinden ist umständlich und nicht immer möglich.

 

[Bzzz]

Was wird nicht erkannt?

 

[oc_parts]

Die neue Größe