[Sammelthread] ZFS Stammtisch

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.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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?
 
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.
 
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"


ps
Es wird ein aktuelles napp-it se web-gui benötigt (wg Perl 5.42)
 
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