# ZFS Optimierung und Todsünden

#### ZFS Funktionen für SSDs

<div class="level4" id="bkmrk-zpool-get-autotrim-%3C">- <div class="li">`zpool get autotrim <poolname>`: Auslesen ob „autotrim“ eingeschaltet ist</div>
- <div class="li">`zpool trim <poolname>`: Pool manuell trimmen. Nicht alle SSDs können das, aber die meisten</div>
- <div class="li">`zpool status -t <poolname>`: Auslesen TRIM status</div>
- <div class="li">`zpool set autotrim=on <poolname>`: generell trimmen (autotrim einschalten, wenn manuelles trimmen erfolgreich)</div>
- `zfs set logbias=throughput <dataset/zvol>`: Eventuell bei großen Files spannend
- `zfs set sync=disabled  <dataset/zvol>`: kann Leistung steigern, auf Kosten der Sicherheit
- Es gibt weniger Müll an SAS SSDs als SATA am Markt
- Enterprise SSDs verwenden! 480G, 960G, 1920G, 3840G ....

</div>
#### ZFS mit Spindeln

- Mit mehr disks skalierst die Bandbreite
- Mit mehr vdevs skalierst IOps
- SAS (vollduplex) ist bei gleicher Bandbreite schneller als SATA (Halbduplex)!
- HBA muss den Linkspeed der Disk unterstützen, neuere Disk funktioniert an altem HBA und anders herum, Links Speed kann man u.a. mit lshw auslesen
- SATA Disks können an SAS Controller betrieben werden, anders herum nicht kompatibel

#### U.2 sticht SAS aus

- Viele Mainboards unterstützen SATA, SAS und U.2
- Direkte Anbindung an PCIe Bus, also kein 12G Limit

<div class="level4" id="bkmrk-je-mehr-spindeln-des"></div>#### ZFS mit Cache und oder LOG

- `zpool add cache <poolname> diskxpx`: Eventuell Lesecache auf Boot NVMe vom PVE oder ganze Disk
- `zpool add log <poolname> <strong>mirror</strong> diskxpx  diskxpx`: Eventuell Logdevice auf Boot NVMe**´s** vom PVE oder ganze Disks im **Spiegel plus USV!**
- `zfs set sync=always <poolname>`: ohne Sync, kein Log

<div class="level4" id="bkmrk--1"></div>
#### Todsünden

> **HW RAID Controller nutzen und mehrere LUNs als Raid VDEVs nutzen** Datenverust, kein Smart, keine Metriken

> <div class="li">**Single VDEV Raid z. B. auf Hardware Raid oder iSCSI/FC SAN**</div><div class="li">Bei Beschädigung kann keine weitere Disk die Redundanz, bzw. die Konsistenz bestätigen. Wenn ein VDEV zu viele Fehler liefert, lehnt ZFS es für einen weiteren Import dauerhaft ab!!! Eventuell zpool import -fFX poolname probieren, destruktiv für Rollback auf letzten guten Zustand, sehr riskant  
> </div>

> <div class="li">**Deduplizierung aktivieren**</div><div class="li">kann nicht mehr ausgeschaltet werden, ggf. in neueren ZFS Versionen optimiert  
> </div>

> <div class="li">**ZFS\_ARC zu klein / zu groß** </div><div class="li">schlechte Leistung, bei Cache und LOG mehr ARC notwendig  
> </div>

> <div class="li">**Pool über 80% Füllstand**</div><div class="li">Leistungseinschränkung bis Stillstand bei ca 96%  
> </div>

> <div class="li">**Snapshot Bereinigung / Management aus dem Blick verlieren** </div><div class="li">führt ggf. unbeobachtet zu vollem Raid  
> </div>

> <div class="li">**Snapshots auf Backups**</div><div class="li">völlig kontraproduktiv, führt zu sehr vollem Raid  
> </div>

> <div class="li">**Anfügesnapshot durch schlechtes Management verlieren**  
> </div><div class="li">Replikation benötigt neuen Platz und Zeit</div>

> <div class="li">**Druckbetankung**</div><div class="li">dafür ist ZFS nicht gemacht, was mehr kann, braucht auch mehr Leistung  
> </div>

> <div class="li">**PVE auf selbem RAID wie Systeme (OS auf Datenpool)**</div><div class="li">Last auf VMs führt im Härtefall bis zum Kernelcrash  
> </div>

> <div class="li">**Kein ECC RAM**</div><div class="li">Datenbeschädigung die nicht in jedem Fall durch Scrub und Resilver behoben werden kann (selten)  
> </div>

> <div class="li">**Proxmox Datastore auf ZFS Dataset Directory setzen**</div><div class="li">Proxmox erstellt eventuell beim Booten den Ordner selbst und ZFS kann dann nicht mounten, Rollback setzt alle virtuellen Disks im Dataset zurück  
> </div>

> <div class="li">**Platzangaben vertrauen** </div><div class="li">Recordsizes, Volblocksizes, Compressions, Special Devices und Co. machen eine Vorhersage fast unmöglich und rechtfertigen Thin Provisioning  
> </div>

> <div class="li">**zpool upgrade zu früh oder zu spät**</div><div class="li">pool upgrade erweitert features die ggf. beim aktuellen Proxmox ISO noch nicht verfügbar, jedoch im Upgrade verfügbar sind. Im Recoveryfall kann man nur readonly mounten!  
> </div>

> <div class="li">**Festplatte ersetzen bei Proxmox ZFS Boot Systemen** </div><div class="li">zpool replace sollte nur nach Übernahme der Partitionstabelle einer funktionierenden Disk auf die dritte Partition ausgeführt werden, zusätzlich mit proxmox-boot-tool init/format auf die zweite Partition.  
> </div>

> <div class="li">**iSCSI LUNs mit Proxmox**</div><div class="li">nicht empfehlenswert, bestenfalls mit dem Free-/TrueNAS Plugin. Wie lange das supportet ist weiss keiner.  
> </div>

> <div class="li">**Import Proxmox Pool in Recovery Umgebung**</div><div class="li">Achtung Eigentümer des Pools ändert sich, daher zpool import -fa benutzen, beim nächsten boot wieder zpool import -fa und exit, /etc/pve ist in Recoveryumgebung nicht vorhande, da aus FUSE generiert  
> </div>

> <div class="li">**Billige USB Adapter und Gehäuse**</div><div class="li">Manche Adapter haben alle die gleiche Kennung, daher ggf. Raid erstellen und importieren über zpool import /dev/disk/by-path oder by-partuuid  
> </div>

> **Raid ohne dryrun erweitern**   
> 'zpool add **-n** rpool **mirror** sdc3 sdd3' wäre korrekt, wobei es tödlich wäre hier das wort mirror zu vergessen

> **Konsumer SSDs für Cache und LOG**  
> Waren im Dauerbetrieb schon nach weniger als zwei Jahren am Limit, währen Enterprise SSDs nach 9 Jahren erst bei 30% waren. Getestet mit Samsung Consumer und Intel Enterprise

> **VMs nicht trimmen**  
> Discard in VMs gibt mit SSD Emulation freie Blöcke an ZFS zurück, ansonsten sehr viel Platz verschenkt!

> **Startsektor der Partition nicht oktal** Manche Festplatten starten ab Block 34, manche auf Block 2048. Bei Startblock 34 sollte die erste Partition bis Block 2047 gehen, damit die nächste Partition direkt bei 2048 anfängt

> **Alles auf einmal machen**  
> Betrieb, Scrub, Trim Backup und Replikation treiben die Load in die Höhe, nach fest kommt ab:)

> **Nur auf ZFS vertrauen**  
> Auch wenn wir nun weit über 15 Jahre ZFS produktiv fahren, machen wir immer zusätzlich Replikate und Backups. Nur so kann wirklich nichts mehr passieren. Replikate bei denen die VM zum Snapshotten heruntergefahren wurde, dürften die absolut beste Sicherung sein und immer die erste Wahl bei Problemen

### Update 2024 zum Thema Volblocksize

\# zfs create -o volblocksize=8k rpool/8k -V 1G

\#Warning: volblocksize (8192) is less than the default minimum block size (16384).To reduce wasted space a volblocksize of 16384 is recommended.

rpool/16k <span class="Apple-converted-space"> </span>**1.11G**<span class="Apple-converted-space"> </span>15.2T<span class="Apple-converted-space"> </span>81.4K<span class="Apple-converted-space"> </span>-  
rpool/8k<span class="Apple-converted-space"> </span>**1.49G**<span class="Apple-converted-space"> </span>15.2T<span class="Apple-converted-space"> </span>81.4K<span class="Apple-converted-space"> </span>-

NAME<span class="Apple-converted-space"> </span>STATE <span class="Apple-converted-space"> </span>READ WRITE CKSUM

rpool <span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0

<span class="Apple-converted-space"> </span>**raidz1**-0<span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0  
<span class="Apple-converted-space"> </span>scsi-201000000000000005cd2e475ae4b5651-part3<span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0  
<span class="Apple-converted-space"> </span>scsi-201000000000000005cd2e4f1bd4e5651-part3<span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0  
<span class="Apple-converted-space"> </span>scsi-201000000000000005cd2e4ef8f4b5651-part3<span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0  
<span class="Apple-converted-space"> </span>scsi-201000000000000005cd2e4889d4b5651-part3<span class="Apple-converted-space"> </span>ONLINE <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0 <span class="Apple-converted-space"> </span>0

Bei RaidZ2 wäre der Overhead über 200%

Inzwischen warnt ZFS, jedoch sieht das keine in der PVE GUI!

**Emfpehlung Volblocksize für ZVOLs**

Raid 1 / 10 8-16k

Raid5(Z1) 16k

Raid6+(Z2-3) 32k

**Empfehlung Recordsize für Datasets**

LXC 128k

Mailarchiv 16k

Proxmox Backup Server 1024k