[Sammelthread] ZFS Stammtisch

ZFS arbeitet genau so.

Fällt eine Platte aus, geht der Pool in den Status degraded. Ein Hotspare ersetzt umgehend die defekte Platte. Der Pool bleibt aber auf degraded. Die normale Aktion ist jetzt Ersatz der defekten Platte per zfs replace. Der Pool geht dann wieder auf online und die hotspare ist wieder hotspare. (Klar kann man die Hotspare entfernen und voll in den Pool integrieren.)

Ansonsten bedeutet "prüfen" bei ZFS sehr viel mehr als bei traditionellem Raid. Dort wird nur der Raid-Stripe per Xor geprüft. ZFS geht da sehr viel weiter indem es tatsächlich die Datenblöcke End-to-End also inklusive Disk, Backplane, Kabel, Treiber überprüft, eventuelle Fehler feststellt und aus Redundanz on the fly repariert. Bei einem nicht behebbaren Fehler führt das zu einer defekten Datei, ZFS weiß ja zu welcher Datei ein Datenblock gehört. Bei einem traditionellen Raid fehlt diese Information. Manche Fehler werden daher nicht erkannt oder aber der Fehler führt zu einem komplett defekten Raid.

Nur als Beispiel ein Raid-1.
Aus welchem Grund auch immer sind die beiden Mirrors nicht identisch. Passiert öfter als man hofft. ZFS erkennt beim Lesen den Fehler durch Prüfsummen und versucht den anderen Mirror zu lesen. Bei Erfolg wird der defekte Part repariert ansonst die Datei als defekt markiert. Ein herkömmlicher Mirror gibt die korrupten Daten einfach unerkannt an das OS weiter.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Der letzte Beitrag von @gea hat mich an einen Post von mir im März diesen Jahres erinnert. Der nachfolgende Fehler ist bisher nicht nochmal aufgetaucht. Das hat ZFS also sehr gut gemacht! ;)

Hallo Leute,

mein openmediavault3-server (aktuelles debian jessie) hat mich heute morgen darüber informiert, dass es einen Checksum-Error gibt/gab:

Hier die erste Email:

ZFS has detected a checksum error:

eid: 12
class: checksum
host: omv
time: 2017-03-12 08:25:52+0100
vtype: disk
vpath: /dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX42K7-part1
vguid: 0xCF4E2F1BD8C14810
cksum: 1
read: 0
write: 0
pool: mediatank

und hier die zweite Email eine knappe halbe Stunde später:

ZFS has finished a scrub:

eid: 13
class: scrub.finish
host: omv
time: 2017-03-12 09:00:24+0100
pool: mediatank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: ZFS Message ID: ZFS-8000-9P
scan: scrub repaired 4K in 8h36m with 0 errors on Sun Mar 12 09:00:24 2017
config:

NAME STATE READ WRITE CKSUM
mediatank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXXY76J ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX2D2F ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX1TZ9 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX42K7 ONLINE 0 0 1
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX4ZJ8 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXX68ZE ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXXY0DJ ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4EXXXY1AN ONLINE 0 0 0

errors: No known data errors

Der zweiten Mail nach (entspricht der Ausgabe von "zpool status") gibt es also keine bekannten data errors. Beim angestoßenen Scrub gab es eine Reparatur mit 0 Fehlern. Hört sich also gar nicht so schlecht an.

Was würdet ihr nun tun? Weiter beobachten oder doch besser gleich die entsprechende HDD austauschen? Ist sowas schon als kritisch zu beurteilen?

Würdet ihr diesen Fehler mit "zpool clear" löschen oder soll ich ihn besser drin lassen. Es sieht zwar nicht schön aus, wenn dort ein checksum error angezeigt wird, spiegelt aber die Realität wieder, so dass es wahrscheinlich sinnvoll ist, den Fehler nicht zu löschen, oder?

Viele Grüße Hoppel
 
Dier ist klar, dass die Karte nur für Sata-ssd im M.2 Format ist? Nix PCIe/Nvme.
Eine Samsung 960 oder ähnlich passt da nicht.
Für doppelte m.2 Adapter muss das MAinboard PCIE-Bifurcation können oder ein extra Pcie-Switch drauf sein (Amfeltec Squid).
 
Zuletzt bearbeitet:
Deswegen gehe ich auf SATA. SATA ist da deutlich unkomplizierter, nur eben die Frage ob Solaris das auch erkennt etc. sonst bringt mir auch SATA nix.
 
Zuletzt bearbeitet:
Kann sein, dass der Sata Treiber die Karte erkennt.
Was soll das aber bringen?

Ein normaler SAS HBA mit LSI 2008 Chip kostet kaum mehr, ist gleichschnell, viel flexibler und hat 8 Ports und geht garantiert. Dazu geht Hotplug und es gibt professionelle SSDs dazu.
 
Im Chenbro SR30169 ist nur begrenzt Platz.Aber ja, mit ein bisschen kreativität, würde ich wohl auch sonstwo im Gehäuse SSDs unterbringen können.
 
@gea: Vielen Dank, deine Erläuterungen waren wirklich sehr hilfreich und nun verstehe ich es auch. Und es hat mir richtig Laune auf ZFS verschafft! ;)

Da kommt mir dann eine weitere Frage: Wenn man das autoreplace-Feature aktiviert, ersetzt es einem dann das manuelle zfs replace?
 
Auf meinem Server läuft nun FreeNAS 11.
Ich habe nun ein Volume erstellt - soweit so gut.

Ich habe noch Einschübe frei und könnte die alten Platten einschieben und kopieren. Nur wie mach ich das ?
Geht das über die FreeNAS Oberfläche ?
 
Da kommt mir dann eine weitere Frage: Wenn man das autoreplace-Feature aktiviert, ersetzt es einem dann das manuelle zfs replace?

Nein, hat nichts miteinander zu tun.

ZFS merkt sich die Platten aus denen der Pool besteht. Bei älteren Systemen ist das ein Controllerport wie sda oder c0t0d1. Damit ist wirklich ein Kabel am Controller gemeint (erster Controller, Anschluss 1). Wenn man autoreplace aktiviert und eine Platte fällt aus, z.B. c0t0d1 und man zieht die und schiebt eine neue in den Slot, dann fängt ZFS automatisch mit dem Replace an.

Das ist aber Schnee von gestern. Aktuelle Systeme nutzen WWN zur Plattenidentifikation. Da sind IDs wie c0t5000CCA01622AC64d0. Diese Nummer vergibt der Hersteller der Platte. Sie bleibt gleich auch wenn man den Server/ Controller wechselt. Autoreplace geht dann nicht mehr, da das nur bei identischer ID arbeitet. Dafür erhält man eine universelle Identifikation von Festplatten.

Zfs replace ist ganz allgemein eine direkte Anweisung an ZFS um eine Platte im Raid durch eine neue zu ersetzen.
 
Zuletzt bearbeitet:
Da wäre mir die alte Vorgehensweise aber lieber! ;)

Nun gut, es ist wie es ist. Werde ich mich mal mit FreeBSD beschäftigen, um damit zurechtzukommen!
 
Ich habe mir folgenden Server zusammengestellt:

Server 2017 mit ECC Preisvergleich Geizhals Deutschland

Das OS (Proxmox) kommt auf die SSD. Aus den drei WD Red möchte ich einen ZFS Pool erstellen. Da ich meine VMs, die auf der SSD liegen, regelmäßig auf das Raid sichere, würde ich dafür gerne ein ZFS mit aktiviertem dedup bauen. Ich habe mich jetzt etwas schlau gelesen und zu dem Schluss gekommen, dass der RAM für VMs und ZFS mit Dedup eventuell etwas knapp ist. Um das Ganze zu entspannen würde ich L2ARC hinzufügen. Kann ich dafür einen Partition auf der vorhandenen SSD nutzen? Oder würde es mehr Sinn machen, eine dedizierte SSD zu verbauen? Noch ist nichts konfiguriert und ich bin für jeden Tipp dankbar. :)
 
L2ARC braucht auch RAM, da gewinnst du nichts (der muss die Zuordnung der Caches auf dem L2ARC ja auch irgendwo speichern -> RAM).

RAM ist durch nichts zu ersetzen außer durch mehr RAM ;) Besonders im Bezug auf ZFS.
 
Servus,

ich muss gestehen, dass ich mich bis dato 0,0 mit diesem Thread beschäftigt habe, da mir mein Windows Filer bisher immer genügte. Da ich aber nun an ein neues Sizing gehe, möchte ich zumindest mein Wissen ein bisschen erweitern und auch im privaten Umfeld sind Features wie Dedup und Compression ja nicht unbedingt verkehrt.
Hat jemand gute Websites für mich, wo ich mich ein wenig in ZFS einlesen kann? Besonders wie Features wie Dedup/Compression usw. funktionieren und warum ZFS im allgemeinen als so RAM-lastig gilt.

Danke euch & Gruß
Moritz
 
Ich habe da auch noch eine Frage: Welche Nachteile hat ZFS on Linux denn aktuell gegenüber "native" ZFS? Und ich meine damit keine theoretischen Nachteile, sondern echte die man auch "spürt"!
 
ZoL kann z.B. kein TRIM für SSDs - noch nicht.
Wer keine SSD Pools verwendet, merkt davon nix.
 
So eine Featuregegenüberstellung würde mich auch interessieren.Bin gerade am überlegen, was ich aus welchen Gründen nehmen soll.
Solaris - OmniOS - Ubuntu ZoL
 
Ein paar Anmerkungen

Dedup
Es gibt nur ganz wenige Fälle wo ich das einsetzen würde. ZFS dedup ist Echtzeit-Dedup. Damit muss die Dedup Tabelle im RAM gehalten werden. Im Extremfall (je nach Blockgröße) verbraucht das bis zu 5GB RAM je TB Dedup Daten. Wenn der RAM nicht reicht, lagert das auf Platte aus und das kann einen Pool extrem langsam machen. Ausserdem muss man diesen RAM-Bedarf zu dem RAM hinzurechnen, den man als Cache haben möchte. Fazit: Platten sind billig, in nahezu allen Fällen lieber eine größere oder Extra Platte nehmen und dedup aus lassen

L2Arc
L2Arc ergänzt den RAM Lesecache um eine SSD oder NVMe. Ich würde mal 5% der L2Arc Größe als RAMbedarf sehen. Die L2Arc sollte daher nicht größer als 5 - 10X RAM sein. Da L2Arc langsamer ist als RAM ist mehr RAM immer besser - bis auf Read Ahead Caching bei sequentiellen Daten. Das geht nur mit L2Arc.

ZFS und RAM
ZFS hat nur minimal mehr RAM-Bedarf als z.B. ext4 oder ntfs. Oracle gibt 2 GB als Mindestvorraussetzung an -egal wie groß ein Pool ist. Nicht-Solaris Systeme brauchen meist etwas mehr da die ZFS interne RAM-Verwaltung noch auf Solaris ausgelegt ist.

ZFS nutzt den freien RAM aber als Cache, bis 4GB default als Schreibcache und den Rest als Lesecache. Das bringt Performance und freut den Anwender. Hinzu kommt dass CopyOnWrite Dateisysteme auch sequentielle Daten über der Platte verteilen und bei vollen Pools relativ stark fragmentieren. Die Performance ist daher stark abhängig von der iops Leistung des Pools. Bei langsamen Platten und wenig RAM ist ZFS langsam, siehe How slow is ZFS with low RAM or readcache disabled and slow disks? | ServeTheHome and ServeThe.Biz Forums

Native ZFS
Das ist Oracle Solaris v37. In allen meinen Tests war es immer der schnellste Filer besonders bei 10G Netzen und schneller. Ausserdem kann es als einzuger sequentielles Resilvering bei dem eine fehlerhafte Platte besonders schnell ersetzt wird. Ist aber closed source, kostet bei kommerzieller Nutzung und ist inkompatibel zu Open-ZFS v5000 von BSD, Linux, OSX oder dem freien Solaris Fork Illumos (Nexenta, OpenIndiana oder OmniOS).

Solaris:
Beste und einfachste Integration von OS, ZFS und Diensten. Alles aus einer Hand und hier kommt ZFS her. Selbst eine Minimalstdistribution hat alles dabei (Netzwerkvirtualisierung, iSCSI, NFS und SMB und zwar alles Solaris Projekte). Insbesondere der eigene SMB Service von Solaris gilt als besonders schnell und Windows kompatibel was ACL und die Integration von Active Directory, Snaps und Windows-Vorherige Version angeht. Samba gibts natürlich auch. Meist wird hier der eigene SMB Server genutzt.

BSD
ist wie Solaris eine Unix Variante und nutzt ZFS seit langem. Für SMB wird wie bei Linux SAMBA genutzt. Etwas breitere Hardware Unterstützung als Solaris und bietet mehr Extraservices ausserhalb des Storagebereichs (z.B. Mediaserver).

Linux
Breiteste Hardwareunterstützung und die meisten Extra-Services. ZoL als Dateisystem durchaus vergleichbar in den meisten Feautures mit Solaris und BSD. Es fehlt aber eine wirklich leistungsfähige ZFS NAS Distribution. Am nervigsten finde ich das Installieren von ZFS, die vielen Probleme bei jedem Update und das ZFS hier nur eine Dateisystem Option von vielen ist. Während ZFS unter Solaris einfach da ist und tut was es oll sehe ich das bei Linux oft als Adventure Spiel.
 
Ein paar Anmerkungen
BSD
ist wie Solaris eine Unix Variante und nutzt ZFS seit langem. Für SMB wird wie bei Linux SAMBA genutzt. Etwas breitere Hardware Unterstützung als Solaris und bietet mehr Extraservices ausserhalb des Storagebereichs (z.B. Mediaserver).

Du empfiehlst Solarish ja meist eh als reines Storageverwaltungssystem unter ESXi. Falls man es aber ohne ESXi macht, mag BSD in Summe auch heute noch mehr Extraservices haben, aber es gibt inzwischen bei Joyent doch ne ganze Menge für Solarish. Über 16.500 Packages u.a. auch mediatomb, wenn es denn ein Mediaserver sein soll. Und alles was als Webanwendung verfügbar ist (z.B. Serviio oder andere apache/php/mysql-Anwendungen), kriegt man auch fast immer ans fliegen.
 
Du empfiehlst Solarish ja meist eh als reines Storageverwaltungssystem unter ESXi. Falls man es aber ohne ESXi macht, mag BSD in Summe auch heute noch mehr Extraservices haben, aber es gibt inzwischen bei Joyent doch ne ganze Menge für Solarish. Über 16.500 Packages u.a. auch mediatomb, wenn es denn ein Mediaserver sein soll. Und alles was als Webanwendung verfügbar ist (z.B. Serviio oder andere apache/php/mysql-Anwendungen), kriegt man auch fast immer ans fliegen.

Prinzipiell bevorzuge ich ganz generell einen minimalistischen Storageserver ohne Extra Dienste egal ob Barebone oder virtualisiert. Storage muss einfach stabil laufen und immer verfügbar sein. Wenn dann da die Systemplatte crasht ist sowas dann in einer Viertelstunde wieder online, auch ohne Backup. Extradienste, egal ob Mail, Media oder Webservices versuche ich immer zu virtualisieren - egal ob die dann unter BSD, Solaris/OmniOS oder Linux laufen. Die VMs sind ja dann auch genaus so einfach wiederherstellbar.

Fürs Virtualisieren nehme ich ESXi weil da die Vollvirtualisierung vor allem auch eines Storageservers am problemlosesten -und schnellsten klappt. Docker Container sind unter ESXi jetzt zwar verfügbar und zwar als voneinander unabhängige VMs, leider aber nicht in der Free Version. OmniOS und LX Container ist eine interessante Entwicklung vor allem weil die direkten Zugriff auf ZFS Dateisysteme haben, also ohne Umweg über Netzwerkdienste.
 
Zuletzt bearbeitet:
gea, auch von meiner Seite sehr vielen Dank für die Infos! Deine Ausführungen nehmen (zumindest für mich) so manchen Tiraden gegen ZoL den Wind aus den Segeln. ;)

Von den LX Containern in OmniOS hatte ich ein paar Informationen aufschnappen können, aber leider nicht genug. Kann man damit eine Linux-Applikation in OmniOS laufen lassen? Gibt es da Einschränkungen? Oracle Solaris hat sowas ja nicht mehr, richtig?!

Vielleicht kannst du mir ja eine letztendliche Empfehlung geben: Mein Ziel ist immer noch ein System, auf dem ich den Storage mit ZFS habe. Darauf soll dann als einzige Software Emby Server laufen. Den gibt es (im Rahmen der jetzt zu treffenden Entscheidungen!) für die gängigen Linux-Distros, für FreeBSD und als Docker Container. Eine Trennung von Storage und Emby Server will ich nicht, ich will auch nicht unnötig einen Hypervisor dazwischenschieben. Das Netzwerk ist durchgehend 1 Gbit und der Storage besteht nur aus 3.5er SATA-Festplatten. Am Ende wird der Server dann Musik und Videos an einen Kodi-Client ausliefern, mehr nicht. Wenn zu realisieren, will ich möglichst wenig manuell machen um ein defektes RAID wieder in Gang zu bringen. Und dann noch die Sache mit dem Copyback, wie ich bereits ansprach.
Mit Ubuntu (Server) kenne ich mich am besten aus, würde aber auch sehr gerne OmniOS (oder noch besser Oracle Solaris!) einsetzen, wenn ich denn dort den Emby Server einrichten könnte!

Zu was rätst du mir letzten Endes?


Vielen vielen Dank im Voraus!
 
Es wird immer ein Kompromiss nötig sein.

Wenn es nur um Emby geht, wird Ubuntu + ZoL am Einfachsten sein.
Die Problemlosigkeit, den Komfort und die Einfachheit von ZFS vor allem unter Solarish aber auch unter BSD erreicht es aber nicht.

Unter Solaris wird es nur mit mit Virtualisierung gehen (Vbox oder ESXi).

Unter OmniOS kann man mit den Packeten von Joyent/SmartOS sehr viel zum Laufen bringen. Zos hat das mit seinen Installern für OmniOS ja gezeigt. Am einfachsten wird auch hier Virtualisierung sein. Mit LX Zonen und Ubuntu gibt es hier eine weitere Option mit direktem Zugriff auf das ZFS Dateisystem siehe http://www.napp-it.org/doc/downloads/zones.pdf

BSD wäre eine Möglichkeit sofern man das z.B. unter FreeNAS am Laufen hat. Wird aber auch hier vermutlich auf Virtualisierung herauslaufen.

Zum defekten Raid
Ein Hotspare Laufwerk ist das was man braucht damit eine fehlerhafte Platte umgehend automatisch ersetzt wird und das Raid möglichst schnell wieder heile ist.
 
Zuletzt bearbeitet:
Auch von meiner Seite aus ein großes Dankeschön an gea!

Besonders, dass Dedup so extrem viel Ressourcen benötigt ist schon heftig. Natürlich ist es ein "nice to have", aber nicht um jeden Preis.
Vermutlich werde ich einfach mal ein wenig mit den gängigen NAS OS (Freenas, NAS4Free usw.) mal rumprobieren.

Was hälst du von Compression? Wie sieht da die HW-Belastung aus?

Vielen Dank und Gruß
Moritz
 
ZFS (alle Varianten) haben mit LZ4 einen fast genialen Compressor. Macht beste Compressionsraten bei niedriger CPU Last. Kann man besonders bei einem 1G Netzwerk eigentlich immer an lassen. Mit 10/40G und einem High-Performance System und schlecht komprimierbaren Daten würde ich es vermutlich aus lassen.

Ist aber im Gegensatz zu dedup flexibel und wirkt nur auf ein Dateisystem (Dedup ist ein Pool-Setting). Wenn man es ausschaltet werden anschliessend alle neu zu schreibenden Daten nicht mehr komprimiert. Wenn man es einschaltet wirkt es auch nur auf neue Daten.
 
Gibt es eigentlich grobe Richtlinien, welche Daten sich besonders gut / besonders schlecht komprimieren lassen? Mit Datenbanken soll das ganze ja sehr praktikabel sein, wie sieht es aber zB mit .mkv's aus?
 
gea, du hast mir schon sehr viel weiter geholfen als ich es je ahnen konnte! :cool:

Ich konnte es für mich mittlerweile besser eingrenzen und Ubuntu ist da dann doch rausgefallen! :d

Jetzt habe ich folgende "Konzepte" für mich im Kopf:
FreeBSD, da kann ich ja den Emby Server aus den Packages und den Ports installieren. Ist auch ein offiziell supportetes OS! Da frage ich mich nur, ob die Administration von ZFS in den Desktop integriert ist (ich würde dann KDE nutzen!).
OmniOS! Da habe ich die LX Zones noch nicht so ganz verstanden: Ist so eine Zone dann "instant" mit dem OS verfügbar oder muß die erst selbst booten? Muß man sich in der Zone dann immer extra anmelden oder ist da ein SSO am Werk? Kann ich dann im Grunde in so einer Zone ein minimales Ubuntu einrichten, welches den Emby Server trägt und die Aktualisierung läuft über apt-get? Sind die LX Zones Bestandteil deines napp-it?

Bei FreeBSD müsste ich also ZFS über den Desktop administrieren können!
Und bei OmniOS muß so eine LX Zone nur meine Hoffnungen erfüllen, dann bin ich sofort bei napp-it! :d

Kannst du mir da nochmal mit deinem Wissen weiterhelfen? ;)
 
Es gilt die einfache Regel: Zweimal komprimieren bringt nichts.

Ein unkomprimiertes Video läßt sich hervorragend komprimieren (da gibt es mit Verlust aber optimaleres als LZ4). Bei einem komprimierten H.264/MPEG-4 AVC Video macht man die Datei mit viel Rechenaufwand aber allenfalls größer.

LZ4 arbeitet verlustfrei und wirkt am besten wenn man Muster hat. Also z.B. statt eine Million mal ein weißes Pixel zu speichern kann man auch nur 1 Pixel speichern uns sagen, die nächsten 999999 sind identisch.
 
@Bene11660: MKVs haben bereits eine interne Kompression, die auch von vielen Video-Erstellungs-Programmen ausgenutzt wird!
Aus eigener Erfahrung kann ich allerdings sagen, dass die sich nur bei Original SD-Material (also Remuxe von DVD!) lohnt. Bei HD ist der H.264-Codec schon mit interner Kompression ausgestattet, da holtst du nix mehr raus.
Von daher wird dir auch eine dateisystembasierte Kompression nicht mehr bringen!
 
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