Maximale Belegung bei ZFS

[T3CHF4N]

HEY Community!

Mache grade meine ersten Versuche mit ZFS auf einem NAS. Inzwischen habe ich Reservierungen und Quotas vergeben.
Jedoch konnte mir das Internet eine Frage bisher nicht beantworten. Man soll ja die Belegung des Dateisystems unter 80% halten. Aber 80% von was?

Dürfen die DateiSysteme nur bis zu 80% voll sein?

Oder die DateiSysteme nur 80% des ZFS-Pools belegen ?

Oder der ZFS-Pool nur 80% des ZFS-RAIDs ?

Oder das ZFS-RAID nur 80% nur des physikalischen Laufwerks ?

Wo genau ist die 80%-Regel anzuwenden?

 

[Firebl]

Das NAS-Forum dürfte hierfür hilfreicher sein. Hier gibt es ja auch bereits den ZFS-Stammtisch.

 

[T3CHF4N]

Der Stammtisch hat schon 423 Beiträge, vielleicht lohnt sich ein SubForum für Dateisysteme?

 

[gea]

Es passiert nichts schlimmes wenn ein ZFS Pool vollläuft. Die Datei die den Pool zum Überlaufen bringen würde, kann halt nicht mehr geschrieben werden (Pool voll). Eine kleine interne Reservierung sorgt dafür, dass alle Blöcke die ZFS als CoW Dateisystem unbedingt schreiben muss um das Dateisystem konsistent zu halten, auch geschrieben werden können.

Aber
Copy on Write Dateisysteme nehmen keine Änderungen an vorhandenen Daten vor. Eine Änderung von "Haus" in "Maus" ändert nicht ein Byte sondern schreibt immer einen neuen kompletten ZFS Datenblock in recsize oder bei kleinen Dateien in einem Teiler davon, also zwischen 4k und 1M. Dies hat eine erhebliche Fragmentierung zur Folge vor allem wenn der Pool voller wird. Bereits ab 50% Füllrate des Pools sieht man einen Performanceverlust, ab 90% wird der recht massiv. Ausreichend RAM kann den Performanceverlust beim Lesen ausgleichen.

Daher der Rat, den Pool nicht voll machen. In meinem napp-it lege ich automatisch beim Pool anlegen eine Pool Reservierung von 10% an. Alle Dateisysteme sehen dann nur noch 90% der Kapazität.

Jedes Dateisystem kann allen verfügbaren Platz des Pools nutzen. Einschränken kann man den Platz den ein Dateisystem oder ein Nutzer verbrauchen kann mit Quotas. Eine Reservierung garantiert einem Dateisystem oder Nutzer Platz. Dies hat zur Folge dass alle anderen Dateisysteme entsprechend weniger freien Platz sehen. Setzt man die Reservierung auf den Pool selber, sehen alle Dateisysteme die man anlegt entsprechend weniger freien Platz.

 

[T3CHF4N]

Wenn die ZFS-Partition 1000 GB hat und ich einen Pool mit 800 GB Quota anlege dann hat der Pool maximal 80% im Verhältnis zum physischen Speicherplatz.

Dann ist ja auf Pool-Ebene schon dafür gesorgt dass 80% nicht überschritten werden.

Bedeutet das, ich kann einzelne Dateisysteme innerhalb des Pools, über 80% im Verhältnis zum Pool befüllen oder nicht?

Hört sich bisschen doof an aber ich weiss es grade nicht besser auszudrücken 🤨

Beitrag automatisch zusammengeführt: 12.08.2023

Auf welcher Ebene innerhalb der ZFS-Hierarchie muss ich darauf achten 80% (im Verhältnis zum darüberliegenden Element) nicht zu überschreiten??

 

[gea]

Nicht so kompliziert denken.

Ein ZFS Pool ist wie eine Stause, daher der übliche Name tank für einen Testpool. Wenn man den vergrößert z.B. den Damm erhöht, passt mehr Wasser rein wie bei einem vergrößerten ZFS Pool. Dateisysteme sind wie Wasserentnahmestellen bei denen man festlegen kann wieviel Wasser maximal entnommen werden kann (Quota). Eine Reservierung garantiert dass eine Entnahmestelle eine bestimmte Menge Wasser entnehmen kann. Da insgesamt nur eine Höchst-Menge entnommen werden kann bedeutet eine Reservierung dass andere Entnahmestellen entsprechend weniger reservieren/nutzen können. Das Prinzip nennt sich Storage Virtualisierung.

Wenn man also einen Pool mit 1000GB hat (bei ZFS gibts keine Partitionen fester Größe wie bei 'alten' Dateisystemen, der Pool selber ist übrigens auch ein ZFS Dateisystem. Man nutzt den aber am Besten nicht direkt sondern legt darunter Dateisysteme an die Eigenschaften des Pool-Dateisystems erben) so ist das Begrenzen des insgesamt zu nutzenden Platzes über Quotas nicht zielführend. Stattdessen legt man auf das Pool Dateisystem eine Reservierung fres von z.B. 10%=100GB an. Alle Dateisystem die man anschließen auf dem Pool anlegt können dann jeweils/zusammen auf max 900 GB (90%) wachsen. Will man ein einzelnes Dateisystem haben dass nur 100GB max nutzen darf, so legt man darauf eine Quota von 100 GB.

Beitrag automatisch zusammengeführt: 12.08.2023

Der Stammtisch hat schon 423 Beiträge, vielleicht lohnt sich ein SubForum für Dateisysteme?

Wenn man mal die alte "Partitions-Denke" hinter sich gelassen hat, sieht man schnell dass ZFS Datasets (Dateisysteme, Snaps/Bootenvironments und Zvol) was ganz einfaches ist, etwas wo man sich schnell fragt, warum man das nicht immer schon so gemacht hat weil es so genial einfach ist.

 

[T3CHF4N]

... so ist das Begrenzen des insgesamt zu nutzenden Platzes über Quotas nicht zielführend.

Reservierung und Quota ist also nur eine "dynamische Partitionierung". Dann Pool zerstören und neu anlegen, da hätte ich jetzt schon 20% meines Platzes verschenkt.
Zum Glück hab ich gefragt bevor das Ding mit Daten befüllt wurde.

Kann noch jemand was zur Fragmentierung sagen? Ich werde einen Pool haben indem nur Dokumente liegen, also viele kleine Elemente wie html- und css-Dateien.
Da wird voaussichtlich auch viel Bewegung drin sein. Sollte ich mich besser gleich mit den Blockgrössen beschäftigen oder ist die Standardeinstellung erst mal genug?

 

[gea]

Den Begriff Partitionierung würde ich in Zusammenhang von ZFS immer vermeiden. Partitionen ist ein Strukturmerkmal herkömmlicher Platten und Raid Arrays, eher würde ich den Begriff "dynamische Speicherverwaltung" nehmen. Pool neu anlegen muss man dabei nicht. Die Einstellung arbeitet dynamisch.

Fragmentierung ist an sich kein Problem. Performancebremsend sind nur sehr starke Fragmentierungen bei plattenbasierten sehr vollen Pools. Die übliche Methode damit das kein Problem wird ist ausreichend RAM und den Pool wie gesagt nicht ganz voll machen. Als Daumenregel solte man bei Solarisbasierten ZFS Systemen (Original ZFS oder Open-ZFS) 2-4 GB, bei BSD und Linux eher 4-8GB RAM als Minimum haben. Speicher darüber hinaus wird als Schreib-Lesecache benutzt und verbessert die Performance vor allem bei kleinen Dateien und beim Lesen von Metadaten. Dieses "Mehr" kann 4-256GB RAM sein, je nach use case. Auch ein Special vdev Mirror für kleine io kann bei sehr vielen kleinen volatilen Daten die Performance verbessern (z.B. Mailserver)

Die relevante Blockgröße für ZFS ist recsize. Default ist 128k. Ist eine zu schreibende Aktion kleiner so wird dynamisch ein Wert von 4k-64k benutzt. 128k ist ein guter Kompromiss für einen general use Filer. Bei Datenbanken oder VM Storage nimmt man gerne 16k-64k, bei einem Mediafiler eher 1M. Kleinere recsize Werte wie 4k-8k sollte man vermeiden da ZFS dann ineffizient arbeitet. Recsize ist eine Eigenschaft eines Dateisystems und wirkt für neue Schreibaktionen. Kann man jederzeit ändern.

Wenn man noch keine Erfahrung hat, einfach nehmen wie es ist. Sun hat bei der Entwicklung von ZFS ganze Arbeit geleistet. ZFS ist per defaults hoch effizient, mag aber gerne viel RAM vor allem zur Beschleunigung langsamer Pools. Eine NVMe ist auch bei weniger RAM fast genauso schnell wie bei sehr viel RAM.