[Sammelthread] ZFS Stammtisch

[gea]

Das Menü macht kein einfaches zfs list sondern wertet für Dateisysteme iSCSI, rsync, s3, acl und weiteres mit aus. Das ist was dauert

 

[kandamir]

So, mal noch eine kurze Rückmeldung. Ich habe am Wochenende den Server noch einmal komplett herunter, um die SATA-Anschlüsse zu prüfen. Mit der Folge, dass danach keine einzige VM mehr starten wollte (es konnte keine Verbindung zur VM aufgebaut werden). Ich habe Stunden damit verbracht, das zu analysieren. Ich war schon kurz davor, ESXi neu zu installieren. Letzter Versuch nach zweimaligem Ausschalten + Server stromlos machen - und die VMs starteten wieder einwandfrei. Und was soll ich sagen: seither ist der Zugriff auf die Pool-Übersicht oder die Filesysteme wieder in ordentlicher Zeit da. Keine Ahnung, was der Kiste quer im Magen lag. Sowas mag ich ja gar nicht, Probleme, die kommen und gehen, ohne dass man erkennen könnte, warum… Napp-It war jedenfalls nicht schuld, sondern offenbar das Blech... 😉

 

[ludwinator]

Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?

 

[kandamir]

Das Übertragen "sonstiger" Snaps kann Probleme machen. Normalerweise erstellt man mit keep und hold auf dem Ziel eine eigene Snapshot retension policy z.B. je Tag 24 snaps, je woche/monat/jahr xx snaps oder behalte letzte 7 Tage oder letzte 20 Snaps.

Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also

Manueller-Snap1
Replikations-Snap (veraltetet) -> wird gelöscht
Manueller-Snap2

Sorry für die vielen Fragen…

Beitrag automatisch zusammengeführt: 21.05.2025

Du hastest ja im März schon so komische Effekte nach dem ausschalten denk ich, was ist denn da für ne Hardware drunter?
Also Mainboard, Controller etc?

Will ich nicht ausschließen. Hardware siehe System in meinem Profil - sollte gepflegt sein. 😉

 

[ludwinator]

OK, also bei der Hardware musst du schon mal damit rechnen, das es so komische Effekte gibt.
Elektronik altert einfach.

 

[kandamir]

Das einzige Fehlverhalten, was ich ggf. auf Hardware schieben würde, wäre das im März berichtete nicht herunterfahren wollen der Napp-It VM. Ich denke inzwischen, dass der damalige Datenverlust des Paperless Docker Containers eher ein Docker Problem war (was ich zugegebenermaßen aber noch nicht verstanden habe…).

Ansonsten zur Hardware selbst: ja, nicht mehr die Jüngste, Spinnweben sind aber noch keine dran und weggerostet ist auch noch nix. 😅 Aber vielleicht sollte ich nach 7 Jahren tatsächlich mal über einen Hardware Refresh nachdenken… Ich werde mal ein wenig stöbern…

 

[gea]

Könntest Du darauf bitte noch einmal näher eingehen? „Sonstige“ Snaps sind dann solche Snaps, die nicht vom Replikationsjob erstellt werden? Davon habe ich durchaus einige. Wie spielt das zusammen mit Snaps, die durch einen Autosnap Job erstellt wurden? Szenario wäre ja: Autosnap erstellt häufig und viele Snaps, um versehentlich durchgeführte Veränderungen rückgängig machen zu können. Replikationsjobs für Backup werden hingegen in geringerer Frequenz durchgeführt, als die Autosnap Jobs. Führt das bei Replikationsjobs dann zu Problemen? Und wie ist das dann bei hold/keep in den Replikationsjobs? Wenn nur die letzten x pro Tag/Woche/Monat/Jahr gehalten werden - werden die ältesten dann mit der nächsten Replikation gelöscht? Und was würde mit den Snaps aus dem o.g. Autosnap Job passieren, die ggf. länger leben sollen? Verschwinden die mit dem entfernen eines Replikations-Snaps, der seine Halbwertszeit überschritten hat? Bzw. bleibt die Integrität der Snapshot-Kette dann noch erhalten, wenn ein solcher Snap gelöscht wurde? Also

Recursive Replikation überträgt alle datasets (auch tieferliegende Dateisysteme, Zvols, Snaps). Das kann manchmal Probleme bereiten wenn man nach der Erstreplikation erwas ändert. Replikations Snaps werden nach der Übertragung umbenannt (mit Hinweis auf die Regel um den Snap zu behalten)

Einfach ausprobieren.

 

[gea]

ZFS Anyraid
Status: Projektidee

Idee: ZFS vdev aus Platten unterschiedlicher Kapazität
Zunächst für Mirrors, dann Raid-Z.

Umsetzung: Klarasystems (waren verantwortlich für OpenZFS Fast Dedup)

Ziel: bessere Nutzung der Kapaazität, kleinste Platte bestimmt nicht mehr die vdev-Größe
also was Richtung Echtzeit Unraid oder Synology SHR

Introducing ZFS AnyRaid, Sponsored by Eshtek — HexOS

At the beginning of this year, we made the decision to invest a substantial chunk of capital to support an open source project for which we have great personal interest. ZFS AnyRaid will give users the ability to mix different sized drives in a pool, a highly-requested feature since our la

hexos.com

https://docs.google.com/document/d/1qRzDdaFujXZCeO0ZGVkhuNLWk8kBdjTiedvb0PiHR98/edit?pli=1&tab=t.0

 

[sch4kal]

Hoffentlich wird das *irgendwann* gefixt: https://www.illumos.org/issues/4896

Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.

 

[Luckysh0t]

Das erklärt meine miese Pool Performance unter OmniOS ziemlich gut, während unter TrueNAS Scale 25.04 alles flutscht.

Das habe ich vor ein paar Jahren auch festgestellt, mit einem Freund, als wir OmniOS als Alternative zu Solaris getestet hatten als VM Filer....aber das war wirklich ein graus...

Mittlerweile nutze ich OmniOS als FIler, aber wie schon mein Solaris direkt auf Blech. Allerdings nur mit einem HDD Mirror und Gbit Lan..mit Verschlüsselung. Solaris ist ca. +-20 MB/s schneller.

 

[sch4kal]

Für mich ist OmniOS damit solange raus. Hab aber keine Lust wieder zurück zu Solaris zu gehen. Ich werde solange Truenas Scale nochmal eine Chance geben, auch wenn ich die UI für zu fancy und aufgeblasen finde.

@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?

 

[gea]

Für mich ist OmniOS damit solange raus. Hab aber keine Lust wieder zurück zu Solaris zu gehen. Ich werde solange Truenas Scale nochmal eine Chance geben, auch wenn ich die UI für zu fancy und aufgeblasen finde.

@gea kann man napp-it auch für ein Plain FreeBSD Stable benutzen ?

ja, napp-it cs.
Ich habe allerdings noch kein howto dabei, um Apache zu installieren und zu starten. Man müsste sich an der Proxmox oder OSX Anleitung orientieren oder das Web Frontend auf Windows oder Linux/Proxmox laufen lassen und nur den backend server starten um Free-BSD remote zu managen.

 

[gea]

OpenZFS 2.3.0 für OSX ist jetzt eine Release Edition, kein release candidate mehr

Release zfs-macOS-2.3.0 · openzfsonosx/openzfs-fork

Upstream changelog RAIDZ Expansion (openzfs#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime. Fast Dedup (openzfs#15896): A major performance upgrade...

github.com

OpenZFS 2.3.1 rc8 für Windows hat die meisten Kinderkrankheiten hinter sich

Releases · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.

github.com

 

[Fischje]

Guten Morgen,

ein Medien-ZFS-Raid wo vielleicht max 4 Streams gleichzeitig drüber laufen sollen mit 14 TB SATA Platten. Macht man da ein Striped Mirror oder was in Richtung RAIDZ2 ? Und reicht das so oder muss man da mit SSDs und ARC und L2ARC was machen? Ist eher ein Datengrab, als das darauf Videoschnitt oder sowas betrieben werden soll...

 

[gea]

Einfach ein Z2 machen und für ausreichend RAM sorgen (min 16GB). Vom RAM nutzt OpenZFS dann 50% als Lesecache (Arc), sollte für 4 Streams reichen wenn es nicht gerade 8k streams sind. L2Arc wird kaum was bringen, eher ein special vdev mirror um metadaten zu beschleunigen oder ein recsize von 1M für geringere Fragmentierung und einen read ahead alike Effekt. Den Pool eventuell nicht zu voll machen, das kostet Performance.

 

[Kavendish]

Es folgt gefährliches Halbwissen:
Also ich habe sogar nur 2 MG10ACA20T 20TB Sata stumpf als ZFS-Mirror derzeit, laut Datenblatt schaffen die 268 MiB/s. Das Mirror bringt da bereits ja theoretisch eine Verdoppelung beim Lesen, dann noch der ARC des ZFS. Meine 4K Medien sind encodiert (MakeMKV + Handbrake) und keine reinen UHD-Disk-Backups, heißt deren Bitrate ist auch bereits niedriger, aber sehr deutlich über dem was Netflix und co als 4K-Stream ausliefern.

@gea Wie könnte ich denn lokal einmal unter Proxmox 8.4 die tatsächliche Leseleistung meines ZFS-Mirros benchen?

 

[gea]

@gea Wie könnte ich denn lokal einmal unter Proxmox 8.4 die tatsächliche Leseleistung meines ZFS-Mirros benchen?

nach reboot (arc cache leer):
entweder mit dd ein file nach /dev/null kopieren
dd bs=1M count=256 if=your_file of=/dev/null

oder mit pv
apt install pv
pv file > /dev/null

oder ein benchmarktool installieren

 

[Kavendish]

root@prox1:/tank0/media_root# dd if=/dev/zero of=groesse_4gb.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1.4117 s, 3.0 GB/s
root@prox1:/tank0/media_root# pv groesse_4gb.img > /dev/null
4.00GiB 0:00:01 [3.00GiB/s] [======================================>] 100%

So ungefähr?

Beitrag automatisch zusammengeführt: 05.06.2025

root@prox1:/tank0/media_root# dd if=/dev/zero of=groesse_4gb.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1.4117 s, 3.0 GB/s
root@prox1:/tank0/media_root# pv groesse_4gb.img > /dev/null
4.00GiB 0:00:01 [3.00GiB/s] [======================================>] 100%

So ungefähr?

Hm, da dürfte schon der RAM arbeiten, auch wenn das kurz nach dem Reboot war, oder?

 

[gea]

vor dem Lesetest ein reboot machen, sonst testet man den Arc ram readcache

um mehrere Streams zu testen
mehrere Putty Fenster öffnen und pv parallel starten.
Da hilft dann aber der Lesecache wenn man nicht je Copy ein anderes File nimmt!

 

[H_M_Murdock]

Hallo zusammen,

ich hätte da mal ein TrueNAS Problem:
Auf einem Dell PowerEdge R720xd versuche ich verzweifelt TrueNAS Scale 25.04.0 zum laufen zu bringen.
Den PERC RAID Controller habe ich auf HBA umgeflashed weil ich die HDDs ja direkt im OS "sehen" will.
Im System stecken 10x 4 TB + 2x 500 GB HDDs.

Das sieht im Installer dann wie folgt aus:

Etwas seltsam finde ich ja dass er die Platten zum Großteil als "ddf_raid_member" findet. Der HBA kann aber definitiv kein RAID mehr, das entsprechende Konfigurationsmenü ist nach dem Crossflash nicht mehr da.
Die HDDs ohne Label sind möglicherweise defekt, das sollte für die Installation aber erstmal egal sein.

Installiert bekomme ich es im Prinzip, dabei wähle ich die beiden 500 GB Platten aus. Installation läuft durch, allerdings bootet er die Installation hinterher nicht.
Ich habe es schon mit UEFI und mit BIOS Modus getestet, sowohl installationsseitig als auch UEFI seitig. Im Bootmenü vom Server bietet er mir leider nur das Installationsmedium, eine der 4 TB Platten und die Netzwerkkarte (PXE) an.

Meine Vermutung ist dass er den Bootloader an die falsche Stelle schreibt weil er vermutlich einfach die erste Platte nimmt die er findet (und das sind zwar am HBA, nicht aber im OS die eigentlichen Systemplatten). Wobei er meiner Ansicht nach dann ja trotzdem booten müsste.

Leider habe ich im Moment keinen physischen Zugriff aufs System, sonst wäre meine letzte Idee dass ich mal sämtliche Platten außer den beiden System-HDDs für die Installation vom System trenne.

Habt ihr dazu Ideen, habe ich vielleicht was übersehen? Gibt es eine Möglichkeit dafür zu sorgen dass der Bootloader an der richtigen Stelle landet? Oder funkt mir am Ende der SAS HBA irgendwie mit rein? Das (geführte) Setup ist ja ziemlich spartanisch.

 

[pwnbert]

Imho musst du dem Bios sagen, dass es vom HBA booten soll und dem HBA musst du dann sagen, von welcher HDD er booten soll.
Imho gabs da irgendwo ein Untermenü.. hatte das mit dem Inspur 9207-8i so gemacht, hab dort TrueNAS von ner SSD gebootet, die am Controller gehangen ist, und das ganze als VM in Proxmox, war nicht ganz easy zum konfigurieren.

Nachtrag:
Das gilt natürlich für die "alten" Controller mit diesem eigenen Bios, wie das bei den neuen UEFI Dingern geht, kein Plan.

Wenns aber noch ein PCIe 2.0 Controller ist, dann müsste das so ein SAS2008 sein, da sollte das so gehen wie beschrieben.

 

[LuxSkywalker]

@H_M_Murdock

beim crossflash unbedingt drauf achten das du auch nach der IT-FW das 'BIOS' der Karte auch noch flasht -> mptsas2.rom bei meinen Controllern

ohne das Controller BIOS kannst du davon nicht booten (der entsprechende Punkt im MB BIOS fehlt dann) soweit ich da im Thema bin - ich selber habe nur die IT Firmware bei mir installiert - booten vom Controller ist nicht nötig in meiner Konfig

falls du das schon auf dem Schirm hattest kannst du meinen Post getrost ignorieren 🙊

 

[pwnbert]

beim crossflash unbedingt drauf achten das du auch nach der IT-FW das 'BIOS' der Karte auch noch flasht -> mptsas2.rom bei meinen Controllern

ohne das Controller BIOS kannst du davon nicht booten (der entsprechende Punkt im MB BIOS fehlt dann) soweit ich da im Thema bin - ich selber habe nur die IT Firmware bei mir installiert - booten vom Controller ist nicht nötig in meiner Konfig

Hm, welche Controller hast du? Das bringt mich zum Nachdenken... mir fehlt da nämlich irgendwas bei meinem 9400er.

 

[H_M_Murdock]

beim crossflash unbedingt drauf achten das du auch nach der IT-FW das 'BIOS' der Karte auch noch flasht -> mptsas2.rom bei meinen Controllern

Ich habe sowohl das BIOS als auch das UEFI hinterher geflashed, das geht angeblich parallel.
Während des Bootvorgangs meldet sich der Controller auch und zeigt seine Platten an, also denke ich dass es prinzipiell funktioniert hat.

Imho musst du dem Bios sagen, dass es vom HBA booten soll und dem HBA musst du dann sagen, von welcher HDD er booten soll.

Vom HBA taucht halt immer eine bestimmte HDD im BIOS Boot Menü auf, vermutlich hast du Recht und ich muss echt nochmal schauen ob ich irgendwo ein Menü vom HBA übersehen habe wo ich auswählen kann welche der angeschlossenen Platten zu booten ist.

Ich schaue mir das morgen nochmal an, in die Richtung werde ich mal zuerst suchen. Vielen Dank vorerst für eure Tips.

 

[pwnbert]

Welchen HBA hast denn? Bzw. welcher Chip ist das und so?

Ich bin mir nicht sicher von welcher Gen wir sprechen...

Bei den "ganz alten" (9207-8i bei mir, 2308 Chip glaub ich ist das) hast beim Bootvorgang irgend ne Taste drücken müssen, dann bist ins Bios davon gekommen und dort gabs in einem Untermenü ein Flag dafür zu setzen... War aber virtuell (per Proxmox) nicht so einfach da rein zu kommen (die VM Konfig war da nicht so intuitiv).. baremetal gings einfacher imho.

 

[LuxSkywalker]

Hm, welche Controller hast du? Das bringt mich zum Nachdenken... mir fehlt da nämlich irgendwas bei meinem 9400er.

M1015 - das sind LSI9220-8i

Während des Bootvorgangs meldet sich der Controller auch und zeigt seine Platten an, also denke ich dass es prinzipiell funktioniert hat.

Das passt dann... ohne BIOS siehst du nix vom Controller beim booten. Die Platten tauchen in meinem FreeBSD dann erst im OS auf

 

[pwnbert]

Muss ein alter LSI 2008 Chil sein, noch mit PCIe 2.0, nachdem das 1 Gen älter ist als mein 9207-8i muss der auch noch das "alte" Bios haben, das man beim Bootvorgang "betreten" kann... da drin is das irgendwo im Untermenü, musst bissl suchen, ist etwas versteckt.

 

[H_M_Murdock]

Das ist ein Dell Perc H710P Mini.

Zum umflashen bin ich dieser Anleitung gefolgt: https://fohdeesha.com/docs/H710-D1.html

Das Teil nennt sich nach dem Flash SAS2308_2(D1).

Ich werde morgen nochmal schauen ob ich das Menü vom HBA finde, eigentlich muss es da was geben.

 

[H_M_Murdock]

So jetzt habe ich mich nochmal durch die diversen UEFI Menüs meines Servers gearbeitet, tatsächlich gab es vom SAS Controller noch ein Menü das man mit STRG+C erreicht, dort kann man die Bootreihenfolge einstellen und danach hat es dann auch geklappt:

Jetzt kann ich mich mit der Einrichtung von TrueNAS selbst beschäftigen.

Die Kiste hat leider nur eine CPU und 32 GB RAM verbaut, soll in meiner Testumgebung aber auch vorwiegend für die zentrale Ablage von Dateien wie Doku, ISOs, ggf Backups der Proxmox Hosts und anderem performancetechnisch unkritischem Kram dienen und nicht vorwiegend zum Betrieb von VMs oder dem simultanen Zugriff durch mehrere User.

Die HDDs unterziehe ich jetzt erstmal einem ausführlichen SMART Test da ich davon ausgehen muss dass nicht mehr alle in Ordnung sind.

 

[gea]

Jetzt kann ich mich mit der Einrichtung von TrueNAS selbst beschäftigen.

Die Kiste hat leider nur eine CPU und 32 GB RAM verbaut, soll in meiner Testumgebung aber auch vorwiegend für die zentrale Ablage von Dateien wie Doku, ISOs, ggf Backups der Proxmox Hosts und anderem performancetechnisch unkritischem Kram dienen und nicht vorwiegend zum Betrieb von VMs oder dem simultanen Zugriff durch mehrere User.

Die HDDs unterziehe ich jetzt erstmal einem ausführlichen SMART Test da ich davon ausgehen muss dass nicht mehr alle in Ordnung sind.

Für ein 64bit OS wie Proxmox würde ich 4GB RAM veranschlagen, TrueNAS hätte gern 16GB RAM und wird mit mehr RAM schneller. 20GB RAM sind dann für das OS und SMB NAS weg, bleiben 12GB für weitere VMs, Container und Apps, nicht gerade üppig.

Da Proxmox auch ZFS mitbringt, ist die Alternative einfach da SAMBA und ACL Support (oder das schnellere ksmbd) zu aktivieren um ein always on SMB NAS zu haben. Die SMB Konfiguration z.B. per WinSCP und Putty ist nicht so kompliziert, optional gibt es auch für Proxmox Web-GUI add ons für ZFS, Shares und ACL wie Cockpit oder napp-it cs.

Smart ist gut um schnell den Plattenstatus zu ermitteln. Für einen echten Oberflächentest gibts bessere Tools. Ich nehme da gern WD data lifeguard um einen intensiven Oberflächentest zu machen. Ist auf einem Hirens usb bootstick enthalten. Dauert halt gerne 1-2 Tage pro Platte.

Alternativ einfach unter ZFS mit min. Z2 nutzen. ZFS gibt sicher Bescheid, wenn es Probleme gibt. Alle 2-4 Wochen einen scrub machen um rechtzeitig Probleme zu finden. (Backup wichtiger Daten nicht vergessen)