[Sammelthread] ZFS Stammtisch

[gea]

Das Problem, vereinfacht:
ZFS schreibt Datenpackete in recsize, egal ob 4K, 128K oder 1M. Das sind immer Zweierpotenzen. So ein Packet muss jetzt auf die Platten verteilt werden, deren kleinste Belegungseinheit 4K ist. Hat man z.B. 128K recsize und 4 Datenplatten (ohne Paritätsbetrachtung), so landet auf jeder Platte 32K, das sind exakt 8 physikalische 4K Blöcke.

Ist die Anzahl der Datenplatten keine Zweierpotenz (2,4,8) so geht das nicht auf. Es werden mehr physikalische Blöcke auf der Platte belegt als eigentlich für das ZFS Packet nötig, also entsteht Verschnitt, z.B. 128K auf 5 Platten bedeutet 25,6K pro Platte, also 6,4 x 4K Blöcke also 7 physikalische Blöcke werden belegt. Das Speichern eines 128K ZFS Packets belegt damit 140K auf den Platten.

Vor Jahren waren diese "golden numbers of disks" in Raid-Z daher allgemeine Empfehlung weil ein Abweichen eine Platzverschwendung zur Folge hatte. Heute ist das egal weil Compress (per default) aktiviert ist. Es gibt damit keine ZFS Datenpackete mehr als Zweierpotenz weil die Daten vor dem Speichern komprimiert werden.

TLDR;
Nehmen was da ist und von der Performance per vdev Sinn macht, Anzahl der Platten unerheblich.

 

[eehm]

Nehmen was da ist und von der Performance per vdev Sinn macht, Anzahl der Platten unerheblich.

Das heißt kleinere recsize wäre besser, weil die Performance dann besser wäre oder ist das durch dein genanntes Compress auch irrelevant geworden?
Und falls nicht, was wäre dann die "ideale" Recsize?

 

[gea]

Hängt von der Anwendung ab, 128K (default) ist ein guter Kompromiss

- kleine Blöcke werden langsamer gelesen/geschrieben als große.
Für große sequentielle Workloads ist 1M daher schneller

- "Overhead"
Hat man eine Datenbank oder Hypervisor der z.B. 4K ändern möchte, so muss dazu bei 1M recsize 1M gelesen und neu geschrieben werden. 16K kann da schneller sein.

 

[gea]

OmniOS 151056 ist verfügbar (Opensource Solaris Fork/Unix)

OmniOS ist eine Illumos Distribution und kompatibel mit OpenZFS: Es gilt als minimalistisches und ultra stabiles ZFS. Liegt mit daran dass Illumos neue ZFS Features sehr zögerlich und erst nach eigenen Tests integriert. Die Probleme die OpenZFS im letzten Jahr hatte, gibt es bei Illumos nicht, neueste Features wie Raid-Z Erweiterung fehlen halt.

"Note that r151052 is now end-of-life. You should upgrade to r151054 or r151056 to stay on a supported track. r151054 is a long-term-supported (LTS) release with support until May 2028. Note that upgrading directly from r151052 to r151056 is not supported; you will need to update to r151054 along the way"

Release Notes

illumos based server OS with ZFS, Bhyve, DTrace, Crossbow, SMF and Linux zone support

omnios.org

ps
Es wird ein aktuelles napp-it se web-gui benötigt (wg Perl 5.42)

 

[asm@s24]

Hat man eine Datenbank oder Hypervisor der z.B. 4K ändern möchte, so muss dazu bei 1M recsize 1M gelesen und neu geschrieben werden. 16K kann da schneller sein.

Ist das nicht eher umgekehrt? Praktisch alle Medien haben doch ein Problem mit small random I/O.
Lassen sich also 1M records nicht tendenziell schneller verarbeiten?

Aber selbst wenn nicht... mit 1M records hat man viel mehr Möglichkeiten, mit den special small blocks zu spielen.

 

[gea]

Die Frage ist doch
Wenn man z.B. einen Datenblock mit 64K ändern möchte und dazu 64K lesen und schreiben muss, ist das schneller als 1M zu lesen und zu schreiben. Die Antwort ist ganz eindeutig, 64K ist in dem Fall schneller. Schaut man sich Atto Benchmarks an, so sieht man dass erst unterhalb von 32K die Performance richtig übel einbricht.

Natürlich is 1M lesen und schreiben viel schneller als 16 x 64K zu lesen und zu schreiben, daher ist bei großen Dateien 1M besser. Mit Small Blocks kommt man aber auch mit kleineren Recsize gut klar, z.B. recsize =128K default und small blocksize=64K zwingt man alle Dateien bis 64K (alle Office Dateien) auf die special vdev und große Mediadaten auf den hd Pool.

 

[asm@s24]

... zwingt man alle Dateien bis 64K (alle Office Dateien) auf die special vdev...

Das sind bei mir so wenig (13.5G) ... Mit Abstand das meiste steckt in den 1M Blöcken (~14.8T).

 

[gea]

Die small block und recsize Einstellung gilt nur für neue Dateien nicht für bereits gespeicherte. Stellt man z.B. recsize eines Dateisystems auf 1M und small block auf 128K so landen künftig alle Dateien <=128K auf dem special vdev. Stellt man für dieses Dateisystem recsize auch auf 128K so landen alle Dateien auf dem special vdev, egal wie groß.

 

[asm@s24]

Das ist bekannt.
Deshalb hab ich ja den Pool vor dem Füllen auf RecSize 1M eingestellt (und special small auf 256K oder gleich 512K, je nach Dataset). Und mit meinen Daten gefüllt (Pool etwa zur Hälfte) sieht es so aus:

Also ... der mit Abstand größte Teil der Dateien steckt in Blöcken >512K. Natürlich hätt ich den default 128K lassen können; nur ergibt das bei diesen Daten m.E. gar keinen Sinn.

... mit 1M records hat man viel mehr Möglichkeiten, mit den special small blocks zu spielen.

Meine Aussage ist einfach die, daß ich vermute, bei den meisten Leuten sieht es ähnlich aus wie bei mir und daß deshalb RecSize 128K ungünstig ist. Zu klein halt.
Hier eine andere Sicht, Anzahl der Dateien nach Größe:

Links der ganze Pool; das rechte Bild find ich noch sehr aufschlußreich, das sind die Dateien im PBS-Repo (3.7 TB).
Also anders ausgedrückt: wer hat denn heutzutage noch viele kleine Dateien? Ich hab mich bei meinen ersten Pools (mit defaults) gewundert, wieso das nur so wenige GB im special vdev waren. Jetzt (nach der Analyse) weiß ich's. 💡

 

[gea]

Praktisch alle "Office" Dateien sind kleiner 128K, ISO, Images und Mediadaten sind größer. Da kommts auch nicht so auf die Verteilung an sondern darum dass die kleinen Dateien schnell sind (auf Flash). Große Dateien sind meist schnell genug, vor allem im Raid.

Ein weiterer Aspekt ist die Speicherart. Bei Flash kann man mit kleineren Recsize effektiv arbeiten ohne dass die Performance einbricht (außer bei sehr kleinen recsize <32K), bei einem hd Pool ist großes Recsize günstiger. Mit Hybrid Pools und special vdev ist das dann eine runde und flexible Sache.

 

[pwnbert]

Naja, @home sind die Leute halt eher Pr0n Hoarder als .doc Hoarder... was soll man da schon sagen?`

 

[eehm]

Ich habe eine generelle Frage zur Verschlüsselung.
Würdet ihr generell zu Key-Files oder Passphrases raten?
Ist es besser den gesamten Pool zu verschlüsseln oder besser jedes Dataset für sich selbst?
Wie handhabt ihr das aktuell bei euch?

 

[pwnbert]

Ich persönlich würde das im Dataset machen... so ist man flexibler, denke ich?

 

[eehm]

würde das im Dataset machen... so ist man flexibler, denke ich?

OK, das spricht für das Dataset.
Und dann mit Key-Files oder Passphrases?

 

[gea]

Wenn man das Pool Dateisystem nicht verschlüsselt, hat man die Option unverschlüsselter Datasets, wichtig wenn man sync braucht, Das wird mit Verschlüssellung arg langsam.

Ob man Keyfile (passphrase, raw, https optional mit keysplit) oder Prompt nimmt ist zunächst egal, kann man ändern und prompt geht auch wenn keyfile eingestellt ist. Ich würde raw mit nichtdruckbaren Zeichen und Zeichen wie 0OIl vermeiden, Gut sind lange hex Werte, kann man drucken und per mail verschicken.

 

[eehm]

Ich würde raw mit nichtdruckbaren Zeichen und Zeichen wie 0OIl vermeiden, Gut sind lange hex Werte, kann man drucken und per mail verschicken.

Du meinst, weil man den Schlüssel zur Not noch im Email-Postfach hat, wenn etwas brennt oder so?

 

[gea]

Ob jetzt email oder ausgedruckt im Safe ist egal.
Hauptsache man hat den Schlüssel selber irgendwo sicher und mehrfach verfügbar.

Verliert man den Schlüssel sind die Daten futsch
(ok, KI und Rechenleistung nehmen so dramatisch zu dass manche bereits davon ausgehen dass derzeitige Verschlüssellung in vertretbarer Zeit zu knacken ist)

 

[eehm]

Danke, dann hätte ich nur noch eine Sicherheitsfrage zur ZFS Replication über SSH.

Ist für die Sicherheit der SSH-Übertragung der Daten eigentlich das Passwort des verwendeten SSH-Users relevant oder könnte das auch "1234" sein?
Eigentlich denke ich nämlich, dass nur der SSH Public Key für die Sicherheit relevant ist und nicht das Passwort des SSH-Users.

Allerdings verunsichert mich die Konfiguration in TrueNAS Scale schon wieder, weil her beim Konfigurations_Wizard nur nach dem SSH-Passwort des SSH-Users gefragt wird!