[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.