Gesucht: Einstieg in ZFS

Rakor

Administrator
Teammitglied
Du kannst mit zpool import -R /mnt das Ding direkt beim Import nach /mnt (oder sonstwohin mounten)
 

bananenBrot

Well-Known Member
Nebenbei: hat jemand schon mal Metadaten im ARC gecached (zfs set primarycache=metadata) und irgend eine Performanceverbesserung festgestellt?
Ich habe echt nen Haufen Mini Dateien in meinem Pool und hab das mal angeschaltet um "ls"se und rsyncs zu beschleunigen aber ich konnte bisher nirgends eine Performanceverbesserung feststellen.
 

mr44er

moderater Moderator
Teammitglied
ich konnte bisher nirgends eine Performanceverbesserung feststellen
Kannst du auch nicht, denn default ist primarycache=all, was metadata bereits mit abschmatzt.

WENN, dann musst du none mit metadata vergleichen.

Entsprechend verhält es sich mit secondarycache=all, aber nur wenn man ein cache-device hat.
 

Yamagi

Possessed With Psi Powers
Teammitglied
WENN, dann musst du none mit metadata vergleichen.
primarycache=metadata ist vor allem für VMs interessant. Genauer gesagt für die Datasets oder zvols, auf denen die Images liegen. Da der Gast seinen eigenen Dateisystemcache implementiert und daher die Nutzdaten selbst cacht, ist es für den Host ausreichend, nur die Metdaten im Cache zu halten. Ansonsten würde man Daten doppelt cachen und das ist Verschwendung.
 

mr44er

moderater Moderator
Teammitglied
Genau, man muss den Wechsel von all zu metadata als Entlastung statts Beschleunigung sehen.
 

PMc

Well-Known Member
Nebenbei: hat jemand schon mal Metadaten im ARC gecached (zfs set primarycache=metadata) und irgend eine Performanceverbesserung festgestellt?
Das ist eher für die Abstimmung der Cache-Größe relevant. Der default ist 'all', also metadaten + nutzdaten. 'metadata' läßt die nutzdaten nicht im ARC, und 'none' läßt gar nichts im ARC.

Das hat damit zu tun, dass es nur einen ARC gibt für alle Pools/Datasets/Filesysteme gemeinsam. Und idealerweise sollte ein Cache gerade so groß sein, dass er Platz für die regelmäßig genutzten Daten enthält - und das kann da schwierig werden.

Nehmen wir ein praktisches Beispiel: du hast einen schwung daten die regelmäßig genutzt werden, und die sind normalerweise im ARC. Dann hast du aber auch noch ein Archivlaufwerk mit einer Riesenmenge an Daten, die weder schnell noch oft gebraucht werden. Wenn jetzt der tägliche Backup (oder sowas) über das Archivlaufwerk geht, dann pressiert das ja nicht, aber die kommen trotzdem alle erstmal in den ARC, und quetschen dabei die tatsächlich ständig genutzten Daten raus (und die müssen danach wieder neu reingeladen werden). Um zB sowas zu vermeiden gibt es die 'metadata' Option pro dataset.

*cache='none' wäre die radikalere Variante, aber das kann recht ekelhaft werden: es wird dann wirklich nicht im ARC gespeichert, trotzdem muss alles gelesene erstmal in den ARC, und der Effekt kann dann fallweise sein, dass bei 128K recordsize für einen einzelnen Sektor diese 128K reingeladen werden, gleich wieder weggeschmissen werden, für den nächsten Sektor wieder reingeladen werden usw. - macht also meistens keinen Spass.
 

bananenBrot

Well-Known Member
Ah das wusste ich nicht. Werden bei =all auch Metadaten weggeworfen, wenn neue Daten in den ARC wandern?
Dann wäre =metadata ja doch hier sinnvoll, da es sich nur um ein Archivsystem handelt.

Ich wollte eigentlich noch mit SSDs als Special Device für Metadaten experimentieren aber wenn die Metadaten eh alle im ARC sind sollte das keinen Unterschied machen. (die sind doch alle im ARC, oder? Der Server hat 128GB RAM aber halt auch viele Dateien drauf...)

Edit: Ich sehe gerade:
arc_meta_used 4 67526381736
arc_meta_limit 4 50652380160
arc_meta_max 4 68104972312
Sind das bytes?
 

mr44er

moderater Moderator
Teammitglied
Werden bei =all auch Metadaten weggeworfen, wenn neue Daten in den ARC wandern?
Ja, wäre sonst auch unsinnig.
sysutils/zfs-stats könnte dir beim Testen behilflich sein.

Der Server hat 128GB RAM
Bevor man da SSDs kauft, maximiert man lieber den RAM. Ist oft teurer, bringt aber mehr.
ARC ist der Level1-Cache, weil besser/schneller/höher/weiter...du weißt schon. ;)
L2ARC wäre dann eben die nächstkleinere Baustelle und da nimmt man ssd/nvme.

Kann man machen, wenn man eh schon sowas rumliegen hat, aber prio sollte mehr RAM haben.
 

PMc

Well-Known Member
Ah das wusste ich nicht. Werden bei =all auch Metadaten weggeworfen, wenn neue Daten in den ARC wandern?
Genau das steuert arc_meta_limit. Damit wird nicht festgelegt wieviel metadaten in den ARC hineindürfen (weil ja eh immer alles erstmal in den ARC muss und dann mindestens solange drinbleibt wie es aktiv im Kernel referenziert ist) sondern nur wenns ans rauswerfen geht, was bevorzugt rausgeworfen wird.

arc_meta_limit muss man also vergrößern wenn man sehr viele Verzeichnisse hat und wenigstens die metadatan im cache halten will.
Wenn umgekehrt auf kleinen Systemen der ARC bei einem 'find' mit metadaten überläuft und das System crasht (kann jedenfalls mit FreeBSD Rel <= 12 vorkommen), dann nützt es kaum wenn man arc_meta_limit verkleinert (weil der 'find' die metadaten aktiv referenziert und sie nicht rausgeworfen werden können), sondern dann muss man kern.maxvnodes reduzieren.

jepp.
 
Zuletzt bearbeitet:

PMc

Well-Known Member
Bevor man da SSDs kauft, maximiert man lieber den RAM. Ist oft teurer, bringt aber mehr.
Das stimmt im Grundsatz, kommt aber auf den Usecase an. Wenn ich zB eine Datenbank hab, dann muss die aktive Datenmenge auch ganz in den ARC passen, sonst gibts nur ein reihum-rausgeschubse und keine Performance. (Und wenn ich dafür genug memory hab, dann muss ich eigentlich nicht den ARC nehmen, sondern kann die Datenbank selber cachen lassen, die weiß ja besser was sie braucht).
Wenn soviel memory nicht praktikabel ist, dann ist ein gut abgestimmter L2ARC eine sehr hübsche Variante die u.U. Faktor 10 schneller macht.

Ein Cache will dimensioniert werden - einfach nur ram kaufen soviel ins Board passt ist nicht unbedingt die wirtschaftlichste Lösung, wenn man seine aktive Datenmenge nicht weiß. Für ein normales Enduser-System spielt das alles keine Rolle, aber für einen Server macht es immer noch Sinn, seinen Usecase zu kennen.
 
Oben