ZFS (ZoL) auf Linux-Dateiservern
ZFS (ZoL) auf Linux-Dateiservern
Moin zusammen,
habe testweise einen Samba-Server (nur Freigaben, kein PDC) mit ZFS (also ZoL) aufgesetzt.
Dazu laufen 2 Platten als Mirror.
Ich hätte gern etwas Input zu ZFS, weil ich zwiegespalten bin, ob mir das auch im Produktiveinsatz gefällt.
Ich habe festgestellt, dass clamav-Scans plötzlich unfassbar langsam auf den Platten laufen.
Außerdem gibt's scheinbar immernoch keinen TRIM-Support.
Ja, ich könnte zu FreeBSD wechseln, aber das würde auch in anderen Bereichen dann heftige Anpassungen bedeuten. Ist also nicht unbedingt ne Option.
habe testweise einen Samba-Server (nur Freigaben, kein PDC) mit ZFS (also ZoL) aufgesetzt.
Dazu laufen 2 Platten als Mirror.
Ich hätte gern etwas Input zu ZFS, weil ich zwiegespalten bin, ob mir das auch im Produktiveinsatz gefällt.
Ich habe festgestellt, dass clamav-Scans plötzlich unfassbar langsam auf den Platten laufen.
Außerdem gibt's scheinbar immernoch keinen TRIM-Support.
Ja, ich könnte zu FreeBSD wechseln, aber das würde auch in anderen Bereichen dann heftige Anpassungen bedeuten. Ist also nicht unbedingt ne Option.
Re: ZFS (ZoL) auf Linux-Dateiservern
Was genau möchtest Du denn wissen? Guck mal in den ix 01-03/2017 da gabs recht gute Tutorials zu ZFS..
Ansonsten braucht ZFS RAM und das viel, zu viel gibts nicht nur zu wenig
.. warum das jetzt langsamer ist könnte an zu wenig RAM liegen, desweiteren bietet ZFS gute stats und monitoring tools um dir anzuzeigen was/warum das langsam ist.
War es davor denn auch ein RAID-1 system?
Ansonsten braucht ZFS RAM und das viel, zu viel gibts nicht nur zu wenig
![Wink ;)](./images/smilies/icon_wink.gif)
War es davor denn auch ein RAID-1 system?
Debian-Nutzer ![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
Re: ZFS (ZoL) auf Linux-Dateiservern
Hallo!
Entschuldige meine stark verspätete Antwort.
Ja, vorher war's auch ein RAID1![Wink ;-)](./images/smilies/icon_wink.gif)
Allerdings ist das System ja ohnehin nur zum Testen, also ganz präzise Erfahrungswerte mit dessen Geschwindigkeit habe ich nun nicht. Weiß aber, dass ein clamAV-Scan für gewöhnlich erheblich schneller läuft.
Mit ZoL ist der selbst auf einer SSD ziemlich lahm.
Alle Datenträger sind übrigens mit cryptsetup verschlüsselt.
Mich interessieren allgemeine Erfahrungswerte. Denn ich habe gehört, ZoL sei generell nicht so gut wie "natives" ZFS auf BSD. Auch gibt es ja regelrechte Glaubenskriege, ob man nun unbedingt ECC-RAM einsetzen solle oder nicht. Ich hab z.B. teilweise noch "ältere" Server (3 Jahre oder so), die keinen ECC-RAM haben oder nutzen können. Die würd' ich auch ungern umrüsten. Das sind nämlich z.T. Celeron-Systeme, bei denen das einfach sinnlos teuer wäre.
Entschuldige meine stark verspätete Antwort.
Ja, vorher war's auch ein RAID1
![Wink ;-)](./images/smilies/icon_wink.gif)
Allerdings ist das System ja ohnehin nur zum Testen, also ganz präzise Erfahrungswerte mit dessen Geschwindigkeit habe ich nun nicht. Weiß aber, dass ein clamAV-Scan für gewöhnlich erheblich schneller läuft.
Mit ZoL ist der selbst auf einer SSD ziemlich lahm.
Alle Datenträger sind übrigens mit cryptsetup verschlüsselt.
Mich interessieren allgemeine Erfahrungswerte. Denn ich habe gehört, ZoL sei generell nicht so gut wie "natives" ZFS auf BSD. Auch gibt es ja regelrechte Glaubenskriege, ob man nun unbedingt ECC-RAM einsetzen solle oder nicht. Ich hab z.B. teilweise noch "ältere" Server (3 Jahre oder so), die keinen ECC-RAM haben oder nutzen können. Die würd' ich auch ungern umrüsten. Das sind nämlich z.T. Celeron-Systeme, bei denen das einfach sinnlos teuer wäre.
Re: ZFS (ZoL) auf Linux-Dateiservern
ZFS auf verschlüsselten Devices ist grundsätzlich nicht die beste Idee und zieht jedes FS in die Knie, erst recht wenn man dafür irgendwelche consumer-NAS mit grottenlangsamen Atom-CPUs verwendet.mrserious hat geschrieben: Alle Datenträger sind übrigens mit cryptsetup verschlüsselt.
Bezüglich clamAV: Wieviel RAM hat das system? Schlangenöl-scanner und z.b. rsync spülen den ARC (MRU) komplett durch. Bei wenig RAM ist das system dann ständig mit dem bereinigen des Caches beschäftigt (bzw ggf verschieben in den L2ARC).
Re: ZFS (ZoL) auf Linux-Dateiservern
Moin,
das Test-System ist nen i5 mit 16GB RAM. Da ist also sicher noch Luft nach oben, aber für nen Dateiserver sollte es reichen.
Klar: Verschlüsselung kostet immer Leistung, aber mit AES-NI und der o.g. Hardware dürfte das keine SO dramatischen Leistungseinbußen nach sich ziehen. Zumal ich auch echte Server im Einsatz habe, die etwas weniger Leistung haben, ebenfalls verschlüsselt sind (dort mit ext4) und da läuft bspw. der Virenscan erheblich schneller.
das Test-System ist nen i5 mit 16GB RAM. Da ist also sicher noch Luft nach oben, aber für nen Dateiserver sollte es reichen.
Klar: Verschlüsselung kostet immer Leistung, aber mit AES-NI und der o.g. Hardware dürfte das keine SO dramatischen Leistungseinbußen nach sich ziehen. Zumal ich auch echte Server im Einsatz habe, die etwas weniger Leistung haben, ebenfalls verschlüsselt sind (dort mit ext4) und da läuft bspw. der Virenscan erheblich schneller.
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: ZFS (ZoL) auf Linux-Dateiservern
Hat cryptsetup ein vorteil gegenueber die eingebaute ZFS encryption?
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
Re: ZFS (ZoL) auf Linux-Dateiservern
Den Vorteil, das ich im Umgang damit geübt bin ![Wink ;-)](./images/smilies/icon_wink.gif)
Habe mir die eingebaute ehrlich gesagt noch garnicht weiter angeschaut.
![Wink ;-)](./images/smilies/icon_wink.gif)
Habe mir die eingebaute ehrlich gesagt noch garnicht weiter angeschaut.
Re: ZFS (ZoL) auf Linux-Dateiservern
Keinen. ZFS native encryption ist aber noch in Entwicklung und AFAIK derzeit nur in ZoL (dev branch?) verfügbar, also noch nicht upstream in OpenZFS und auch noch nicht reviewed. Ergo: "Here be Dragons"Lord_Carlos hat geschrieben:Hat cryptsetup ein vorteil gegenueber die eingebaute ZFS encryption?
Da die ZFS integration unter Linux eher schlecht bis nicht vorhanden ist und ein äquivalent zu bootenvironments kaum möglich ist, da Linux eher mittelmäßig bis schlechte Dateisystemhygiene besitzt (Linux FHS vs 'sauberes' Unix filesystem layout - die BSDs haben praktisch alle lokalen Anpassungen/Konfigurationen in /usr/local) und GRUB a) keine vollwertige ZFS-Unterstützung (somit auch nicht für BEs) besitzt und regelmäßig auseinanderfliegt, nutze ich auf Fileservern (bzw mittlerweile allen servern) FreeBSD. Bei Bedarf werden dort Ordner/datasets (homes) per PEFS auf Dateisystemebene verschlüsselt. Dabei werden snapshots/backups nicht beeinflusst und encryption läuft auf den clients, somit kann Serverseitig auch nichts entschlüsseltes 'geleaked' werden.
Größtes Problem mit ZFS auf verschlüsselten blockdevices ist die meist extreme io-amplification, da ZFS seine IO (speziell writes) serialisiert und auf die zugrundeliegenden blockgrößen und positionen auf bem Datenträger optimiert. Pfuscht dann aber noch eine Verschlüsselung darunter rum, geht das häufig/meistens nach hinten los und führt zu massiven random I/O.
Mit ZFS native encryption hat ZFS wieder Kenntnis über die tatsächliche Struktur auf der Platte und die Optimierungen greifen wieder; zudem sollen die Daten dann auch verschlüsselt im ARC liegen. Auch bei replikation per send/receive bleiben die datasets verschlüsselt.
My 2 cents zu Vollverschlüsselten Servern: Ein Server muss ohne manuellen Eingriff booten und seine dienste starten können - somit fallen alle Verrenkungen über Passworteingabe flach. Ein USB-stick mit keys ist im RZ auch eher sinnfrei, ebenso alle anderen Lösungen bei denen die Keys zur bootzeit verfügbar sind - ist der server gebootet kann ja wieder auf die verschlüsselten Daten zugegriffen werden.... Die einzig sinnvolle Lösung für mich war daher schon immer: Grundsystem normal ohne Verschlüsselung installieren, userdaten ggf auf dateiebene verschlüsseln (-> PEFS).
Emails gehören ende-zu-ende verschlüsselt, nicht erst "at rest" auf dem server; ein verschlüsseltes /var/mail ist daher IMHO humbug und führt ggf nur zu einem nicht ohne manuellen eingriff startenden mailserver und verkompliziert ggf backups...
Bei Laptops kann man natürlich anders argumentieren - wobei man hier auch streiten kann, ob es im Extremfall nun besser ist wenn man den Laptop an der Grenzkontrolle überhaupt nicht booten kann, oder wenn er zwar normal startet, aber die Userdaten verschlüsselt und verborgen sind.
Mit PEFS habe ich mir die zweite Lösung gebaut: Mein User hat ein normales passwort in der /etc/passwd; und ein anderes für PEFS. PAM akzeptiert beide für den login; nur mit dem PEFS wird aber auch das verschlüsselte home-dataset gemounted und entschlüsselt. Mit dem normalen Passwort landet man in einem jungfräulichen Account ohne jegliche Daten in ~
Re: ZFS (ZoL) auf Linux-Dateiservern
Da stimm ich dir bei fast allem voll zu, r4pt0r ![Wink ;-)](./images/smilies/icon_wink.gif)
Der Server wird auch nicht voll-verschlüsselt. Und für eine System-Partition brauche ich normalerweise auch kein ZFS.
Bei Verschlüsselung+ZFS reden wir wirklich von einem reinen Festplatten-Array, auf dem ausschließlich Daten liegen.
Warum ist der ZFS-support eigentlich so "schlecht" unter Linux? ZFS ist doch ne sinnvolle Sache, die man supporten müsste.
![Wink ;-)](./images/smilies/icon_wink.gif)
Der Server wird auch nicht voll-verschlüsselt. Und für eine System-Partition brauche ich normalerweise auch kein ZFS.
Bei Verschlüsselung+ZFS reden wir wirklich von einem reinen Festplatten-Array, auf dem ausschließlich Daten liegen.
Warum ist der ZFS-support eigentlich so "schlecht" unter Linux? ZFS ist doch ne sinnvolle Sache, die man supporten müsste.
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: ZFS (ZoL) auf Linux-Dateiservern
Danke r4pt0r . Netter Beitrag +1
mrserious, ich habe mir mal sagen lassen das im privaten bereit bei gigabit lan ZFS unter linux wohl "gut genug" ist. In wieweit das stimmt kann ich nicht sagen.
________________
Wo wir gerade ein paar ZFS experten hier haben, kann man ein zfs raid (mit 1 oder 2 parity drives, aehnlich raid5/6) erstellen wo man einzielende Festplatten im nachhinein hinzufuegen kann?
mrserious, ich habe mir mal sagen lassen das im privaten bereit bei gigabit lan ZFS unter linux wohl "gut genug" ist. In wieweit das stimmt kann ich nicht sagen.
________________
Wo wir gerade ein paar ZFS experten hier haben, kann man ein zfs raid (mit 1 oder 2 parity drives, aehnlich raid5/6) erstellen wo man einzielende Festplatten im nachhinein hinzufuegen kann?
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
Re: ZFS (ZoL) auf Linux-Dateiservern
Leider nicht, man kann immer nur um eine weitere komplette RAID-Gruppe vergrößern. Also vorher planen, dann hat man weniger VerschnittLord_Carlos hat geschrieben:Wo wir gerade ein paar ZFS experten hier haben, kann man ein zfs raid (mit 1 oder 2 parity drives, aehnlich raid5/6) erstellen wo man einzielende Festplatten im nachhinein hinzufuegen kann?
![Wink ;)](./images/smilies/icon_wink.gif)
Re: ZFS (ZoL) auf Linux-Dateiservern
(Achtung: das Folgende kann subjektive/persönliche Meinungen und OT enthalten)mrserious hat geschrieben:Warum ist der ZFS-support eigentlich so "schlecht" unter Linux? ZFS ist doch ne sinnvolle Sache, die man supporten müsste.
Linux leidet in vielen Bereichen unter dem "NIH-syndrome" (not invented here). Da werden dann Lösungen selbst zusammengeschustert anstatt vorhandene Technologien zu nutzen oder zumindest aus deren Fehlern zu lernen.
Prominentes Beispiel: DTrace. Unter Linux muss(te)* man sich mit langsamen, unsicheren und halbgaren Lösungen wie uprobe, ktap oder bcc rumschlagen während praktisch alle (!) relevanten UNIXes und abkömmlinge DTrace bereits seit langem portiert haben - selbst Apple hat DTrace für OS X portiert, anstatt (wie sonst üblich) eine eigene, inkompatible Lösung zu entwickeln.
Dazu kommt, dass "Linux" kein vollständiges OS ist - Linux per Definition ist der Kernel. Ende. Alles andere liegt in der Verantwortung und an den Vorlieben der Disturbutionen oder der User. Selbst die libc ist optional und es existieren diverse Variationen (!!). Alles muss also irgendwie auf den kleinsten gemeinsamen Nenner begrenzt sein um austauschbar zu bleiben.
Klassische UNIX und BSD sehen Kernel + alle wichtigen Kernkomponenten und Tools als "das Betriebssystem" und diese sind vollständig aufeinander abgestimmt und funktionieren als Einheit. So sind in FreeBSD z.B. viele Tools (z.B. pkg, top, ifconfig) auch "jail-aware" und Jails können ZFS nativ nutzen. Das automatisch vom installer vorgeschlagene Layout der ZFS datasets ist bereits auf die Verwendung von Boot Environments ausgerichtet. Der Bootloader versteht das Konzept der BEs und bietet diese zur Auswahl an. Überall findet man sauber integrierte und abgestimmte Lösungen, die viele Abläufe vereinfachen oder erst möglich machen.
Insgesamt hat man einfach ein sauberes, homogenes und gut abgestimmtes System in dem nicht ständig Versionskonflikte einzelner Tools und Abhängigkeiten entstehen. Da das "base" System zwischen verschiedenen Systemen ziemlich einheitlich ist und lokale Änderungen schon in der Dateisystem-hierarchie getrennt vom base-system sind, ist Automatisierung (deployment, konfiguration) bereits OOTB _sehr_ einfach. Mit Linux braucht man hier mittlerweile schon speziell dafür optimierte Distributionen wie z.b. Alpine Linux...
Die _extreme_ Modularität die teilweise als Stärke von Linux gesehen werden kann (mit systemd aber praktisch für alle "großen" distributionen hinfällig geworden ist) und die fast schon fanatische Verteidigung der "unantastbaren" ABI ist gerade bei der Integration von neuen Technologien wie ZFS eher hinderlich. Das artet dann eben oft in halbgaren Bastellösungen aus.
(Sidenote: Die in Stein gemeißelte Linux-ABI, die sich praktisch nicht mehr weiterentwickelt, macht es allen anderen OS mittlerweile relativ einfach, Linux-ABI-Kompatibilität herzustellen. Daher gibt es mittlerweile eine Kompatibilitätsschicht (= primär ein mapping der systemcalls) in fast allen anderen Betriebssystemen: FreeBSD, OS X, Solaris/Illumos (LX-Zones) und sogar Windows...)
Rückblickend betrachtet waren die debian ZoL-Server die ich betrieben habe, ziemlich zusammengeschustert (praktisch 2/3 Kernelupdates brauchten hinterher manuelle Eingriffe damit das system wieder bootbar wurde. Von GRUB fang ich erst garnicht an...) und im Gegenzug waren aber nur wenig funktionen von/mit ZFS wirklich nutzbar/möglich. Ob es den Aufwand wirklich wert war sei dahingestellt - die Alternative dazu waren aber nur Gebilde aus md-raid, lvm und ext4; was ebenfalls einen irrsinnigen Administrationsaufwand bedeutet, nicht wirklich performant ist, keinerlei Sicherheit bzgl, Datenintegrität bietet und die snapshot-Funktionalität von LVM ist auch eher unbrauchbar im Vergleich zu ZFS...
Btrfs ist keine Alternative, da es noch lange nicht 'production safe' ist bzw nicht mit dieser Maßgabe von Anfang an entwickelt wurde (!!). Btrfs ist ebenfalls wieder ein Beispiel für das "NIH-Syndrome" im Linux-Ökosystem. Statt dass man ein Kampferprobtes, performantes und sicheres Dateisystem wie ZFS portiert oder zumindest als Vorbild verwendet, wird was eigenes gebaut und dabei nicht einmal angeschaut wie und vor allem warum vorhandene Lösungen wie ZFS manche Probleme auf eine gewisse Art gelöst haben. Man bekommt manchmal das Gefühl, dass man es mit Dickköpfigen Teenagern zu tun hat, die auf-Teufel-komm-raus sich erst den Kopf einrennen müssen bevor sie Einsehen dass sie auch einfach aus der Vergangenheit lernen könnten. (Nein, ich werd das jetzt nicht auch noch auf systemd beziehen - für ein Ranting dieser Größenordnung ist es zu Warm heute
![Wink :wink:](./images/smilies/icon_wink.gif)
* Oracle hat DTrace für Oracle Linux portiert - inwiefern das für andere Linux-derivate verfügbar ist und funktioniert hab ich nie wirklich verfolgt. Auch ob/wie "production safe" dieser Port ist kann ich nicht beurteilen.
Ich sättige zu Hause mit relativ wild zusammengewürfelter Hardware von einem ZFS-Pool mit 4xmirror vdev und 2x SSD als L2ARC einen 2x4GBit active/active FibreChannel link zum Desktop. Schreibend wird zwar irgendwann gethrottled, da ein mirror noch aus langsamen SATA2 HDDs besteht und ZFS den Cache nach gewisser zeit auf die Geschwindigkeit des Pools abbremst.Lord_Carlos hat geschrieben: mrserious, ich habe mir mal sagen lassen das im privaten bereit bei gigabit lan ZFS unter linux wohl "gut genug" ist. In wieweit das stimmt kann ich nicht sagen.
Lesend kann der Link nach etwas aufwärmzeit auch über längere Zeit gesättigt werden - erst recht wenn die Daten gut für prefetching geeignet sind. Der Client wird dann praktisch konstant aus dem ARC im RAM versorgt.
Der Storageserver hier in der Firma ist per 10Gbit Ethernet / iSCSI an den Virtualisierungshost angebunden - die IOPS und R/W performance der targets auf bem ZFS-Server über diesen Link ist besser, als die des lokalen Pools (1x RAIDZ1 aus 3x HGST SAS + SSDs für L2ARC und ZIL). Latenz ist natürlich lokal besser - diskimages für DBs liegen also am lokalen pool, alles was eigentlich nur rohe Bandbreite und/oder viel Platz braucht (und kein ZFS in der VM nutzen kann/muss) liegt auf iSCSI targets.
Für normales GBit-LAN reicht praktisch jeder Pool aus halbwegs aktuellen SATA3 Platten aus. Im typischen Heimnetz werden billige switches und/oder Plastikrouter und gammlige Realtek/Ralink/... Onboard-NICs ohne jegliche HW-offloading funktionen verwendet - da liegt der Flaschenhals sowieso eher im Netzwerk bevor selbst eine eher Langsame HDD mit ~75MB/s an die Grenzen stößt, geschweige denn ein vdev aus mehreren Platten, bei dem sich je nach konfiguration lesend und/oder schreibend die bandbreiten addieren (IOPS sind im Heimbereich sowieso nur extrem selten relevant).
Nein, die parität eines vdev muss natürlich vorher festgelegt werden (RADIZ1/2/3..), da das on-disk-layout aller provider davon abhängt. Nachträgliche Änderungen sind nicht möglich. Weitere vdevs kann man natürlich immer hinzufügen (auch bestehend aus einer einzelnen HDD, was aber eher unsinnig ist)Lord_Carlos hat geschrieben: kann man ein zfs raid (mit 1 oder 2 parity drives, aehnlich raid5/6) erstellen wo man einzielende Festplatten im nachhinein hinzufuegen kann?
Da man ohnehin nur vdevs mit identischem layout und Anzahl provider nutzen sollte, legt man sich hier aber sowieso einmal beim Erstellen eines Pools fest, abhängig von der art der Arbeitslast und gewünschten/geforderten Performance vs Ausfalltoleranz. Für grundlegende Änderungen des Layouts erstellt man am besten einen neuen Pool und überträgt alle Daten per ZFS send|receive.
Aktuell wird an der Möglichkeit gearbeitet, einzelne root-vdevs zu entfernen (primär um versehentliche Verwendung von [cmd]zfs add[/cmd] anstatt [cmd]zfs attach[/cmd] rückgängig zu machen). Das geschieht über ein mapping der daten vom zu entfernenden vdev auf alle anderen vdevs über zuordnungstabellen. Auf Basis dieser Technik wird auch an einem "declustered zraid" gearbeitet - hier werden einfach _alle_ verfügbaren Laufwerke als ZRAID mit definierter parität genutzt und spares/spare stripes unter allen vdevs geshared. Fällt z.B. ein beliebiges Laufwerk in einem Pool aus 30 Platten aus, beteiligen sich alle 29 verbliebenen Platten am rebuild und nehmen die Daten der ausgefallenen Platte auf.
Beides wird etwas genauer in der openZFS roadmap beschrieben:
http://open-zfs.org/wiki/Roadmap#Top-level_vdev_removal
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: ZFS (ZoL) auf Linux-Dateiservern
So habe ich das auch verstanden. Aber dann meinte jemand aus dem internet das dies wohl doch gehen soll.r4pt0r hat geschrieben:Nein, die parität eines vdev muss natürlich vorher festgelegt werden (RADIZ1/2/3..), da das on-disk-layout aller provider davon abhängt. Nachträgliche Änderungen sind nicht möglich. Weitere vdevs kann man natürlich immer hinzufügen (auch bestehend aus einer einzelnen HDD, was aber eher unsinnig ist)Lord_Carlos hat geschrieben: kann man ein zfs raid (mit 1 oder 2 parity drives, aehnlich raid5/6) erstellen wo man einzielende Festplatten im nachhinein hinzufuegen kann?
Code: Alles auswählen
zpool add <NAME_OF_POOL> <HDD_ID>
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
Re: ZFS (ZoL) auf Linux-Dateiservern
Ja wenn das Internet sowas sagt muss das wohl richtig seinLord_Carlos hat geschrieben: So habe ich das auch verstanden. Aber dann meinte jemand aus dem internet das dies wohl doch gehen soll.Code: Alles auswählen
zpool add <NAME_OF_POOL> <HDD_ID>
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Im ernst: Damit fügst du einen einzelnen provider (Platte) als root-vdev hinzu - ohne jegliche redundanz und mit extremen performanceeinbußen für den gesamten Pool (die richtet sich grob gesagt nach dem langsamsten vdev).
DON'T TRY THIS AT WORK! (At Home ist OK - dort schießt man sich damit nur selbst ins Knie...)
Nochmal: Zu einem RAIDZ-vdev können nachträglich keine (aktiven) provider hinzugefügt werden, nur hotspares.
Zu einem mirror kann man nachträglich beliebig viele provider hinzufügen - der mirror muss aber bereits beim erstellen des vdevs als solcher erzeugt werden, selbst wenn er anfangs nur aus einem provider bestehen sollte. Der Unterschied zwischen beiden Varianten ist schon per zpool status ersichtlich:
Code: Alles auswählen
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
gpt/wd-wcc3f0vz5ctr ONLINE 0 0 0
logs
gpt/zil0 ONLINE 0 0 0
cache
gpt/cache0 ONLINE 0 0 0
Code: Alles auswählen
zroot ONLINE 0 0 0
gpt/wd-wcc3f0vz5ctr ONLINE 0 0 0
logs
gpt/zil0 ONLINE 0 0 0
cache
gpt/cache0 ONLINE 0 0 0
- jph
- Beiträge: 1049
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: ZFS (ZoL) auf Linux-Dateiservern
Die Lizenz, der der Code von ZFS unterliegt (CDDL), verbietet die Aufnahme in den GPL-lizensierten Kernel. Und da Sun bzw. Oracle das nicht ändern wollten, musste ZFS halt draußen bleiben. (Das war wahrscheinlich einer der Auslöser für die Entwicklung von btrfs. Da letzteres mittlerweile recht weit gediehen ist, ist der Zug für ZoL IMO abgefahren.)mrserious hat geschrieben:Warum ist der ZFS-support eigentlich so "schlecht" unter Linux? ZFS ist doch ne sinnvolle Sache, die man supporten müsste.
Re: ZFS (ZoL) auf Linux-Dateiservern
Guten Morgen ![Wink ;-)](./images/smilies/icon_wink.gif)
Also im Grunde interessiert mich nur die Daten-Integrität von ZFS.
Meist verwende ich ohnehin nur mirrors und will in Verbindung mit den Checksums dafür sorgen, dass meine Daten nicht korrumpiert werden.
Insofern ist das jetzt kein sooo großes Drama. Fänd es nur schade, wenn das Projekt ZoL mehr oder weniger einschläft, denn es ist ja eine sinnvolle Sache.
Wie weiter oben schon gesagt wurde: In meinem Szenario stattdessen z.B. ext4 und md-Raids zu nutzen ist nicht wirklich ne Alternative... Denn das schützt mich ja wirklich nur vor nem reinen Mechanik-Defekt. Und den Zustand meiner Backups prüfen kann ich damit auch nicht.
![Wink ;-)](./images/smilies/icon_wink.gif)
Also im Grunde interessiert mich nur die Daten-Integrität von ZFS.
Meist verwende ich ohnehin nur mirrors und will in Verbindung mit den Checksums dafür sorgen, dass meine Daten nicht korrumpiert werden.
Insofern ist das jetzt kein sooo großes Drama. Fänd es nur schade, wenn das Projekt ZoL mehr oder weniger einschläft, denn es ist ja eine sinnvolle Sache.
Wie weiter oben schon gesagt wurde: In meinem Szenario stattdessen z.B. ext4 und md-Raids zu nutzen ist nicht wirklich ne Alternative... Denn das schützt mich ja wirklich nur vor nem reinen Mechanik-Defekt. Und den Zustand meiner Backups prüfen kann ich damit auch nicht.
Re: ZFS (ZoL) auf Linux-Dateiservern
Wenns um Datenintegrität geht ist ZFS natürlich immer sinnvoll - egal unter welchem OS.
Tipp: lege den Pool fürs "Datengrab"/Backups auf eigene Platten und verwende z.B. eine/zwei separate SSDs fürs OS. Dann lässt sich der Pool später auch einfach in ein anderes System übertragen oder das OS austauschen.
So lange man keine OS-Spezifischen ZFS-Features nutzt, lassen sich Pools plattformübergreifend importieren - ich nutze USB-Sticks mit ZFS z.B. für größere Datenabgleiche zwischen FreeBSD, Illumos und den beiden verbliebenen Devuan Servern.
Tipp: lege den Pool fürs "Datengrab"/Backups auf eigene Platten und verwende z.B. eine/zwei separate SSDs fürs OS. Dann lässt sich der Pool später auch einfach in ein anderes System übertragen oder das OS austauschen.
So lange man keine OS-Spezifischen ZFS-Features nutzt, lassen sich Pools plattformübergreifend importieren - ich nutze USB-Sticks mit ZFS z.B. für größere Datenabgleiche zwischen FreeBSD, Illumos und den beiden verbliebenen Devuan Servern.
Re: ZFS (ZoL) auf Linux-Dateiservern
Jau, mache ich schon so ![Wink ;-)](./images/smilies/icon_wink.gif)
Wie vorher schon geschrieben: Das OS muss auch nicht auf eine ZFS-Partition.
Nutze auch bisher nie vdevs, sondern arbeite immer auf dem reinen Pool.
![Wink ;-)](./images/smilies/icon_wink.gif)
Wie vorher schon geschrieben: Das OS muss auch nicht auf eine ZFS-Partition.
Nutze auch bisher nie vdevs, sondern arbeite immer auf dem reinen Pool.