[Sammelthread] ZFS Stammtisch

  • wird auf die Platte geschrieben
  • 0,5sek Pause
  • wird auf die Platte geschrieben0,5sek Pause
Ist das Normal?
Das tritt auch mit anderen Testplatten auf.

Ja das ist normal. Bei ZFS gehen die Daten nicht direkt auf den Pool sondern zunächst in den rambasiertem Schreibcache. Unter Solaris und native ZFS sammelt der 5s kleine langsame Writes und schreibt die dann als eine große schnelle Schreibaktion. Unter Open-ZFS ist die Größe des Schreibcaches abhängig vom RAM, per default 10% RAM max 4GB. Ist der Schreibcache halb voll wird der Inhalt auf Platte geschrieben. 0.5s ist sehr kurz und läßt auf wenig RAM schließen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zum Speicher bei ZFS aus zpool list poolname

Zunächst muss man wissen dass ZFS nicht Terabyte sondern Tebibyte anzeigt. Als Hausnummer sind das ca 10% weniger in der Anzeige. Dazu kommt dass ZFS zunächst die "Rohkapazität" aller Platten zeigt, bei 18 x 18,2T also 327T. Da zwei Platten für Redundanz draufgehen bleiben damit ca 290T nutzbar. Für eine kleine interne Reservierung geht noch minimal was ab,

Davon zieht man den belegten Speicher ab und erhält dann den freien Platz sofern nichts durch Snaps geblockt ist oder durch zvols belegt ist.
 
Zum Speicher bei ZFS aus zpool list poolname

Zunächst muss man wissen dass ZFS nicht Terabyte sondern Tebibyte anzeigt. Als Hausnummer sind das ca 10% weniger in der Anzeige. Dazu kommt dass ZFS zunächst die "Rohkapazität" aller Platten zeigt, bei 18 x 18,2T also 327T. Da zwei Platten für Redundanz draufgehen bleiben damit ca 290T nutzbar. Für eine kleine interne Reservierung geht noch minimal was ab,

Davon zieht man den belegten Speicher ab und erhält dann den freien Platz sofern nichts durch Snaps geblockt ist oder durch zvols belegt ist.
Nun, dann mal mit den Angaben, die ich in Dolphin sehe:

Kapazität = 290,8 TB ohne darauf liegende Daten
Summe der darauf liegenden Daten jetzt = 8,5 TB
Kapazität jetzt = 267,9 TB

Selbst mit den von dir genannten 10% lässt es sich einfach nicht erklären!
 
Sicher?
TrueNAS zeigt mir einen ZFS Cache von 7,7GB an. Wenn der Vorgang abgeschlossen ist geht der wieder auf 0.

Was ich aber auch nicht verstehe ist, das dieser Cache "volläuft". Die Übertragungsrate übers Netzwerk beträgt ca. 110MB/s und die Festplatte schafft ca. 240MB/s.
Somit müsste die Platte immer schneller wegschreiben, als neue Daten kommen. 🤔
 
Nun, dann mal mit den Angaben, die ich in Dolphin sehe:

Kapazität = 290,8 TB ohne darauf liegende Daten
Summe der darauf liegenden Daten jetzt = 8,5 TB
Kapazität jetzt = 267,9 TB

Selbst mit den von dir genannten 10% lässt es sich einfach nicht erklären!
Bei 290T - ca 7,5T Daten sollte ca 282T frei sein. Wenn es keine Snaps gibt muss Speicher von etwas anderem belegt sein, z.B. dump oder swap Volumes.
 
Bei 290T - ca 7,5T Daten sollte ca 282T frei sein. Wenn es keine Snaps gibt muss Speicher von etwas anderem belegt sein, z.B. dump oder swap Volumes.
Kannst du mir ein paar Konsolenbefehle nennen, um der Sache auf die Spur zu kommen?
Swaps habe ich beí den OS-Installationen immer abgelehnt.

Der Pfad ist /storage ...
 
Sicher?
TrueNAS zeigt mir einen ZFS Cache von 7,7GB an. Wenn der Vorgang abgeschlossen ist geht der wieder auf 0.

Was ich aber auch nicht verstehe ist, das dieser Cache "volläuft". Die Übertragungsrate übers Netzwerk beträgt ca. 110MB/s und die Festplatte schafft ca. 240MB/s.
Somit müsste die Platte immer schneller wegschreiben, als neue Daten kommen. 🤔

Neben dem RAM-Schreibcache gibt es den RAM-Lesecache. Der ist ca 70%vom freien RAM alsi ca 7GB. Der läuft voll im Lauf der Zeit.

ps
Eine Platte kann unter Laborbedingungen (Daten am Stück außen lesen/schreiben) 240MB/s. Da ZFS die Daten auf dem Pool gleichmäßig verteilt zählt mehr iops. Da sind Platten mit ca 100 iops lausig schlecht. Ich rechne pro Platte eher mit 100 MB/s. Daten gehen aber immer zuerst in den RAM Cache. Kann die Platte dann den Cacheinhalt nicht so schnell wegschreiben wie neue Daten kommen, bremst das, andernfalls hat man volle Performance auch bei kleinen Daten bei denen eine Festplatte ansonst auch mal auf 10 MB/s einbricht.

Beitrag automatisch zusammengeführt:

Kannst du mir ein paar Konsolenbefehle nennen, um der Sache auf die Spur zu kommen?
Swaps habe ich beí den OS-Installationen immer abgelehnt.

Der Pfad ist /storage ...
zfs list -t volume
FreeNAS hat immer automatisch Swaps angelegt, k.A. ob das immer noch so ist
 
@gea
Also ist das alles völlig normal, wenn es mich stören sollte muss ich eben ein anderes System verwenden.

Danke für die genauen Erklärungen 👍
 
Neben dem RAM-Schreibcache gibt es den RAM-Lesecache. Der ist ca 70%vom freien RAM alsi ca 7GB. Der läuft voll im Lauf der Zeit.

ps
Eine Platte kann unter Laborbedingungen (Daten am Stück außen lesen/schreiben) 240MB/s. Da ZFS die Daten auf dem Pool gleichmäßig verteilt zählt mehr iops. Da sind Platten mit ca 100 iops lausig schlecht. Ich rechne pro Platte eher mit 100 MB/s. Daten gehen aber immer zuerst in den RAM Cache. Kann die Platte dann den Cacheinhalt nicht so schnell wegschreiben wie neue Daten kommen, bremst das, andernfalls hat man volle Performance auch bei kleinen Daten bei denen eine Festplatte ansonst auch mal auf 10 MB/s einbricht.


Beitrag automatisch zusammengeführt:


zfs list -t volume
FreeNAS hat immer automatisch Swaps angelegt, k.A. ob das immer noch so ist
"Not datasets available"

Es ist zum Haareraufen!
 
@gea
Also ist das alles völlig normal, wenn es mich stören sollte muss ich eben ein anderes System verwenden.

Danke für die genauen Erklärungen 👍
Warum sollte einen das stören. Ohne den Schreibcache hätte man sehr schlechte Schreibperformance,
Um das zu simulieren einfach mal sync auf always stellen. Dann geht jedes write commit sofort auf Platte.

Write Performance geht dann gerne auf 10MB/s bei einer Platte. Dafür gibt es keinen Datenverlust im Schreibcache.
Beitrag automatisch zusammengeführt:

"Not datasets available"

Es ist zum Haareraufen!

Dann liegt die Differenz zumindest nicht an ZFS. Da ist Nutzkapazität-Snaps-zvols=verfügbar.
Einzig Reservierungen können noch ZFS Platz belegen, https://docs.oracle.com/cd/E38896_01/html/E38889/gazvb.html
 
Um das zu simulieren einfach mal sync auf always stellen. Dann geht jedes write commit sofort auf Platte.

Write Performance geht dann gerne auf 10MB/s bei einer Platte. Dafür gibt es keinen Datenverlust im Schreibcache.
Interessant, werde ich Mal ausprobieren 🤔👍
 
Warum sollte einen das stören. Ohne den Schreibcache hätte man sehr schlechte Schreibperformance,
Um das zu simulieren einfach mal sync auf always stellen. Dann geht jedes write commit sofort auf Platte.

Write Performance geht dann gerne auf 10MB/s bei einer Platte. Dafür gibt es keinen Datenverlust im Schreibcache.
Beitrag automatisch zusammengeführt:



Dann liegt die Differenz zumindest nicht an ZFS. Da ist Nutzkapazität-Snaps-zvols=verfügbar.
Einzig Reservierungen können noch ZFS Platz belegen, https://docs.oracle.com/cd/E38896_01/html/E38889/gazvb.html
Reservierungen habe ich auch keine.

Ich sollte wohl das Storage räumen und neu aufbauen!

Ergänzungsfrage: Ich habe eine Record Size von 4K, kann das die Erklärung sein?
 
Reservierungen habe ich auch keine.

Ich sollte wohl das Storage räumen und neu aufbauen!

Ergänzungsfrage: Ich habe eine Record Size von 4K, kann das die Erklärung sein?

4K!!!!! Warum zum Henker. Das ist vom Speicherbedarf und Performance katastrophal.

Alle ZFS Operationen beziehen sich darauf inkl Prüfsummen und das ist mit so kleinen Blöcken extrem ineffektiv.
Default ist 128k, Gerne geht man auf 512k-1M. Man kann für VMs auch mal auf 32k-64k heruntergehen, niemals auf 4k

ps.
Recsize wirkt bei neuen Writes. Man kann einfach recsize hochsetzen und Daten umkopieren.
4k ist die physical blocksize bei Festplatten, Betriebssystem arbeitet meist mit 8k Blöcken, ZFS mit größeren Blöcken, SSDs mit mehreren MB als Block.
 
Zuletzt bearbeitet:
Hm, dann stelle ich mal auf 128K um .... Frage mich nur, wie ich die bestehenden Daten korrigiere ...
 
Hm, dann stelle ich mal auf 128K um .... Frage mich nur, wie ich die bestehenden Daten korrigiere ...
zfs send | zfs receive oder einfach ein move nach Ändern der recsize

ps
Mich hätte die Performance bei 4k recsize interessiert.
Könnte unterhalb von 1MB/s liegen
 
zfs send | zfs receive oder einfach ein move nach Ändern der recsize

ps
Mich hätte die Performance bei 4k recsize interessiert.
Könnte unterhalb von 1MB/s liegen
Bzgl der Performance kann ich sagen, dass eine USB-Festplatte ohne Einbrüche geleert werden konnte und auch der Download meines Googles Drives mit der VDSL250-Leitung schon seit Tagen bis zum Anschlag läuft (ca. 30 MB / s).
 
D
Bzgl der Performance kann ich sagen, dass eine USB-Festplatte ohne Einbrüche geleert werden konnte und auch der Download meines Googles Drives mit der VDSL250-Leitung schon seit Tagen bis zum Anschlag läuft (ca. 30 MB / s).
Da hilft wohl der ZFS + Plattencache.
Ist aber definitiv ein Fehler recsize=physical HD blocksize zu stellen.
 
D

Da hilft wohl der ZFS + Plattencache.
Ist aber definitiv ein Fehler recsize=physical HD blocksize zu stellen.
Lektion gelernt! Nur das mit dem zfs send / receive kapiere ich nicht ...

Der Storage heißt "storage" und hängt in /storage ... Und dann habe ich eben noch gelesen, dass das nichts bringt bei geänderter Blocksize ... Mir schwirrt der Kopf!
 
zfs send (Replikation)

Recsize wirkt bei Schreiben. Man muss also recsize hochstellen, dann Daten neu schreiben (zfs send oder ein einfaches copy/ move zwischen Dateisystemen tuts auch)
 
Zuletzt bearbeitet:
Und wenn du schon beim umkopieren bist, denk mal drüber nach, ob das Layout mir Z2 und 18 Platten wirklich nötig ist für dich. Ich würde eher nicht über 12 Disks gehn in einem vdev. Außerdem solltest du LZ4 aktivieren, das bringt garantiert mehr als es kostet.
cu
 
Bei ZFS gehen die Daten nicht direkt auf den Pool sondern zunächst in den rambasiertem Schreibcache. Unter Solaris und native ZFS sammelt der 5s kleine langsame Writes und schreibt die dann als eine große schnelle Schreibaktion.
Hier hätte ich noch eine Frage, ich hatte die Tests mit großen Dateien (25GB und mehr) durchgeführt.

Sollten diese nicht in einem Rutsch geschrieben werden? Oder ist das unabhängig von der Dateigröße?
 
Und wenn du schon beim umkopieren bist, denk mal drüber nach, ob das Layout mir Z2 und 18 Platten wirklich nötig ist für dich. Ich würde eher nicht über 12 Disks gehn in einem vdev. Außerdem solltest du LZ4 aktivieren, das bringt garantiert mehr als es kostet.
cu
Die Kompression werde ich in der Tat aktivieren, am Layout an sich ändere ich nichts ... Bin mit 8+1 bei den Paritäts-RAIDs schon seit Jahren gut gefahren ...
 
Hier hätte ich noch eine Frage, ich hatte die Tests mit großen Dateien (25GB und mehr) durchgeführt.

Sollten diese nicht in einem Rutsch geschrieben werden? Oder ist das unabhängig von der Dateigröße?

ZFS schreibt grundsätzlich zuerst in den RAM Schreibcache. Ist der halbvoll geht es in recsize Blöcken (oder bei kleinen Daten in Bruchteilen davon) auf den Pool. Mit LZ4 ist die tatsächliche Blockgröße abhängig von der Komprimierbarkeit. ZFS versucht dabei den Pool gleichmäßig zu füllen. Direkt IO (Schreiben ohne Cache) ist in der Entwicklung. Im ZFS Raid gibt es damit keine echten sequentiellen Transfers. IO Leistung ist damit wichtiger als bei älteren Dateisystemen. Ein single Z2 vdev Plattenpool hat aber nur ca 100 echte iops. Bei mehreren Benutzern oder vielen kleinen Daten ist das sehr wenig.

ps
Neben der geringen io Leistung würde ich wegen der langen Resilverzeit bei einem Plattenausfall 2 x Z2 (sowas wie früher Raid-60, Pool bringt dann 200 iops) oder wenigstens auf Z3 gehen. Für schnelle Sachen gibts ja noch den NVMe Pool.
 
ZFS schreibt grundsätzlich zuerst in den RAM Schreibcache. Ist der halbvoll geht es in recsize Blöcken (oder bei kleinen Daten in Bruchteilen davon) auf den Pool. Mit LZ4 ist die tatsächliche Blockgröße abhängig von der Komprimierbarkeit. ZFS versucht dabei den Pool gleichmäßig zu füllen. Direkt IO (Schreiben ohne Cache) ist in der Entwicklung. Im ZFS Raid gibt es damit keine echten sequentiellen Transfers. IO Leistung ist damit wichtiger als bei älteren Dateisystemen. Ein single Z2 vdev Plattenpool hat aber nur ca 100 echte iops. Bei mehreren Benutzern oder vielen kleinen Daten ist das sehr wenig.

ps
Neben der geringen io Leistung würde ich wegen der langen Resilverzeit bei einem Plattenausfall 2 x Z2 (sowas wie früher Raid-60, Pool bringt dann 200 iops) oder wenigstens auf Z3 gehen. Für schnelle Sachen gibts ja noch den NVMe Pool.
Also wäre aufrüsten auf 32GB RAM sinnvoll?

Zum zweiten Punkt, das ist ein NAS Ersatz, basierend auf einem Odroid H2 bzw. H3. Also sehr klein, energiesparend und nur mit 2 Platten ausrüstbar. Des weiteren mit Offsite Backup auf baugleichen System.
Daher wäre dein Vorschlag ein klein wenig Overkill 😅

Edit: Wahrscheinlich ist es sogar schneller das Offsite Backup auf neue Platten zurückzuspielen als zu resilvern 🤔
 
Zuletzt bearbeitet:
Also wäre aufrüsten auf 32GB RAM sinnvoll?

Bei einer reinen Performance und Effizienzbetrachtung macht ZFS alles falsch. Es fügt an Daten und Metadaten Prüfsummen an und muss damit viel mehr Daten lesen, schreiben und verarbeiten. Da keine Daten auf dem Pool geändert werden sondern wegen Copy on Write immer als neue Blöcke in recsize geschrieben werden, erhöht sich die Datenmenge nochmals beträchtlich. Da Daten über den Pool verteilt werden, gibt es keine echten sequentiellen Transfers sondern viel random io.

Im Gegenzug kann ZFS feststellen ob Daten oder Raid korrekt sind. Bei einem Absturz bei Schreiben bleibt ZFS heile und Copy on Write liefert ganz nebenbei Snaps ohne Overhead. Auch bei vielen Nutzern und vielen kleinen Dateien bleibt die Performance von ZFS recht konstant.

Dass ZFS dennoch sehr schnell ist, liegt neben modernen/schnellen CPUs daran dass fast der komplette RAM als extrem effizienter
Lese-/Schreibcache genutzt wird. Meine Daumenregel lautet:

Ein 64 bit OS mit ZFS braucht etwa 4 GB RAM. Solaris/Illumos etwas weniger da die ZFS Speicherververwaltung noch wie Solaris arbeitet,
BSD und Linux etwas mehr. Dazu kommt noch ein Zuschlag für webbasiertes Management zwischen 512k und 2 GB.

Ca 10% RAM werden als Schreibcache genutzt. Dieser dient ausschließlich dazu kleine Writes z.B. < 128k wann immer möglich zu vermeiden. Da brechen sogar NVMe übel ein.
Ca 70% RAM werden als Lesecache für kleine random reads (Metadaten und kleine Daten aus read last/read most). Große Daten/Files werden nicht gecacht.
Falls man rambasiertes realtime Dedup nutzt, kommt dazu bis zu 5 GB RAM je TB deduplizierte Daten (nicht Poolsize).

Bei 32GB kann man also phi x Daumen rechnen
32-6 GB (OS und Web-ui, BSD/Linux)=26GB frei

Schreibcache 2,6GB, nutzbar 1,3 GB für alle User.
Wenn man keine Writes < 128k möchte, könnte man in diesem Fall 10 User je mit ausreichend Schreibcache bedienen

Lesecache wären dann max ca 18GB. Da landen vor allem Metadaten und kleine/letzte Reads.
Mit wenigen Usern und Dateien liefert das eine Cache hitrate von gerne > 80%.
Bei einem Enterprise Mailserver mit vielen Usern und Millionen Dateien wäre das viel zu wenig Cache.

Die oft genannte Regel 1 GB RAM per TB Pool ist Unsinn sondern es kommt darauf an. Gibt Fälle wo 4 GB RAM gerade noch ok sind, manchmal sind 128 GB sinnvoller.
 
Danke für die sehr ausführliche Erklärung 👍
Da das Gerät max. 3 User gleichzeitig hat im Schnitt 1-2 User, sollte der RAM ausreichen.

Soweit ich das verstanden habe 😅
Also erstmal weiter benutzen, die Performance passt ja soweit 👍
 
Bei 32GB kann man also phi x Daumen rechnen
32-6 GB (OS und Web-ui, BSD/Linux)=26GB frei

Schreibcache 2,6GB, nutzbar 1,3 GB für alle User.
Wenn man keine Writes < 128k möchte, könnte man in diesem Fall 10 User je mit ausreichend Schreibcache bedienen

Die oft genannte Regel 1 GB RAM per TB Pool ist Unsinn sondern es kommt darauf an. Gibt Fälle wo 4 GB RAM gerade noch ok sind, manchmal sind 128 GB sinnvoller.

Danke für die ausführliche Erklärung!
Wie spielt jetzt L2ARC und Schreibcache auf einer SSD da rein?
Sollte man L2ARC erst nehmen wenn man nicht mehr RAM ins System bekommt?
 
Ich habe selbst noch keinen Anwendungsfall gefunden, bei dem der L2ARC messbaren Geschwindigkeitsgewinn gebracht hätte.
Das muss wohl an der erstklassigen ARC Implementierung liegen, daher lautet mein Votum: lieber 8GB mehr Ram als 100GB L2ARC.
Nicht zu vergessen: der Index des L2ARC muss im ARC gehalten werden und verringert den "schnelleren" Cache damit.
 
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