[Sammelthread] ZFS Stammtisch

[gea]

Das Screenshot zeigt Timeslider.
Das ist ein recht geniales Tool. Man wählt einen Ordner und kann dann mit dem Timeslider in der Zeit zurückgehen. Das gibt es nach wie vor bei Oracle Solaris und OpenIndiana wenn man den Desktop mit installiert.

Die Hauptalternative ist Windows. Wenn man damit ein CIFS Share mountet, kann man mit "Ordnereigenschaft-Vorherige Version" auf ZFS Snapshots zugreifen. Das geht zumindest mit dem Solaris CIFS Server perfekt.

Letzte Möglichkeit ist es lokal auf den Ordner /pool/dateisystem/.zfs/snapshots zuzugreifen. Da liegen die Snapshots drin. Man kann sich den Ordner auch auf in einer Freigabe anzeigen lassen.

 

[VivianMeally]

TimeSlider ist recht genial, aber wie ich rausgelesen habe, funktioniert es wohl nur auf Solaris, OpenIndiand und pcbsd un das auch nur local?

Windows Shadow Copy funktioniert wunderbar mit ZFS snapshots. Leicht einzurichten und "just works".

Kenn jemand eine möglichkeit das auch auf Linux umzusetzen? Kann nicht glauben das VSS mit ZFS snapshots auf dem NAS funktioniert und in Linux keine möglichkeit dazu gibt (zumindest habe ich keine gefunden)

 

[gea]

TimeSlider gibts nur mit Solaris und den freien Forks wie OpenIndiana - nicht unter BSD oder Linux.
Unter Linux als Client sehe ich auch nur die Möglichkeit direkt auf ../.zfs/snapshots zuzugreifen.

Wenn Solaris das NAS macht, gäbs allenfalls noch VNC

 

[amorph]

Hallo, mal eine Frage an die ZFS-Profis: ich habe vor in den nächsten Tagen mal ein FreeNas-System auszutesten. Hier würde ich gerne 4 x 4TB und 4 x 3TB Platten verwenden. Kann mir jemand sagen, wie ich die Platten am besten ZFS-technisch verwende? Meine Priorität liegt eindeutig auf Performance, dann Storage-Space und dann erst Sicherheit. Soll ich hier ein RAID-Z1 anlegen? Was sind hier die Best-Practices? Vielen Dank!

 

[zos]

Eigenheiten von SmartOS

Wie viele von Euch sicher wissen, ist SmartOS eine recht spezielle Distribution mit einem klaren Fokus auf Virtualisierung und weniger (bis gar nicht) als Fileserver mit einer read-only global zone. Ich bin auf einen ganz interessanten Blog-Artikel gestossen, der einige Probleme (und deren unkonventionelle Lösungen) im Falle von individuellen Anpassungen des Systems behandelt und möchte Euch diesen nicht vorenthalten

=> SmartOS for cranky Solaris People

 

[Bzzz]

Hier würde ich gerne 4 x 4TB und 4 x 3TB Platten verwenden. Kann mir jemand sagen, wie ich die Platten am besten ZFS-technisch verwende? Meine Priorität liegt eindeutig auf Performance, dann Storage-Space und dann erst Sicherheit. Soll ich hier ein RAID-Z1 anlegen? Was sind hier die Best-Practices? Vielen Dank!

Gestripte Mirrors? Ist halt hochgradig verschwenderisch, aber vielleicht kommt auch ein Stripe über zwei Z1 in Frage, die jeweils die vier gleichgroßen Platten umfassen...fünf Platten je Z1 wären aber wohl schlauer. Oder generell, gleichgroße Platten, aber fürs Testen isses egal, da kannst du auch mal mixen.

 

[fesh]

Hallo, mal eine Frage an die ZFS-Profis: ich habe vor in den nächsten Tagen mal ein FreeNas-System auszutesten. Hier würde ich gerne 4 x 4TB und 4 x 3TB Platten verwenden. Kann mir jemand sagen, wie ich die Platten am besten ZFS-technisch verwende? Meine Priorität liegt eindeutig auf Performance, dann Storage-Space und dann erst Sicherheit. Soll ich hier ein RAID-Z1 anlegen? Was sind hier die Best-Practices?

Verschlüsselung? Kann die CPU AES-NI? Mein HP Microserver N54L (AMD Turion II) kann es nicht, also musste ich darauf verzichten.
Aber wenn Du eh 8 SATA-Ports hast werden Board und CPU wohl 'ne Nummer größer sein...

 

[amorph]

Gestripte Mirrors? Ist halt hochgradig verschwenderisch, aber vielleicht kommt auch ein Stripe über zwei Z1 in Frage, die jeweils die vier gleichgroßen Platten umfassen...fünf Platten je Z1 wären aber wohl schlauer. Oder generell, gleichgroße Platten, aber fürs Testen isses egal, da kannst du auch mal mixen.

Das heisst ich lege 2 RAID-Z1, jeweils mit den gleich großen Platten an und stripe die beiden RAIDs dann? Ist das am performantesten?

Verschlüsselung? Kann die CPU AES-NI? Mein HP Microserver N54L (AMD Turion II) kann es nicht, also musste ich darauf verzichten.
Aber wenn Du eh 8 SATA-Ports hast werden Board und CPU wohl 'ne Nummer größer sein...

Verschlüsselung ist mir erst mal egal. Aber danke für den Hinweis.

 

[Morpheus2200]

Hallo, mal eine Frage an die ZFS-Profis: ich habe vor in den nächsten Tagen mal ein FreeNas-System auszutesten. Hier würde ich gerne 4 x 4TB und 4 x 3TB Platten verwenden. Kann mir jemand sagen, wie ich die Platten am besten ZFS-technisch verwende? Meine Priorität liegt eindeutig auf Performance, dann Storage-Space und dann erst Sicherheit. Soll ich hier ein RAID-Z1 anlegen? Was sind hier die Best-Practices? Vielen Dank!

Ich würde ja Mirrors stripen. Aber wenn dir Sicherheit total egal ist kannst du ja auch auf den Mirror verzichten.
Die Anforderung nach Priorität ist schwammig. Definier lieber ein minimum an Kapazität und Sicherheit. Also Stripes stripen wäre vermutlich die performanteste Lösung, dafür wäre bei ausfall einer Platte alles weg. Die vernünftigste Lösung wenn du auf den Platz nicht angewiesen bist sind Striped Mirrors. Zumindest wenn es dir um vernünftige random I/O Performance geht.
Ausreichend gute sequentielle Performance bekommt man auch mit einem anderen Raid level hin.

Wie greifst du denn darauf zu und wie viel Cache setzt du ein? Und was kann dein Netzwerk überhaupt übertragen? Es bringt dir halt nichts wenn du mehrere hundert MB/s sequentiell lesen und schreiben kannst und dann über einen GBit Link an deine Clients angebunden bist.

Pauschal kann man sagen für anständige Performance Kompression aktiv lassen und keine Deduplikation.

 

[amorph]

Sicherheit ist mir nicht total egal, aber auch nicht so wichtig, da ich nachts sowieso Backups auf einen anderen Rechner laufen lasse. Ich steige von einem Synology um - dort hatte ich ein Raid-5 laufen, sprich eine Platte für die Parität würde mir ausreichen. Andererseits hätte ich gerne so wenig wie möglich "Verschnitt" wegen der unterschiedlichen Plattengrößen. Und du hast absolut Recht, natürlich spielt der Netzwerkspeed absolut eine Rolle. Hier plane ich ein Bonding zweier 1Gbit-Links. Vielleicht rüste ich den Server und meine Workstation auch irgendwann auf 10Git auf.

Verstehe ich es richtig, dass Kompression kein Performance-Killer ist?

 

[Morpheus2200]

Du kannst das Verfahren für die Kopression ja selber wählen ich meine lzjb ist default und sehr performant. Das verursacht nahezu keine CPU last und bei komprimierbaren Daten reduzierst du damit die Zugriffe auf die Platten, da ja weniger Blöcke geschrieben oder gelesen werden müssen.
Auf performance optimierte Kopressionsalgorithmen erzielen meist etwas geringere Kopressionsraten. Aber meine Erfahrung ist entweder du hast Daten die sich gut koprimieren lassen, dann hilft auch so ein einfacher Algortihmus schon sehr viel. Oder du kannst es dir ganz sparen.
Werden aber eh nur schon komprimierte Daten geschrieben kannst du dir das natürlich auch sparen.

Also ich würde für I/O performance Striped Mirrors nehmen. Du kannst aber auch 2 Raid Z1 (ähnlich Raid 5) Gruppen Stripen. 2 Striped Mirrors geben dir halt 2/4 der Kapazität Striped Z1 3/4.
Die Anzahl der VDEVs die du am Ende ein einen Stripe Packst entscheidet über die I/O performance.

Ich habe hier ein System mit 8 2TB HDs die ich als striped Mirror nutze. Also 4 Mirrors striped. Die performance ist deutlich besser als bei nur einer Raidgruppe. Kombiniert mit großem read cache versorge ich da 50 Clients mit die parallel zugreifen.

 

[Bzzz]

Das heisst ich lege 2 RAID-Z1, jeweils mit den gleich großen Platten an und stripe die beiden RAIDs dann? Ist das am performantesten?

Wenn du die einzeln erstellst, bleiben sie auch einzeln. Idee war ja, ein Z1 zu erstellen (create raidz disk1/2/3/4), und dann ein weiteres dranzukleben (add raidz disk5/6/7/8). Einzeln (2x create ...) wärn die Z1 zwar sicherer, aber helfen in Sachen Performance auch nicht zusammen (sequentiell) und sind nicht so schön administrierbar.

Andererseits hätte ich gerne so wenig wie möglich "Verschnitt" wegen der unterschiedlichen Plattengrößen.

Ja lustig, aber der Verschnitt bei nem Mirror wär dir egal?

 

[Morpheus2200]

Ich glaube für die Performance für viele Anwendungsfälle ist am Ende aber auch deine Cache Größe ausschlaggebend. Ich habe mir gerade mal gedacht schmeiße ich doch mal kurz nen kleinen IOzone Test auf der großen ZFS Kiste an. Da sind 2 Raidz2 Sets mit je 10x3TB gestriped. Kompression ist an Dedup aus. Ich komme über NFS mit einem 8GB File halt garnicht wirklich dazu die Perfomance der Raid Sets zu testen weil alles aus dem Cache bedient wird. Um auf aussagekräftige Werte für die Platten zu kommen müsste ich vermutlich 512GB oder 1TB Filesize nehmen und das will ich der Kiste im Produktivbetrieb gerade nicht zumuten. Cached komme ich auf 6-10GB/s lesend 2-4GB/s schreibend. Leider unrealistische Werte wenn die Platten beteiligt wären.
Aber da stellt sich dann die Frage was man testen will. Wenn unter realen Bedingungen im Betrieb mehere GB/s geliefert werden ist mir am Ende recht egal ob das am Raid Layout oder am cache liegt.
Ob du also in deinem Szenario einen Unterschied zwischen striped Mirrors oder striped Z1 oder einem großen Z1 sehen wirst liegt auch am Zugriffsmuster und Cache und Netzwek usw. Vielleicht hast du bei SATA Platten/Controllern auch früher schon irgendwo dein Nadelöhr in dem System. Wie sieht deine Hardware denn überhaupt aus?

Nochmal zur Kompression. ZFS komprimiert die Daten ja bevor sie auf die Platten geschrieben werden. Daher kannst du einen höheren Durchsatz erreichen. Hast du 10GB Daten die sich auf 2GB komprimieren lassen schreibt dein System auch nur 2GB auf die Platten und braucht dafür halt auch nur so lange wie es eben zum schreiben von 2GB braucht. In dem Fall hast du einen Performancegewinn. Beim lesen der Daten müssen auch wieder nur 2GB gelesen werden. Die CPU Last durch Kompression ist auf den meisten modernen Systemen zu vernachlässigen. Ganz nebenbei erhöhst du damit natürlich die nutzbare Kapazität.

 

[phlowx]

LZ4 kann man für den kompletten Pool aktivieren. Blöcke die nicht mindestens 12,5% Platzersparnis erbringen, da sich die Datei z.B. nur schwer komprimieren lässt, werden eh nicht komprimiert.

 

[amorph]

Darf ich fragen wie man den Cache verwaltet? Ich nehme an der Cache ist Ram? Mach hier auch eine zusätzliche SSD Sinn?

Was die Hardware betrifft so habe ich die Wahl zwischen 2 Systemen. Eines besteht aus einem ASRock C2750D4I mit 32GB Ram auf dem FreeNAS baremetal, also direkt laufen soll. Oder ich lasse es auf meinem ESXi-Server (2 x XEON E5 2680 EP, 64GB Ram) in einer VM laufen und reiche den SATA-Controller (M1015) direkt in die VM durch. Hängt auch ein wenig davon ab ob die ASRock C2750D4I-Variante performant genug ist.

 

[Morpheus2200]

Die meisten ZFS filer werden per default ein bisschen RAM für das OS reservieren und den Rest für ZFS nutzen. Den Cache verwaltet man also am besten indem man einfach mehr Ram reinstopft.
Nexenta empfielt meine ich minimal 1GB RAM fürs System plus 1GB pro TB Speicher 2GB/TB Speicher mit dedup. Je mehr destso besser zumindest bis 512GB.

Bei den Filern die ich hier habe habe ich auf SSDs verzichtet und lieber auf mehr RAM gesetzt. 128 und 256GB.
Du kannst SSDs als Cache einsetzen aber das lohnt sich halt nur dann wenn die SSD(s) eine bessere read performance abliefern als dein Storage Pool. Eigentlich nur empfehlenswert wenn du genau weisst das die ständig genutzten Daten die du gern cachen möchtest nicht in den RAM Cache passen aber mit SSDs genau die Kapazität da wäre.
Man kann auch wieder Stripes oder striped Mirrors aus SSDs bauen um eine gute Cache performance zu erzielen.

ZFS kennt mehrere Arten von Cache ARC (Adaptive Replacement Cache) L2ARC und ZIL
Der RAM wird automatisch als ARC genutzt. SSDs kann man als L2ARC einsetzen also Level2 ARC Cache der eben langsamer aber größer als der RAM ist.
ARC und L2ARC cachen also die zuletzt abgerufenen Inhalte deines Storage Pools.
ZIL ist eigentlich nur für Synchrones schreiben relevant. Da macht auch keine 0815 SSD mehr Sinn, da gibt es Speziallösungen mit hohem Durchsatz und geringer Latenz wie Zeus RAM und ähnliches und da wird es teuer. Auch hier muss das cache device allein eine bessere performance liefern als der gesammte Storage Pool.
Wobei auch mainstream oder Enterprise SSDs in letzter Zeit kräftig zugelegt haben, keine Ahnung ob sich da was lohnendes und kompatibles findet.

Zur Virtualisierung kann ich wenig sagen, hab es nie probiert. Kann mir aber nicht vorstellen das man damit die performanteste Lösung hinbekommt. Gibt aber sicher hier im Forum Nutzer die damit ihre Erfahrungen haben.

Ich würde es an deiner Stelle erstmal mit dem kleinen ASROCK Board testen. Wobei mir die Anbindung der Controller und NICs mehr Sorgen bereiten würde als die CPU Leistung. Cache hit rates kann man sich dann im Betrieb auch mal ansehen und erstmal Erfahrungen sammeln wie gut man für den individuellen Einsatzzweck mit dem vorhandenen Cache auskommt.

Ich hoffe ich habe zu den Caching Mechanismen alles korrekt wiedergegeben. Ich sehe mich eher als ZFS Anwender mit ein paar Erfahrungswerten aus der Praxis, nicht als Profi. Da gibt es sicher Leute die sich tiefer mit der Materie beschäftigt haben. Die Filer die ich hier betreibe habe ich nach meinen Anforderungen von Leuten mit mehr Praxiserfahrung zusammenstellen lassen und nicht selbst gebastelt. Daher kann ich dir zur Hardwareauswahl nicht viel sagen. Außer das ZFS auf Dual Xeon Servern mit ordentlich RAM und kompatiblen SAS controllern für meine einsatzzwecke eine tolle performance liefert. Und das die CPUs der Kisten hier nicht viel zu tun bekommen. 1-5% CPU last sind normal. Die Dual Xeons haben wir damals nur genommen weil man da günstig viel RAM reinstopfen konnte. Ein großer ARC erschien mir sinvoller als fast das gleiche Geld für einen L2ARC rauszuwerfen.

 

[ichbaum]

Hi,

ich hatte beim Scrub einen Error in einer Datei.
Da diese Unwichtig war, habe ich diese gelöscht. Scheinbar ist aber immer noch ein Fehler vorhanden.
Ein erneutes scrub hat keine Fehler gefunden, listet aber trotzdem einen Error auf.(!?)

scan: scrub repaired 0 in 17h47m with 0 errors on...
...
errors: Permanent errors have been detected in the following files:
tank1/video:<0x77f5>

Hier habe ich gelesen, dass ein Objekt nicht zugeordent werden konnte, wenn diese Meldung erscheint.
Repairing Damaged Data - Oracle Solaris ZFS Administration Guide

Wie werde ich das los, ohne den ganzen Pool neu auf zu bauen?

 

[gea]

Es gibt verschiedene Methoden, behobene Fehlermeldungen zu löschen.
In diesem Fall reicht vermutlich ein erneutes Scrubbing

Ansonsten
zpool clear poolname
Offline + Online (z.B. pool export/import oder reboot)

 

[TCM]

...

Rein interessehalber: hat die Kiste ECC-RAM?

 

[ichbaum]

Rein interessehalber: hat die Kiste ECC-RAM?

Nein, es ist kein ECC drinn.

Ein zpool clear tank1 und darauf ein weiteres scrub hat den Fehler jetzt gelöscht.
Jetzt bekomme ich keine ständigen Warningmails mehr.

 

[Digi-Quick]

Nein, es ist kein ECC drinn.

Und nun dürfen wir Seitenlang spekulieren, ob der Fehler durch den NICHT-ECC Ram entstanden ist
*scnr*

 

[Bzzz]

Is relativ egal, ich hab auch so nen dubiosen Error, der zudem nicht dauerhaft wegzukriegen ist...manchmal kommt der Mist nach nem Scrub einfach wieder. Und bei mir ist seit Anbeginn ECC verbaut.

 

[fesh]

Mein HP N54L (8GB ECC-RAM) läuft seit 2 Wochen mit 6 Seagate St3000DM001 (3TB) als raidz2 (18TB brutto, 12TB netto) unter FreeNAS 9.3 stable.

Habe versucht, bei allen 6 Platten HDD Standby auf "10 Minuten" zu stellen, und das Advanced Power Management auf "Level 1: Minimum Power Usage with Standby (spindown)".
Daraufhin konnte ich hören, dass nach ca. 40 Sekunden Idle eine (oder mehrere?) Platte runterfuhr, und ca. 15 Sekunden später wieder anlief. Und dasselbe nochmal. und nochmal. Jede Minute ging(en) die Platte schlafen und wachte sofort wieder auf. Eventuell waren das auch alle gleichzeitig, das weiß ich jetzt nicht so genau - der N54L steht hinterm Sofa unter einer Steinplatte und ich komme nicht dran ohne das Sofa wegzuschieben...
Nach 2 Stunden war mir das dauernde runter- und wieder rauffahren zu dumm und ich habe wieder "Always On" eingestellt.


Fragen:
1) Könnte das daran liegen, dass FreeNAS andauernd was ins Logfile schreiben will, und dieses Log eben auch auf den Platten liegt?
2) Wenn ja, kann man das Log irgendwo anders hinlegen?
3) Wenn ja, wie und wohin? Auf den Boot-USB-Stick oder eine RAM-Disk (gibt's sowas für FreeNAS?) oder evtl. eine per USB angeschlossene Notebook-Platte?
Die 6 SATA-Ports sind ja alle mit den Datenplatten belegt. Ich habe hier noch 'ne alte 120er OCZ SSD, die könnte ich in ein USB-Notebookplattengehäuse stecken...

4) Wenn's nicht am Logfile liegt - mit welchen Einstellungen kriegt man die 6 Datenplatten dazu, dass sie runterfahren (spindown) und auch schlafend bleiben bis wirklich ein Datenzugriff erfordert dass sie anlaufen?

 

[5chund]

Falls hier noch jemand ZoL unter Debian 7 mit dem Standardkernel der Distribution (3.2) auf einem Supermicro X9SRL-F einsetzt:

Ich hatte am Wochenende nach dem Anschließen zweier WDC WD30EZRX-00D8PB0 an die SCU-Ports reproduzierbare Fehler für beide Platten mit diesem Befehl:

dd if=/dev/zero of=/dev/sde bs=1M count=40000 skip=1000000

Jan 17 20:00:44 box kernel: [  367.854895] sd 0:0:2:0: timing out command, waited 180s
Jan 17 20:00:44 box kernel: [  367.854958] sd 0:0:2:0: [sde] Unhandled error code
Jan 17 20:00:44 box kernel: [  367.854959] sd 0:0:2:0: [sde]  Result: hostbyte=DID_OK driverbyte=DRIVER_OK
Jan 17 20:00:44 box kernel: [  367.854961] sd 0:0:2:0: [sde] CDB: Write(10): 2a 00 00 00 64 00 00 04 00 00
Jan 17 20:00:44 box kernel: [  367.854966] end_request: I/O error, dev sde, sector 25600
Jan 17 20:00:44 box kernel: [  367.855020] Buffer I/O error on device sde, logical block 3200
Jan 17 20:00:44 box kernel: [  367.855074] lost page write due to I/O error on sde
[...]

An den Nicht-SCU 6G Ports haben beide Platten mit dem gleichen Befehl keine Fehler produziert. Die SATA-Kabel waren auch beide neu. SMART-Werte waren absolut in Ordnung.
Letztendlich konnte ich es auf den Kernel eingrenzen, da es mit einem grml-Linux (Kernel 3.13) auch an den SCU-Ports funktioniert hat.
Mein Verdacht wurde grob vom Intel-SCU-Linux-Support bestätigt.
Hier der Wortlaut:

We don't recommend running any kernel older than 3.8 for the C600 controller as that is when the Product Version of the driver starts. There is no way to tell which exact commit fixed this issue since 3.2. There are driver changes, libsas changes, libata changes. If you really need to chase it down, feel free to use git bisect.

Nach Installieren des Backports-Kernels (3.16) war auch unter Debian 7 alles fehlerfrei.

 

[gea]

Entfernen eines vdev aus einem ZFS Pool:

Hätte ich schon öfter gerne gehabt und es scheint so dass es in Illumos/OmniOS und dann sicher auch in BSD/ZoL kommt: OpenZFS Device Removal

 

[CommanderBond]

Habe versucht, bei allen 6 Platten HDD Standby auf "10 Minuten" zu stellen,

Mal unabhängig von deinem Problem damit würde ich sie so oder so net auf 10 Minuten stellen. Dann sind sie ja wirklich ständig am hoch und runterfahren wenn du grad mal 10 Minuten keinen Zugriff drauf hast. Habe es bei mir auf 2h stehen. Wenn du es damit übertreibst wird die Platte auch schneller altern und schneller hinüber sein. Ergo hat man dann nix bei gewonnen. Außerdem ist diese Zeit die man warten muss bis sie wieder hochgefahren sind mitunter recht nervig, auch aus dem Grund würde ich es etwas höher stellen damit dieser Fall (zugriff und platten sind aus) net ständig vorkommt.

Kommt aber auch auf die Anwendung an. Wenn da nur Filme drauf sind kann man den Wert eher niedrig halten. Ist es nen Pool zum Arbeiten "Eigene Dateien" usw würde ich es eher etwas höher wählen.

 

[fesh]

Da sind wirklich nur Filme drauf. D.h. Zugriff gibt es nur abends wenn ein Film angeschaut wird, und 2-3mal die Woche wenn ich neue EyeTV-Aufnahmen fertig geschnitten habe und auf das NAS kopiere.
"Eigene Dateien" gibt es am NAS nicht - meine Macs machen ihr TimeMachine-Backup jeweils auf lokale USB-Platten sowie eine weitere "Netzwerkplatte" (direkt an den Airport-Extreme-Router angeschlossene USB-Platte).

Also, das (Film-) FreeNAS soll schlafen, wann immer es geht. Die 10 Minuten sind genau richtig - wenn man abends zwischen dem ersten und dem zweiten Film sich was zu trinken holt und die alten Getränke wegbringt (WC) wären 5 Minuten manchmal zu knapp...


Habe eine Antwort im FreeNAS.org-Forum erhalten:
• FreeNAS nutzt ein System-Dataset (.system), das standardmäßig auf dem ersten Pool abgelegt wird.
* *Dort werden alle Logs, sowie weitere systemrelevante Dateien wie die Sambadatenbank abgelegt, und es findet ein relativ dauerhafter Zugriff statt.
• Das System-Datenset kann man in den Einstellungen verschieben.
• USB geht, es muss ein ZFS Pool vorhanden sein. RAM Disk wäre keine so gute Idee, da auch Crashlogs etc dort abgelegt werden.

 

[zos]

Im Zusammenhang mit der Nutzung von Datenbanken (hier mySQL) und ZFS-Datasets bin ich auf die folgenden beiden Blog-Einträge aufmerksam geworden, die ggf auch für andere interessant sein könnten:

- mySQL on ZFS
- primarycache all vs. metadata

Besonders der letzte Link zeigt deutlich, wie negativ die Auswirkungen sein können, wenn primarycache=metadata gesetzt wird.

 

[VivianMeally]

Guten Tag,
welche möglichkeiten gibt es ein ZVOL auf ein nicht zfs system zu sichern?

Ich möchte gerne ein paar zvols zu backupen. Habe aber keine tutorial gefunden wie das gehen soll.

 

[gea]

Am Einfachsten per zfs send auf eine Datei.
http://128bitstudios.com/2010/07/23/fun-with-zfs-send-and-receive/

Wenn man sowas aber häufiger braucht, ist es einfacher ein LU Blockdevice nicht auf einem Zvol anzulegen sondern gleich auf einer einfachen Datei. Die kann man dann ohne Umwege direkt wegsichern.

Ganz am Einfachsten und Schnellsten (geht incrementell im Minutenabstand als Replikation) wäre natürlich ein Backup per zfs send auf ein anderes ZFS System.