`: ohne Sync, kein Log
#### Todsünden
> **HW RAID Controller nutzen und mehrere LUNs als Raid VDEVs nutzen** Datenverust, kein Smart, keine Metriken
> **Single VDEV Raid z. B. auf Hardware Raid oder iSCSI/FC SAN**
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
>
> **Deduplizierung aktivieren**
kann nicht mehr ausgeschaltet werden, ggf. in neueren ZFS Versionen optimiert
>
> **ZFS\_ARC zu klein / zu groß**
schlechte Leistung, bei Cache und LOG mehr ARC notwendig
>
> **Pool über 80% Füllstand**
Leistungseinschränkung bis Stillstand bei ca 96%
>
> **Snapshot Bereinigung / Management aus dem Blick verlieren**
führt ggf. unbeobachtet zu vollem Raid
>
> **Snapshots auf Backups**
völlig kontraproduktiv, führt zu sehr vollem Raid
>
> **Anfügesnapshot durch schlechtes Management verlieren**
>
Replikation benötigt neuen Platz und Zeit
> **Druckbetankung**
dafür ist ZFS nicht gemacht, was mehr kann, braucht auch mehr Leistung
>
> **PVE auf selbem RAID wie Systeme (OS auf Datenpool)**
Last auf VMs führt im Härtefall bis zum Kernelcrash
>
> **Kein ECC RAM**
Datenbeschädigung die nicht in jedem Fall durch Scrub und Resilver behoben werden kann (selten)
>
> **Proxmox Datastore auf ZFS Dataset Directory setzen**
Proxmox erstellt eventuell beim Booten den Ordner selbst und ZFS kann dann nicht mounten, Rollback setzt alle virtuellen Disks im Dataset zurück
>
> **Platzangaben vertrauen**
Recordsizes, Volblocksizes, Compressions, Special Devices und Co. machen eine Vorhersage fast unmöglich und rechtfertigen Thin Provisioning
>
> **zpool upgrade zu früh oder zu spät**
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!
>
> **Festplatte ersetzen bei Proxmox ZFS Boot Systemen**
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.
>
> **iSCSI LUNs mit Proxmox**
nicht empfehlenswert, bestenfalls mit dem Free-/TrueNAS Plugin. Wie lange das supportet ist weiss keiner.
>
> **Import Proxmox Pool in Recovery Umgebung**
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
>
> **Billige USB Adapter und Gehäuse**
Manche Adapter haben alle die gleiche Kennung, daher ggf. Raid erstellen und importieren über zpool import /dev/disk/by-path oder by-partuuid
>
> **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 **1.11G** 15.2T 81.4K -
rpool/8k **1.49G** 15.2T 81.4K -
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
**raidz1**-0 ONLINE 0 0 0
scsi-201000000000000005cd2e475ae4b5651-part3 ONLINE 0 0 0
scsi-201000000000000005cd2e4f1bd4e5651-part3 ONLINE 0 0 0
scsi-201000000000000005cd2e4ef8f4b5651-part3 ONLINE 0 0 0
scsi-201000000000000005cd2e4889d4b5651-part3 ONLINE 0 0 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
# ZFS Import - Importieren von ZPOOLS
Bei (Neu-)Installationen oder anderen Startproblemen z.B. von Proxmox ist es teilweise nötig, den *ZPOOL* manuell zu importieren (siehe auch [Proxmox Startproblem](https://wiki.cloudistboese.de/doku.php?id=atknowhow:ato_opensource:ato_1proxmox#prox_bootproblem "atknowhow:ato_opensource:ato_1proxmox")).
Prüfen, ob es *zpools* gibt
```
zpool import
```
Importieren der *zpools*
```
zpool import -fa #Optionen -f force, -a all.
```
Die häufigste Ursache ist gerade bei mehreren internen Festplatten die Verzögerung.
Abhilfe schafft das Anpassen des mit einem Delay im *Grub-Loader*
```
nano /etc/default/grub
```
In dieser Konfigdatei wird folgende Zeile ergänz mit *rootdelay=10* ( = 10 Sekunden Verzögerung)
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=10"
```
**Wichtig:** Danach immer GRUB aktualisieren mit
```
update-grub
```
bzw.
-
` update-grub ` *Aktualisierung der Grub Loaders*
-
` grub-install /dev/sdb ` *Installation des Grub Loaders auf weiteres Laufwerk (hier sdb)*
-
`update-initramfs -u ` *Aktualisiert die Grub-Infos auf diesen HDs*
| SOURCE-Wert | Beschreibung |
|---|
| `default` | Dieser Eigenschaftswert wurde für dieses Dataset bzw. seine übergeordneten Datasets nie explizit gesetzt. Es wird der Standardwert für diese Eigenschaft verwendet. |
| `inherited`from *Dataset-Name* | Dieser Eigenschaftswert wurde vom übergeordneten Dataset geerbt, das in *dataset-name* angegeben ist. |
| `local` | Dieser Eigenschaftswert wurde mithilfe von `zfs set` für dieses Dataset explizit gesetzt. |
| `temporary` | Eigenschaftswert wurde mithilfe von `zfs mount - o` gesetzt und gilt nur solange, wie das Dateisystem eingehängt ist. Weitere Informationen zu temporären Eigenschaften von Einhängepunkten finden Sie unter [Verwenden temporärer Einhängepunkte.](https://docs.oracle.com/cd/E19253-01/820-2313/gamnt/index.html "https://docs.oracle.com/cd/E19253-01/820-2313/gamnt/index.html") |
| - (keiner) | Diese Eigenschaft ist schreibgeschützt. Ihr Wert wird von ZFS bereitgestellt. |
-
`zpool status` zeigt erst mal alle Platten und Datasets
-
Unter */dev/disk/by-id*/ sind die Festplatten per ID aufgelistet
-
`by-id`
-
`ata-` zeigt klassischen S-ATA Platte mit Seriennummer
-
`wwn-` zeigt SAS-Platte (Nummer ebenfalls auf HD zu finden)
-
`usb-` USB Stick oder Festplatte
-
`iscsi-` iSCSI Platte
-
`by-label`
-
zeigt die *rpools* (Daten/rpool/rpool2/System-reserviert) mit Mountpoints
-
`by-partlabel`
-
`zfs-… → ../../sd(n)1` ZFS Symbolic-Links zu der Hauptpartition (1) der Disks sd(n)
-
`by-uuid`
-
zeigt UUIDs für jede einzelne Partition inkl. Mountpoints *sd(nm)*
-
`by-path`
-
gibt Aufschluss über die jeweilige Schnittstellen-Pfad (z.B. `pci-0000:44:00.0-sas-phy3-lun-0`)
-
`lsblk -f` für Mountpoints
-
`ls -althr` zeigt alle HDs mit ID an
-
Voraussetzung: Backups über *zfs-auto-snapshot*
-
`zfs clone rpool/data…/vm--disk-0@…auto-snapshot rpool/data/…/vm--disk-9 `
-
`cfdisk /dev/zd `
-
`mkdir /mnt/restore `
-
`mount /dev/zdp3 /mnt/restore/`
-
`ls /mnt/restore/ ` zum Kontrollieren und Auslesen der alten Dateien und eigenen Einstellungen
-
`cfdisk /dev/zd `
-
`unmount /mnt/restore `
-
`zfs destroy -r rpool/data/…/vm--disk-9`
-
Übersicht Sharing (Samba, NFS, iSCSI oder SSHFS)
-
NFS Sharing
-
Samba Sharing
-
iSCSI Sharing (unvollständig!)
-
Vergleich SAN Protokolle
-
Vergleich Fileserver Windows, UCS, TrueNAS und Zamba
---
-
**Samba**
-
Schnittstelle zum Anwender
-
Für Filesharing
-
Kompatibel mit allen Betriebsystemen
-
Authentifizierung lokal oder AD
-
Verschlüsselt
-
Kein Routing sinnvoll möglich über NAT
-
**NFS**
-
Schnittstelle zu iX Systemen (Linux, Mac, etc.)
-
Einfachste Konfiguration und Absicherung (/etc/exports)
-
Für Filesharing
-
Schnell
-
Einfach zu Mounten
-
**iSCSI**
-
Komplex
-
Für Blocksharing von u. a. Disks, LVM, ZVOLS
-
Multipath
-
HA+RR etc
-
**SSHFS**
-
Filesharing via SSH
-
Langsam
-
Für ESXi ohne vCenter zur Migration
---
## NFS Sharing
Erzeugen Dataset und Mount unter */rpool/nfsshare*, ideal für *VMs* (raw, vmdk, qcpow2) oder *Files*:
```
zfs create rpool/nfsshare
```
Freigabe der Dateien:
```
zfs set sharenfs=on rpool/nfsshare
```
oder mit Zugriffsrechten aus dem Netz *192.168.11.0/24*:
```
zfs set sharenfs="rw=@192.168.11.0/24" rpool/nfsshare
```
#### Zugriffssteuerung
Vereinfacht für kompletten Share mit
```
chmod oder chown # nach Bedarf
```
Zugriffsteuerung per *Linux PAM* Benutzer mit Editieren der Datei `/etc/exports`
```
# freigabe1 wird für zwei Rechner freigegeben
# notebook darf nur lesen (ro)
# desktop darf lesen und schreiben (rw)
rpool/nfsshare notebook(ro,async) desktop(rw,async)
```
oder kombiniert mit *IPs* oder *Netzwerken*
```
# Freigabe gilt nur für 192.168.1.13, jedoch nur mit Leserechten:
rpool/nfsshare 192.168.1.13(ro,async)
# Freigabe gilt für alle IPs von 192.168.1.1 bis 192.168.1.255, mit Lese-/Schreibrechten:
rpool/nfsshare 192.168.1.0/255.255.255.0(rw,async)
# Freigabe gilt nur für den Rechner mit dem Namen notebook
rpool/nfsshare notebook(ro,async)
```
Bei Leistungsproblemen mit *NFS* kann man ggfs. *sync* deaktivieren mit `zfs set sync=disabled rpool/nfsshare`.
Weitere Infos zu den Risiken gibt es bei [https://jrs-s.net/2019/07/20/zfs-set-syncdisabled/](https://jrs-s.net/2019/07/20/zfs-set-syncdisabled/ "https://jrs-s.net/2019/07/20/zfs-set-syncdisabled/").
#### Mounten von NFS Shares
-
Mount in Proxmox
-
*Datacenter* > *Storage* > Taste *Add* > NFS
-
ID: Mount benennen „myNAS1“
-
Server: IP Adresse des Server
-
Export: Auswahl der NFS Freigabe (taucht auf bei erfolgreicher NFS-Verbindung)
-
VMware per Datastore Dialog
-
HyperV über Erweiterung Windows Funktionen
-
Linux
-
`mkdir /mnt/nfsmount && mount -t nfs 192.168.0.100:/rpool/nfsshare /mnt/nfsshare`
-
oder
-
per fstab
-
`192.168.0.100:/rpool/nfsshare /mnt/nfsshare nfs rw 0 0`
-
wenn der umount mal scheitert:
-
`umount -l /mnt/nfsshare #lazy umount`
---
## Samba Sharing
Erzeugen Dataset und Mount unter */rpool/smbshare*:
```
zfs create rpool/smbshare
```
Freigabe der Dateien:
```
zfs set sharesmb=on rpool/smbshare
chmod 777 /rpool/smbshare
```
#### Zugriffssteuerung
Vereinfachtes Sharing mit
```
smbpasswd -a root # erzeugt Samba Passwort
chmod oder chown # nach Bedarf
```
Detailliertere Zugriffsteuerung mit Editieren der Datei `/etc/samba/smb.conf`
```
[Global]
workgroup = workgroup security = user
map to guest = Bad Password
[homes]
comment = Home
Directories browsable = no
read only = no
create mode = 0777
[smbshare]
path = /rpool/smbshare
public = yes
writeable = yes
comment = smb
share printable = no
guest ok = yes
create mask = 0777
security mask = 0777
directory mask = 0777
force create mode = 0777
directory security mask = 0777
```
Kontrolle der effektiven Config `testparm` (zum Kontrollieren der effektiven Konfiguration)
und Abschluss mit
```
service smbd restart
```
#### Zugriff auf SMB Freigaben
-
Windows: `\\\smbshare`
-
macOS und Linux: `smb:///smbshare`
-
Nötige Erweiterung für Linux-Zugriff
- ```
apt-get install cifs-utils
mkdir /mnt/smbshare
mount -t cifs //ip/smbshare /mnt/smbshare #username=root
```
-
per fstab
-
`ip/smbshare /mnt/smbshare cifs iocharset=utf8 0 0`
---
## iSCSI Sharing
Unvollständig
Erzeugen Dataset und Mount unter */rpool/iscsishare*:
```
zfs create rpool/iscsishare
```
Freigabe der Dateien:
???
#### Zugriffssteuerung
Vereinfachtes Sharing mit
???
Detailliertere Zugriffsteuerung mit Editieren der Datei `/etc/???`
#### Zugriff auf SMB Freigaben
-
Windows:
-
Proxmox:
-
macOS und Linux:
-
Nötige Erweiterung für Linux-Zugriff
- ```
???
```
-
per fstab
-
???
-
**Vorteile NFS**
-
schlank
-
einfach
-
übersichlich bei Fehlersuche
-
schnell
-
**Nachteile NFS**
-
Wenig Funktionen
-
kein Multipath (Gleichzeitiger Zugriff von mehreren Servern)
-
kein Sharing von Volumes
-
keine UUID (eindeutige Identifizierung)
-
**Vorteile iSCSI**
-
Multipath
-
HA
-
Sharing von Volumes
-
Blockgrößen und etliche Paramter
-
Eindeutige Identifizierung
-
Hoher Funktionsumfang
-
**Nachteile iSCSI**
-
aufwendiges Setup
-
schwierige Fehlersuche
-
schlechte Integration PVE
-
**Windows**
-
Natives SMB
-
Kritischer Windows Unterbau
-
Partitionierung notwendig
-
NTFS Probleme
-
Kein ZFS, dafür wenige Wiederherstellungspunkte möglich
-
**Univention**
-
Klassiches, aktuelles Samba
-
Umfangreiches System als Unterbau
-
LVM bei Kapaziätserweiterung notwenidg
-
EXT4
-
Kein ZFS, keine Schattenkopien
-
**TrueNAS**
-
Volle
GUI, ZFS und Replikationen, Monitoring
-
Extra Hardware
-
Läuft direkt auf Hardware, daher schnell
-
**Zamba**
-
Schnelle Bereitstellung per LXC
-
Schlank und schnell, da quasi direkt auf ZFS
-
Schattenkopien so viele man möchte
-
ZFS
GUI via Cockpit, Wiederherstellung via Windows-Explorer
-
Erste Wahl bei Einsatz von Debian oder Proxmox
| ashift | Sektorgröße | Entspricht |
|---|
| 9 | 512 Byte | klassische 512B-Sektoren |
| 10 | 1.024 Byte | 1 KB |
| 11 | 2.048 Byte | 2 KB |
| 12 | 4.096 Byte | **4 KB (Standard heute)** |
| Einsatz | Empfehlung |
|---|
| Heimserver / NAS | **ashift=12** |
| SSD / NVMe | **ashift=12** |
| Unbekannte Hardware | **ashift=12** |
| Alte 512B-Platten | trotzdem **ashift=12** |