[Sammelthread] ZFS Stammtisch

VirtuGuy schrieb:
Zuerst muss man sich festlegen was man überhaupt möchte, Backups oder Snapshots? Ein Snapshot (zfs, lvm, ceph) ist immer an ein Filesystem gefesselt. Snapshots sind also nicht so ohne weiters bewegbar und auch simple Dinge wie Restores auf Filelevel sind nur mit großen Aufwand möglich. PBS hingegen erstellt bewegliche Backups und keine Snapshots. Ohne eine Lösung wie PBS muss man halt auf einen Medienbruch, Live- und Filelevel Restore, Deduplikation,... verzichten.
Zum Vergrößern anklicken....

Nicht ganz.

Snapshots sind readonly Ansichten des ganzen ZFS Dateisystems zum Zeitpunkt der Erstellung. Daraus kann man sehr wohl ein simples Restore einzelner Dateien bewerkstelligen indem man entweder per SMB und Windows "vorherige Version" den Snap durchsucht oder aus dem ZFS Dateisystem aus dem Ordner /"Dateisystem"/.zfs/snapshots wiederherstellt,

Snapshots sind eine perfekte Basis für ein Backup z.B. per zfs send mit dem man ZFS Dateisysteme viel schneller und prüfsummengesichert als mit jeder anderen Methode sichern, wiederherstellen oder syncronisieren kann. Auch kann man mit Snaps sehr viele Versionen einer Datei, einer VM oder eines ZFS Dateisystems z.B. jede viertelstunde, stündlich, töglich, wöchentlich,.. sichern und wiederherstellen.

Echtzeit Deduplikation ist ein ZFS Feature, braucht lediglich ziemlich viel RAM oder ein dedup special vdev für die dedup Tabellen.

Ergo:
Es gibt schlicht kein Backupverfahren das auf "file copy" basiert das annähernd so flexibel und schnell ist wie ZFS basierte Methoden. Bei einem VM Storage hat man nur das Problem konsistenter Gast Dateisysteme. Bei einem simplen Filer würde sich das erübrigen, da nimmt man einfach offene Dateien so wie sie sind, im worst case (Datei wird zum Snapzeitpunkt geschrieben) ist die halt defekt, ZFS bleibt aber immer konsistent.

Selbst Terabyte große Dateisysteme eines Hochlastsystems kann ZFS damit im laufenden Betrieb mit ganz kurzer Verzögerung sichern/syncronisieren.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Kurzu
gea schrieb:
Nicht ganz.

Snapshots sind Ansichten des ganzen ZFS Dateisystems zum Zeitpunkt der Erstellung. Daraus kann man sehr wohl ein simples Restore einzelner Dateien bewerkstelligen indem man entweder per SMB und Windows "vorherige Version" den Snap durchsucht oder aus dem ZFS Dateisystem in Ordner "Dateisystem"/.zfs/snapshots wiederherstellt,
Zum Vergrößern anklicken....

Und was mache ich wenn die Filer VM down ist? Mit Datenbanken? Windows Systemdateien? In Linux/Unix Systemen? Man erreicht mit Snapshots schnell die Grenze wo ich für einen simplen Restore einen Storage Admin brauche und die Aufgabe nicht mehr in die jeweilige Abteilung delegieren kann. :)


gea schrieb:
Snapshots sind eine perfekte Basis für ein Backup z.B. per zfs send mit dem man ZFS Dateisysteme viel schneller als mit jeder anderen Methode sichern, wiederherstellen oder syncronisieren kann. Auch kann man mit Snaps sehr viele Versionen einer VM z.B. jede viertelstunde, stündlich, töglich, wöchentlich,.. sichern.
Zum Vergrößern anklicken....

In dem Moment wo du mal "schnell" eine VM für einen Developer aus einem alten Backup exportieren willst wird es halt mühsam. Auslagern auf Tapes oder Wechseldatenträger ist auch kein Spaß.

Ein schneller Restore ist in der Praxis auch so ein Thema. Im Idealfall gehe ich ich auf den letzten Snapshot zurück und alles ist wieder gut. Aber was ist wenn deinen VM Cluster samt lokalen Storage oder Storage VM´s zerlegt? Bei Veeam/Pbs/Synology/wwi kann die VM´s per Live Restore direkt aus dem Backup Repository starten und ohne Downtime im Hintergrund wiederherstellen. Natürlich kann man auch einen "Backup" Storage Host außerhalb des Clusters betreiben, die Snapshots per Pull abziehen und diese im Notfall stundenlang zurück replizieren. Oder ich stelle diese z.B. per NFS bereit (juhu, Schreibzugriff!), importiere und starte diese von Hand. Der Ablauf ist aber nicht im vorbeigehen erledigt und ich brauche Schreibzugriff auf dein womöglichst letztes "Backup".

Ich skizziere es absichtlich einseitig undüberspitzt. Es sind nunmal Beispiele die man mit Pbs/Veeam/... und einem sauberen Medienbruch besser lösen kann.


gea schrieb:
Echtzeit Deduplikation ist ein ZFS Feature, braucht lediglich ziemlich viel RAM oder ein dedup special vdev für die dedup Tabellen.
Zum Vergrößern anklicken....

Nun, Veeam/PBS brauchen halt kaum Ram und auch keine extra Hardware ;)

gea schrieb:
Ergo:
Es gibt schlicht kein Backupverfahren das auf "file copy" basiert das annähernd so flexibel und schnell ist wie ZFS basierte Methoden. Bei einem VM Storage hat man nur das Problem konsisteter Gast Dateisysteme. Bei einem simplen Filer würde sich das erübrigen, da nimmt man einfach offene Dateien so wie sie sind, im worst case (Datei wird zum Snapzeitpunkt geschrieben) ist die halt defekt, ZFS bleibt aber immer konsistent.

Selbst Terabyte große Dateisysteme eines Hochlastsystems kann ZFS damit im laufenden Betrieb mit ganz kurzer Verzögerung sichern/syncronisieren.
Zum Vergrößern anklicken....

Aber es sind halt trotzdem "nur" Snapshots und die bringen halt auch Nachteile mit sich. Ich kann bei Proxmox ootb mit ein paar Klicks ganze VM´s per Snapshots im 30 Sekunden Takt auf einen anderen Host replizieren, mit Live Migration und und und. Aber wie du schon sagst, ZFS/Ceph/... hat absolut keine Ahnung ob die Daten IN der VM irgendeinen Wert haben. Und wenn nur noch Müll in der VM steckt, der lokale Snapshot und eine etwaige Replikation wird immer ein konsistentes "Backup" melden. Mit Veeam/PBS/wwi kannst du recht einfach Test Restores orchestrieren. Egal ob checkfile Restores, einzelne VM´s oder eine tägliche Wiederherstellung deiner gesamten prod Umgebung inkl Tests in getrennten Umgebung. Mit Veeam kann ich auch Pre-Backup Checks machen, im Verdachtsfall einzelne Backup in ein "Dirty" Repository sichern und Alarm schlagen.

Es steht absolut außer Frage, Snapshots sind toll und sollten wenn möglich IMMER verwendet werden. Aber man sollte auch wissen wo die Grenzen der jeweiligen Systeme erreicht sind und bei Bedarf zusätzlich eine andere "Backup" Lösung implementieren.
 
Ohne Know How gehts natürlich selten.
Komplette ZFS Dateisysteme mal so schnell oder temporär aus einem lokalen ZFS Snap read/write bereitstellen geht aber ohne Zeitverzug per ZFS Clone. Ein Dateisystem kann man auch mit Rollback auf einen früheren Stand zurücksetzen. Ein ZFS Dateisystem aus einem Backupserver (Snap oder Filesystem) zurückzukopieren geht mit Replikation. Das dauert natürlich länger da Daten kopiert werden müssen. Gleiches gilt für ein Restore via Copy eines Snap -> aktuelles Dateisystem. Das entspricht im Ergebnis auch einem klassischer Restore aus Backup.

Bleibt nur die Konsistent der Daten einer VM im Snap. Für einen Filer kein Problem, für ESXi gibts Lösungen.
Lediglich bei Proxmox wohl noch ein Problem.

Ps
Was heißt "nur" Snapshot.

Ein Snapshot beinhaltet alle Daten eines Dateisystems im Snap Zeitpunkt (readonly). Per Clone kann man den Snapshot ganz normal als Dateisystem und schreibbar nutzen. Der Platzbedarf eines Snapshots ist beim Erstellen Null. Hundert Snaps ohne Änderung brauchen daher keinen Platz. Der "Speicherverbrauch" eines Snaps, genauer die Anzahl geblockter Bytes eines Dateisystems von Snap zu Snap entspricht lediglich den geänderten ZFS Datenblöcken (wg Copy on Write).
 
Zuletzt bearbeitet:
Moin, kurze Frage in die Runde hier. Ich gehe aktuell meine ersten Gehversuche mit ZFS in Unraid (hab ich nun mal da) und habe da direkt mal ne frage. Ist es normal das die Schreibgeschwindigkeit etwas langsamer ist im RaidZ als auf der einzelnen Platte? Hier sind es 3x12TB sata. Die schaffen einzeln ca 265Mb/s. Im RaidZ aktuell aber nur 220 ca. Gibt es irgendwo ne gute Seite zum einlesen in das Thema?
 
Prinzipiell hat man bei Platten das Problem dass die rein sequentiell mit einem User und einer großen Datei auf den äußeren Spuren 150-280 MB/s schaffen. Ist die Last nicht sequentiell sondern random (lesen mehrerer kleiner Dateien durch mehrere Nutzer) oder mixed (concurrent read/write) so merkt man dass eine Platte halt nur ca 100 iops kann. Je nach genauen Rahmenbedingungen sind dann 20-100 MB/s normal. Das hat zunächst nichts mit ZFS zu tun.

Im Raid kommt dies zum Tragen da eine zu schreibende Datei in Form kleiner Blöcke möglichst gleichmäßig über den Pool verteilt wird und damit werden iops wichtiger als reine sequentuelle Performance. Damit soll vor allem erreicht werden, dass möglichst immer gleichmäßig gute (schlechte) Zugriffsverhalten erreicht werden, auch bei großen Pools, vielen Dateien und Nutzern. Darauf ist ZFS ja ausgelegt nicht auf einen Nutzer der gerne ein Video schaut.

Hinzu kommt bei ZFS wegen Copy on Write eine höhere Fragmentierung als bei "alten" Dateisystemen. Auch gibt es wegen der Prüfsummen mehr io zum Lesen und Schreiben. ZFS muss damit konzeptionell langsamer sein als ext3 oder ntfs die beides nicht haben. Kompensiert wird das bei ZFS durch überragende rambasierte Schreib/ Lesecaches. Damit schafft es ZFS oft sogar schneller zu sein. Das braucht aber RAM, bei Linux etwas mehr, bei Solaris genügen ein paar GB weniger. Mit etwas mehr RAM (ab ca 16GB bei Linux und wenig Nutzern) sollte ein leeres Raid-Z aber durchaus ca 70% der Summe der Daten-Einzelplatten haben (wobei ich eine gute Einzelplatte meist mit 200 MB/s bei mixed load ansetze). Wenn eine Platte also 200 MB/s hat so sollte ein Raid Z1 mit 2 Datenplatten (und einer als Parität) etwas Richtung 200 x 2 x 0,7 = 280 MB/s können. Setzt man eine Platte mit 250MB/s an liegt man bei 350 MB/s im Raid - wird aber in der Praxis kaum zu erreichen sein. Wenn der Pool voll wird (ab ca 80%) sinkt das nochmal deutlich.

Optimieren kann man ZFS durch die recsize. Wenn man hauptsächlich Mediafiles hat ist 1M ein guter Wert, Auch sollte man bei einem einfachen Filer sicheres ZFS sync write immer deaktivieren.

Wieviel RAM hat denn der Rechner?
 
Zuletzt bearbeitet:
Danke schonmal, das bringt schon ein wenig licht ins dunkle. Ram sind 32GB, wovon zfs 24GB nutzen darf. Dateien sind zu 90% große Videodateien (10GB+)
 
Prinzipiell könnte mehr RAM etwas bringen (mehr Schreib/Lesecache). Per Default nutzt Open-ZFS ca 10% RAM als Schreibcache und ca 70% als Lesecache für ZFS Datenblöcke (read last/ read most, keine Files). Falls man recsize hochsetzt so wirkt das nur bei neu zu schreibenden Dateien.

Wie voll ist der Pool?
Ab ca 50% Füllrate werden Arrays spürbar langsamer, ab ca 80% deutlich.

Man kann auch mal iostat der Platten beobachten. Im Raid bestimmt immer die langsamste Platte die Array Performance.
Plattenlast sollte im Raid immer gleichmäßig verteilt sein.
 
Aktuell noch fast komplett leer, 2,8TB von 22TB. Mehr Ram kann ich mal testen.
 
Mal eine eher ESXi spezifische Frage: Ich möchte eine (nein, eigentlich zwei) NVMe SSDs an meine Napp-It VM durchreichen. Die NVMe SSD steckt in einem PCIe NVME Controller für 2 SSDs, die PCIe Bifurcation ist im BIOS (SuperMicro Board) eingeschaltet (4x4x) und die SSD wird in ESXi auch als Samsung NVMe SSD Controller erkannt. Passthru ließ sich problemlos um-/einschalten. Nur: Wie füge ich die SSD nun meiner VM zu? Unter PCI-Geräte taucht sie nicht auf und auch sonst habe ich keinen Hinweis gefunden. In den Einstellungen der VM könnte ich noch einen NVMe Controller hinzufügen, aber der hat wohl mit der SSD nix zu tun. Unter Napp-It taucht auch keine SSD auf.

Auf der SSD möchte ich dann letztlich einen Pool für meine VMs anlegen, ihn per NFS mit dem ESXi Host teilen und dort die VMs ablegen.

Edit: Wird das als RDM gemacht? Dazu habe ich gerade eine Anleitung gefunden…
 
Zuletzt bearbeitet:
Prinzipiell geht passthrough so:
- In ESXi die NVMe auf passthrough stellen. ESXi ignoriert daraufhin die NVMe.
ESXi neu starten (ESXi 8 kann das manchmal auch ohne)

- In den VM Einstellungen die NVMe als pci device hinzufügen.
Im Gast OS sollte die NVMe dann als Platte auftauchen.
NVMe Passthrough ist aber nicht immer so problemfrei wie SAS HBA Passthrough.

oder:
Die NVMe ohne passthrough in ESXi nutzen und darauf einen datastore anlegen.
Dann kann man darauf virtuelle Platten anlegen, idealerweise in den VM Einstellungen als nvme device

Vorteil: problemlos
Nachteil: VM hat keinen direkten Zugriff, keine Smartwerte

RDM macht man normalerweise für einzelne Sata/SAS Platten wenn man kein HBA Passthrough möchte
 
Danke für die Antwort, @gea!

- NVMe in ESXi auf Passthrough umstellen: Klappt ohne Fehlermeldung. Eintrag in /etv/vmware/passthru.map nicht nötig.
- Neustart
- In VM die NVMe als PCI-Gerät hinzufügen: Da taucht die NVMe gar nicht erst auf. :-|
- NVMe in /etc/vmware/passthru.map eingetragen:
144d a80a d3d0 false
- Neustart
- In VM die NVMe als PCI-Gerät hinzufügen: Auch hier taucht die NVMe gar nicht erst auf. :-|

Also bleibt wirklich nur, auf der NVMe eine VMDK anzulegen? Das Ganze dann tendenziell auch noch mit einer baugleichen 2. NVMe…

Ach so, ESXi ist Version 7.0.3, Upgrade wollte ich jetzt aber erst einmal nicht angehen. Zu viele Baustellen auf mal…
 
Interessante Beobachtung:

Beim NVMe Controller der SSD erscheint das Passthrough in ESXi als „Aktiviert“, nicht als „Aktiv“ wie bei den anderen. Weiterhin wird mit bei den PCI-Geräten in den VM-Einstellungen ein Ethernet-Adapter angeboten, der bei den PCIe-Geräten in den Hardware-Einstelltungen des Hosts gar nicht als „Aktiv“ oder „Aktiviert“ angezeigt wird… Spaßenshalber habe ich den mal eingebunden. Wie es scheint, erkennt OmniOS den als Netzwerk-Adapter. Hätte ja sein können, dass da nur die Bezeichnungen durcheinander gekommen sind.
 
Seltsam.
Wenn tatsächlich eine oder beide NVMe und nicht ein anderes Device auf Passthrough gestellt ist, dann müssen die anschließend in den VM Einstellungen als pci device verfügbar sein. Andernfalls ist eventuell eine Inkompatibilität da oder etwas läuft falsch.

Zum "Controller", was ist das, ein dummer Adapter um die 16/8 pci-lanes per Bifurkation auf 4x4 bzw auf 2x4 aufzuteilen oder ein teurer pci-e swich - der dann ohne Bifurkation arbeitet. In beiden Fällen muss nicht der "Controller" durchgereicht werden, sondern die daran angeschlossenen NMVe,
Beitrag automatisch zusammengeführt:

During fixing Bugs in current Open-ZFS, a ZFS bug in the Solaris fork Illumos that was there for a long time was also fixed

Bug #16087: lseek(SEEK_DATA) on ZFS races with writes and can briefly miss data before it is flushed in a txg - illumos gate - illumos

Redmine
www.illumos.org www.illumos.org

Should be available in OpenIndiana and next weekly OmniOS stables bugfix updates.
omnios.org

Release Notes

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support
omnios.org
 
Zuletzt bearbeitet:
Der Controller ist dieser hier und erfordert Bifurcation durch‘s Mainboard.


Bifurcation ist im Bios eingeschaltet auf x4x4:
IMG_6049.jpeg

ESXI erkennt auch beide NVMe SSDs im Controller. Es schreibt bei Passthrough auch „Aktiviert / Erfordert Neustart“. Den hinteren Teil habe ich nie gelesen, da die Spalte zu schmal war und der Rest durch „…“ dargestellt war. Neustarts habe ich nun x-mal gemacht…

IMG_6051.jpeg

Und krass, bzw. Bestätigung von etwas, was mir heute Morgen schon durch den Kopf ging: Da wird doch tatsächlich ein falsches Device zum Durchreichen in den Einstellungen zur VM angeboten. Nachdem ich die 2. NVMe eingesteckt und das Passthrough aktiviert habe, bekomme ich jetzt NOCH ein Ethernet Device zum Durchreichen angeboten. Und dabei ist für die Passthrough gar nicht aktivert. Da läuft was richtig falsch…

IMG_6052.jpeg

Inhalt der /etc/vmware/passthru.map:

Code: 
# passthrough attributes for devices
# file format: vendor-id device-id resetMethod fptShareable
# vendor/device id: xxxx (in hex) (ffff can be used for wildchar match)
# reset methods: flr, d3d0, link, bridge, default
# fptShareable: true/default, false

# Intel 82579LM Gig NIC can be reset with d3d0
8086  1502  d3d0     default
# Intel 82598 10Gig cards can be reset with d3d0
8086  10b6  d3d0     default
8086  10c6  d3d0     default
8086  10c7  d3d0     default
8086  10c8  d3d0     default
8086  10dd  d3d0     default
# Broadcom 57710/57711/57712 10Gig cards are not shareable
14e4  164e  default  false
14e4  164f  default  false
14e4  1650  default  false
14e4  1662  link     false
# Qlogic 8Gb FC card can not be shared
1077  2532  default  false
# QLogic QL45604 cards need to be reset with "link" and cannot be shared
1077  1634  link     false
1077  1629  link     false
1077  1636  link     false
1077  1656  link     false
1077  1644  link     false
1077  1654  link     false
# LSILogic 1068 based SAS controllers
1000  0056  d3d0     default
1000  0058  d3d0     default
# NVIDIA
10de  ffff  bridge   false
# Intel Sunrise Point-H AHCI
8086  a102  d3d0     false
# Intel USB 3.0 Controller
8086  a12f  d3d0     false
# Samsung NVMe SSD Controller
144d  a80a  d3d0     false

Wenn jemand einen anderen PCIe NVME Controller kennt, der mit dem Supermicro X11SSH-LN4F funktioniert - bitter gerne Hinweise. Muss halt in einen PCIe X8 Slot passen (in dem Board geht nur beim mittleren der drei PCIe Slot die Bifurcation).

Bin wirklich ratlos…
 
sch4kal schrieb:
Aus nem Kommentar aus Phoronix:
Full ack
Zum Vergrößern anklicken....
Mag sein. Aber was ebenso wichtig ist dass man neuere Features und Optimierungen einzubauen nicht höher gewichtet als Datensicherheit...
Also das hört sich für mich auch bisschen so wie herunterspielen des Ganzen an...

Ich hoffe dass auf BEIDEN Seiten etwas gelernt wurde.
 
@gea
Ich hätte mal ein paar Frage zu dem silent data corruption bug...

Habe hier ein System mit Proxmox 7.3 und bin mit ZFS Version 2.1.4 auf jeden Fall davon betroffen. Habe leider auch widersprüchliche Aussagen darüber gelesen, welche ZFS Versionen konkret betroffen sind. Mal hieß es zwischen 2.1.4 und 2.2.1, dann hieß es woanders, dass der Bug schon seit 2006 im Code schlummert...
Ich nutze das betroffene System aktuell glücklicherweise noch als Spielwiese, wollte es aber bald in eine Produktivumgebung umwandeln und habe die nötigen Daten (Bilder, Musik, Hörbücher) schon rüber kopiert.

Wegen des Bugs kann man nun ja offenbar leider nicht sicher sagen, ob die Daten vollständig / ohne data corruption auf dem Dateisystem vorliegen. Es scheint auch kein Prüftool zu geben, womit man checken kann, ob nun data corruption vorliegt. Schlimmstenfalls habe ich nun data corruption und ziehe ich nun meinen Server auf das neue System um, werden Daten teilweise unbrauchbar.

Ich bin nun etwas besorgt um meine Daten, allerdings jetzt nicht panisch, weil offenbar die Wahrscheinlichkeit extrem gering ist, dass der Bug tatsächlich auftritt. Trotzdem würde ich gerne schnellstmöglich eine gute Lösung finden...

Meine Fragen:
  • Kann man irgendwie sicher stellen, dass keine data corruption im aktuellen System vorliegt?
  • Ich hab hier noch alte Backup-Systeme mit ZFS Version 2.0 oder noch älter. Sind die auch betroffen oder erst ab 2.1.4?

Auch wenn es höchst unwahrscheinlich ist, gibt es meiner Ansicht nach 2 Möglichkeiten um SICHER zu stellen, dass die Daten nicht kaputt sind:
  1. Sofern ZFS vor 2.1.4 nicht betroffen war: Ich downgrade auf Proxmox 7.2 mit ZFS 2.1.3, richte ALLES neu ein und übertrage alle Daten erneut
  2. Ich warte, bis der Patch im neuesten Proxmox 8 ankommt, richte damit ALLES neu ein und übertrage die Daten erneut von der Originalquelle (Quellen sind Smartphone, Ext4, NTFS)

Vielen Dank im voraus...

sandreas
 
Option 3: Du lässt einen checksum Algorithmus über die Daten laufen (Dateiebene) auf der Quelle und auf dem Ziel und vergleichst diese.

Data at Rest ist von dem Bug ja mW nicht betroffen, nur wenn kopiert/geschrieben wird kann er auftreten (?).

Falls Du die Daten per smb/NFS übertragen und danach nicht mehr geändert hast, dürften sie auch nicht betroffen sein.
 
Um Open-ZFS Probleme zu vermeiden ist wohl ein Update auf ein aktuelles 2.2.2 oder 2.1.14 nötig. In deutlich älteren Versionen sind Probleme möglich aber zumindest nicht sehr wahrscheinlich. Die meisten Problemmeldungen gab es ja in den letzten Wochen mit den letzten Versionen . Gravierende und häufige Problemmeldungen davor eher nicht obwohl das Problem ursächlich wohl schon sehr lange besteht. Insgesamt handelt es sich um ein gravierendes Problem aber kein Massenproblem.

Empfehlenswert ist es auf jeden auf eine der ganz aktuellen Versionen upzudaten. Vorhandene Daten die nicht geändert werden und Backups sollten relativ sicher sein, vgl https://www.theregister.com/2023/12/04/two_new_versions_of_openzfs/
 
@gea @asche77 Vielen Dank für die raschen Antworten...
asche77 schrieb:
Option 3: Du lässt einen checksum Algorithmus über die Daten laufen (Dateiebene) auf der Quelle und auf dem Ziel und vergleichst diese.
Zum Vergrößern anklicken....
Nette Idee, aber ich fürchte, dass hier der Aufwand aufgrund der "Verteiltheit" der Daten wohl annähernd einem neuen Aufsetzen gleich kommt. Stelle ich nämlich beim Vergleich Fehler fest, kann ich neu Aufsetzen UND alles nochmal machen.

Data at Rest ist von dem Bug ja mW nicht betroffen, nur wenn kopiert/geschrieben wird kann er auftreten (?).

Falls Du die Daten per smb/NFS übertragen und danach nicht mehr geändert hast, dürften sie auch nicht betroffen sein.
Zum Vergrößern anklicken....

Das ist grundsätzlich gut, aber ich kann einfach nicht mehr sicher sagen, was ich schon alles mit den Daten gemacht habe... leider.

gea schrieb:
Um Open-ZFS Probleme zu vermeiden ist wohl ein Update auf ein aktuelles 2.2.2 oder 2.1.14 nötig. In deutlich älteren Versionen sind Probleme möglich aber zumindest nicht sehr wahrscheinlich. Die meisten Problemmeldungen gab es ja in den letzten Wochen mit den letzten Versionen . Gravierende und häufige Problemmeldungen davor eher nicht obwohl das Problem ursächlich wohl schon sehr lange besteht. Insgesamt handelt es sich um ein gravierendes Problem aber kein Massenproblem.
Zum Vergrößern anklicken....
Ok... demnach behalte ich jetzt erstmal alles bei, warte bis Proxmox das Update integriert hat und installiere dann komplett neu. Ich habe ein bisschen das Vertrauen in ZFS verloren muss ich sagen... nicht grundsätzlich, andere machen auch Fehler und die Kommunikation diesbezüglich war akzeptabel, aber die Komplexität bei ZFS ist schon sehr sehr hoch.

Fürs Protokoll, ich hab schon einiges mit dem System gemacht, um den Havariefall zu testen:
Anhand der größeren lese und schreibvorgänge würde ich vermuten, dass man hier durchaus rechtfertigen kann, sich nicht auf "die Daten sind schon OK" zu verlassen. Ich wollte ohnehin noch eine Artikelserie für meinen Blog schreiben, wie ich self-hosting mit OpenWRT, wireguard, verschlüsseltem Proxmox, Docker und LXC inkl. mapped mounts mit einem 12W Xeon 1225 v5 Server umsetze, das kann ich ja dann jetzt dokumentieren, während ich es durchführe.
Ein Upgrade auf Proxmox 8 hätte ohnehin eine Neu-Installation bedeutet.
:-)
 
Zuletzt bearbeitet:
sandreas schrieb:
@gea @asche77 Ich habe ein bisschen das Vertrauen in ZFS verloren muss ich sagen... nicht grundsätzlich, andere machen auch Fehler und die Kommunikation diesbezüglich war akzeptabel, aber die Komplexität bei ZFS ist schon sehr sehr hoch.
Zum Vergrößern anklicken....
Ich nutze und beschäftige mich mit ZFS jetzt seit über 15 Jahren. Kritische Probleme gabs in der Zeit ein paarmal, z.B. mit trim oder persistentem l2arc kurz nachdem das implementiert wurde. ZFS ist unter der Haube schon etwas komplexeres, aus Nutzersicht angesichts der Fähigkeiten jedoch recht übersichtlich.

Was man immer anraten kann wenn man auf besondere Stabilität aus ist:
Nicht alles was Neu ist und größere strukturelle Änderungen bewirkt wie z.B. Raid-Z Erweiterung sofort haben wollen. Lieber etwas warten bis andere die Probleme entdeckt haben und die beseitigt sind. Auch gut ist es die entsprechenden Maillisten der Distribution zu abbonnieren oder ab und zu auf die entsprechenden Issue Tracker zu schauen. Frühzeitiges Erkennen von Problemen ist das A und O.

Klar ist. Es gibt keine fehlerfreie Software, Jede Software lebt, wird weiterentwickelt und braucht konstante Pflege. Große Bugs fallen schnell auf und schaffen es nicht in die jeweiligen stabilen Versionen. Gemein sind die seltenen Probleme die nur bei ganz bestimmten Bedingungen auffallen oder bei einzelnen der vielen Linux Distributionen, so wie hier. Kleinere geschlossenere Unix ZFS Varianten wie native Solaris ZFS oder Illumos OpenZFS sind da im Vorteil. Da gibt es nicht zig ZFS Varianten für zig Distributionen sondern exakt einen ZFS Stand für ein Betriebssystem.

Es gibt hunderttausende von ZFS Installationen mit ein paar Dutzend Problemberichten. Andere neue Dateisysteme wir btrfs oder ReFS wären froh wenn sie die Reife von ZFS erreicht hätten. Sonstige wie ext4 oder ntfs werden das nie erreichen. Da kann schon ein einfacher Absturz beim Schreiben reichen um das Dateisystem oder Raid zu schrotten, einen Bug brauchts da nicht.
 
Zuletzt bearbeitet:
Ich nochmal mit dem Problem, zwei NVMEs an eine VM durchzureichen: Jetzt habe ich einen zweiten (und dritten) PCIe-NVMe Adapter besorgt. Gleiches Bild. Die NVMes werden nicht zum Durchreichen angeboten und bei der Hardware Verwaltung des Host stehen sie als „Aktiviert /Neustart erforderlich“). Zwar nur bei dem zweiten Adapter probiert, aber der dritte („Original“ von Supermicro) wird wohl ähnlich aussehen…

Hat noch jemand Hinweise? Bios-Einstellungen? Ich werde wohl mal nach einem Bios-Update schauen. Wer weiß…
 
Geht denn Plan B indem man die NVMe unter ESXi als local datastore nutzt und dann als vdisk einbindet?
 
So schnell wollte ich nicht aufgeben, Passthrough würde mir besser gefallen. Sonst müsste ich (da zwei NVMe) zwei Datastores und zwei virtuelle Disks erstellen, denn die beiden NVMe sollen in Napp-It als gespiegelter Pool eingebunden werden, an dem dann wiederum die restlichen VMs abgelegt werden. Das klingt mir doch alles sehr nach von hinten durch die Brust.. (Datastore -> virt. Disk -> Pool -> Filesystem -> NFS-Share -> VMs …). Ich werd jetzt mal noch ein Bios Update machen, vielleicht bringt das noch was. ESXi Update wäre auch noch denkbar, vielleicht werden die PCI Devices ja dort „durcheinander gewürfelt“. Wenn das nix bringt, kann ich Plan B immer noch verfolgen…
 
Gibts andere Slots in denen man den NVMe Adapter versuchen könnte.
 
Nee, das Board hat nur 3 Slots, von denen auch nur einer (der verwendete) Bifurcation beherrscht. Dummerweise kann ich hier nicht schalten und walten, wie ich gerne würde. Wäre jedesmal eine Downtime, die sogar im familiären Umfeld gegen das erwartete SLA geht… :ROFLMAO: Deswegen zieht sich das bei mir leider ein wenig…

Im ESXi Thread hab ich was von Problemen mit Samsung NVMe gelesen. Bei mir sind es zwei Samsung NVMe PCIe 4.0 SSD 980 PRO. Wäre das evtl. noch eine mögliche Ursache? Wenn ich einen neuen Datastore unter ESXi anlegen will, dann werden sie mir ja angeboten, um den Datastore darauf anzulegen. Insofern glaube ich eigentlich, dass die Bifurcation grundsätzlich funktioniert. Lediglich beim Passthrough scheint ESXi was durcheinander zu bringen (oder wird durcheinander gebracht) …
 
So, heute Abend die Gelegenheit genutzt, um diverse Updates einzuspielen: Server-IPMI, Bios-Update und aktuelles Patchlevel ESXi 7.0.3. Hat viel Zeit gekostet, insbesondere um nach dem Bios-Update wieder von der SSD im Onboard M.2 Slot zu booten (AMI Firmware, nicht Vendor Firmware..). In Sachen Passthrough leider keine Besserung. Naja, zumindest sind jetzt mal wieder einige Sicherheitslücken gepatcht, das ist ja auch was. Morgen gehe ich noch einmal die Bios Settings an… Mir geht immer noch nicht aus dem Kopf, dass mit Hinzufügen einer NVMe in der Adapter-Karte und Einschalten von Passthrough in den Hardware Einstellungen des ESXI Hosts statt der NVMe ein Ethernet-Device in der Auswahl erscheint, wo man in der VM das hinzuzufügende PCI-Device auswählt. Wie kann das sein? Zweimal, also jeweils beim Hinzufügen einer NVMe?
Was ich morgen außerdem noch einmal angehe, ist noch einen anderen PCIe-NVMe Adapter auszuprobieren. Da liegt noch einer von Supermicro in der Originalverpackung. Vielleicht liegt‘s ja doch am Adapter…
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
532
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
309
AliManali
AliManali
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