Fusseltuch
Enthusiast
Soviel dazu 😵💫
Soviel dazu 😵💫
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 529
Neue Probleme mit 2.2.1: https://github.com/openzfs/zfs/issues/15533 unten
scheint was mit LUKS zu tun zu haben.
Zwischenzeitlich weitet sich das data corruption Problem offenbar auch auf ältere Versionen aus: https://github.com/openzfs/zfs/issues/15526
scheint was mit LUKS zu tun zu haben.
Zwischenzeitlich weitet sich das data corruption Problem offenbar auch auf ältere Versionen aus: https://github.com/openzfs/zfs/issues/15526
Zuletzt bearbeitet:
Shihatsu
Legende
- Mitglied seit
- 16.08.2005
- Beiträge
- 5.013
Das ist scary Shit. Ich warte dann mal mit Updates für meinen proxmox Server. Was nutzt eigentlich TrueNAS (nicht scale, "normal")? Darauf läuft mein Filekrams. Vielleicht wird es doch mal Zeit auf Napp-IT (auf proxmox, ich HASSE ESXi) zu wechseln...
Zuletzt bearbeitet:
Fusseltuch
Enthusiast
Auf jeden Fall. Habe mir die verlinkten Bugreports mal in Gänze angesehen, das ist wirklich fatal. Wobei es so aussieht, als müssten bestimmte Rahmenbedingungen erfüllt sein, um die Bugs zu triggern. Es wird nicht alles sofort in Flammen aufgehen, aber es fördert nicht unbedingt das Vertrauen, wenn es solche gravierenden Bugs in eine Release-Version schaffen.
Fusseltuch
Enthusiast
Bei Proxmox wird das schon diskutiert: https://forum.proxmox.com/threads/o...ailable-on-test-no-subscription.135635/page-7
Seite 7 und folgende.
Sollte dann die Version aussprucken.
Seite 7 und folgende.
Code:
zfs versionFusseltuch
Enthusiast
Der ganze Sachverhalt ist aktuell noch unklar, wirklich gesicherte Erkenntnisse gibt es noch nicht. Mutmaßlich betroffen ist man, wenn man seine Platten/Partitionen mit LUKS verschlüsselt und nicht die in ZFS integrierte Verschlüsselung nutzt.
Bei den Version 2.1.x könnte es helfen
zu setzen, ich habe aber noch nicht ganz verstanden, wo das gesetzt wird. Eventuell kann @gea uns da helfen...
Bei Version 2.2.x habe ich keine Ahnung.
Ich würde die verlinkten Bugreports weiterhin verfolgen und schauen, was noch ans Licht kommt. Und für den Seelenfrieden vielleicht ein Extra-Backup machen, sofern (Nicht-ZFS)Speicherplatz zur Verfügung steht.
Bei den Version 2.1.x könnte es helfen
Code:
zfs_dmu_offset_next_sync=0Bei Version 2.2.x habe ich keine Ahnung.
Ich würde die verlinkten Bugreports weiterhin verfolgen und schauen, was noch ans Licht kommt. Und für den Seelenfrieden vielleicht ein Extra-Backup machen, sofern (Nicht-ZFS)Speicherplatz zur Verfügung steht.
Naja eben genau nicht. Da gabs einen Anwender der den PoC von dem issue unter 2.1.10 ausführte und das Problem hatte. Wenn man es genau wissen will sollte man den Pythoncode aus dem Issue ausführen und schauen was da raus kommt.
Edit, hier der Codesnippet zur Prüfung:
Zuletzt bearbeitet:
Open-ZFS gibt es auch bei den freien Solaris Forks. Man hat auch Open-ZFS v5000 und alle wichtigen Features und ist kompatibel zu BSD und Linux.
Solaris 11.4 ist zwer immer noch so ziemlich das schnellste und hat kommerziellen Support bis mindestens 2035. Ist aber kommerziell und benötigt für kommerzielle Nutzung einen Supportvertrag. Solaris 11.4cbe (mehr oder weniger eine aktuelle Beta) kann man zwar frei herunterladen, hat aber keinen Zugriff auf alle Support-Fixes.
Ich halte die freien Solaris Forks um Illumos für besser und zukunfstfähiger. Meinen Hauptgrund für Solaris, den OS/ZFS integrierten SMB/NFS Server mit NFS4 ACLs und Windows SID im Dateisystem haben beide.
Die Situation mit Open-ZFS 2.2 ist übel, zumal es ja Berichte nicht nur bei Luks verschlüsselten Platte gab (solltze man aktuell meiden, ist zwar schnell aber der ZFS Ansatz ist eh universeller) sondern auch rund um Cache und Importprobleme gibt. Das unangenehme ist ja gerade dass es keine eindeutigen einzelne Probleme gibt. In der Tat is wohl der beste Ansatz ältere 2.1 Versionen zu bevorzugen und in der Tat bei besonders wichtigen Daten auf Backups zu achten, auf eine ältere ZFS Version oder gar Nicht-ZFS oder andere ZFS Basis.
Und ansonst, halt abwarten bis sich die Situation über einem längeren Zeitraum (ein paar Wochen) mit Updates beruhigt. Es arbeiten ja genügend Leute an den Problemen.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 529
Wie es scheint sollen die Probleme auf https://github.com/openzfs/zfs/issues/11900 zurückgehen.
Hier die (für mich) beste Zusammenfassung:
Hier die (für mich) beste Zusammenfassung:
RichardBelzer commented 3 hours ago
So are we tracking three different disk corruption issues?
|
Zuletzt bearbeitet:
@gea Wie ist eigentlich der aktuelle Status von napp-it unter Linux?
Die Informationen dazu auf der napp-it Website sind, soweit ich gesehen habe, schon etwas älter.
Zum Hintergund: Ich habe nach langen, treuen Diensten meinen napp-it all in one (also ESXi mit HBA passthrough an Omnios als Fileserver) auf Proxmox umgestellt.
Eine Diskussion warum und des für und wieder möchte ich hier nicht anstossen.
Der Funktionsumfang des Proxmox GUI ist allerdings in Bezug auf die ZFS Verwaltung recht übersichtlich.
Das würde ich gerne mit napp-it ergänzen. Die übrige Server-Verwaltung, welche ja doch recht OS spezifisch ist, würde über das Proxmox GUI laufen.
Die Informationen dazu auf der napp-it Website sind, soweit ich gesehen habe, schon etwas älter.
Zum Hintergund: Ich habe nach langen, treuen Diensten meinen napp-it all in one (also ESXi mit HBA passthrough an Omnios als Fileserver) auf Proxmox umgestellt.
Eine Diskussion warum und des für und wieder möchte ich hier nicht anstossen.
Der Funktionsumfang des Proxmox GUI ist allerdings in Bezug auf die ZFS Verwaltung recht übersichtlich.
Das würde ich gerne mit napp-it ergänzen. Die übrige Server-Verwaltung, welche ja doch recht OS spezifisch ist, würde über das Proxmox GUI laufen.
Napp-it unter Linux läuft unverändert. Es werden aber nur Basis-Funktionen unterstützt, die auf ZFS (Poolverwaltung, Snaps) oder Perl (Jobverwaltung, Replikation) aufbauen, also mit deutlich weniger Funktionen als unter Solaris/OmniOS/OpenIndiana.
Eine Option wäre noch eine Solaris/OmniOS Storage VM unter Proxmox, ähnlich der ESXi Lösung. Ich habe mich aber noch nicht damit beschäftigt, wie gut Solaris unter Proxmox läuft. Da hätte man auch den kernelbasierten Solaris SMB Server.
OmniOS läuft gut unter Proxmox. Allerdings ist das Durchreichen vom HBA nach meinem Gefühl Glückssache.
Bei Proxmox 8 bekomme ich den on-board-HBA auf meinem SuperMicro Board nur durchgereicht, wenn ich den letzten Kernel aus Proxmox 7 verwende (5.15.108-1-pve). Sobald ich auf einen aktuellen umschalte (6.2 oder 6.5), bekomme ich die OmniOS VM nicht mehr ans Laufen. Die VM schaltet sich während des Bootens auf. Und ich habe keine Ahnung, woran das liegen konnte.
Schon mit dem alten Kernel habe ich unter Proxmox 7 einen zweiten HBA, ebenfalls ein SAS3008 mit derselben Firmware, nicht durchgereicht bekommen. Hier geht wohl nur Probieren über Studieren.
Bei Proxmox 8 bekomme ich den on-board-HBA auf meinem SuperMicro Board nur durchgereicht, wenn ich den letzten Kernel aus Proxmox 7 verwende (5.15.108-1-pve). Sobald ich auf einen aktuellen umschalte (6.2 oder 6.5), bekomme ich die OmniOS VM nicht mehr ans Laufen. Die VM schaltet sich während des Bootens auf. Und ich habe keine Ahnung, woran das liegen konnte.
Schon mit dem alten Kernel habe ich unter Proxmox 7 einen zweiten HBA, ebenfalls ein SAS3008 mit derselben Firmware, nicht durchgereicht bekommen. Hier geht wohl nur Probieren über Studieren.
Zuletzt bearbeitet:
Proxmox statt ESXi könnte ich mir vorstellen. Samba auf Posix ACL und Unix uid statt Solaris SMB auf NFS4 ACL mit Windows SID eher nicht. Auch Proxmox Backup Server mit file copy statt ZFS Snaps/ ESXi hot memory snaps mit Replikation als Basis für Backups laufender VMs wäre für mich eher "suboptimal". Hat sonst jemand Erfolg mit Passthtrough unter Proxmox 8.1 und OmniOS Unix als Gast (HBA, eventuell nic) oder hat jemand eine Idee wie man Proxmox dazu bringen kann, Gast-Dateisystem-sichere ZFS Snaps zu erstellen.
Also das hier ist unter Linux nicht gleichwertig, da die direkte Abbildung der Windows SID fehlt?
ACL Primer
Provides general information on POSIX and NFSv4 access control lists (ACLs) in TrueNAS systems and when to use them.
www.truenas.com
Ggf einfach Housten, Poolsman,... verwenden.
Also das hier ist unter Linux nicht gleichwertig, da die direkte Abbildung der Windows SID fehlt?
ACL Primer
Provides general information on POSIX and NFSv4 access control lists (ACLs) in TrueNAS systems and when to use them.
Es sind mehrere Aspekte für eine Windows ntfs artige User und Rechterverwaltung
(NFS v4 ACL = Superset von Windows ntfs ACL, Posix ACL und einfachen Permissions wie 755)
1. NFS v4 ACL im Dateisystem. Ist bei Solaris und Free-BSD der Fall/ möglich, bei Linux derzeit nicht.
ACLs - Linux NFS
2. NFS v4 ACL im SMB Server (Solaris SMB oder SAMBA)
Der Solaris SMB Server nutzt ausschließlich NFS v4 ACL, sowohl lokal wie im AD
New Solaris ACL Model - Oracle Solaris Administration: ZFS File Systems
This book is intended for anyone responsible for setting up and administering Oracle ZFS file systems. Topics are described for both SPARC and x86 based systems, where appropriate.
docs.oracle.com
NFS4 ACL overview - SambaWiki
3. Dateireferenz für Owner oder Authorisierung
Ist bei Solaris SMB die Windows SID als erweitertes ZFS Attribut
Bei BSD und LInux ist das die Unix uid mit der Notwendigkeit von Mappings mehrdeutige uid wie 101 -> eindeutige (AD) SID
Ein ZFS Restore behält damit seine AD Rechte ohne erneutes User Mapping. Die uid/gid sind ja auf jedem Server meist was anderes.
4. SMB Gruppenverwaltung
Die Linux/Unix Gruppenverwaltung mit gid Nummern ist nicht Windows kompatibel da keine Gruppen in Gruppen möglich sind, es sei denn der SMB Server SAMBA faked das im AD Betrieb. Solaris kennt lokale SMB Gruppen mit einer Windows Gruppen SID die weitere SMB Gruppen enthalten können.
Code:
smbadm show
administrators (Members can fully administer the computer/domain)
SID: S-1-5-32-544
backup operators (Members can bypass file security to back up files)
SID: S-1-5-32-551
power users (Members can share directories)
SID: S-1-5-32-547
smbadm show -mp administrators
administrators (Members can fully administer the computer/domain)
SID: S-1-5-32-544
Privileges:
SeTakeOwnershipPrivilege: On
SeBackupPrivilege: On
SeRestorePrivilege: On
BypassAclRead: Off
BypassAclWrite: Off
Members:
gea@omnios.localIch habe vor Jahren lange versucht, meine Windows AD Filer mit Linux + SAMBA abzulösen, bin aber letztlich immer gescheitert oder hatte zuviele Einschränkungen. Linux/Unix + SAMBA ist prima, wenn man auf einen Linux/Unix Server SMB Zugriff haben möchte und ansonst in der Linux/Unix Rechtewelt bleibt. Einen Windows AD Filer rechtemäßig sauber zu ersetzen ist mir erst unter Solaris mit dem kernelbasierten SMB Server gelungen und das sehe ich auch heute noch so.
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
PVE verlässt sich bei den snaps auf die Funktion des Dateisystems, daher hoffe ich doch das jeder snap nicht die Konsistenz der VM/LXC beeinträchtigen kann. Ich nutze bei meinem PVE zfs, und sehe dann die jeweiligen zfs snaps in der shell, wenn ich einen über die GUI des jeweiligen lxc/vm mache.
Ich nutze eine Skriptkombi um beim ssh Login des jeweiligen LXC einen snap zu machen. Allerdings hat mir da jemand geholfen und im zweiten Teil funktioniert die altersbestimmte Löschung nicht, hatte bisher nur keine Zeit mir das genauer anzuschauen.
Ist aber nur auf LXC ausgelegt, aber vlt gibt es ja Anstöße.
Snaplogin ist auf dem betreffenden LXC und löst dann das snap was auf dem pve host liegt aus und übergibt eine variable (LXC ID).
Zuletzt bearbeitet:
ZFS Snaps sind wie Stromstecker ziehen. ZFS sorgt zwar mit Copy on Write dafür dass das ZFS Dateisystem selber auch bei einem Absturz während des Schreibens unbeschädigt bleibt (Dateien die gerade geschrieben werden, sind natürlich meist korrupt), nicht jedoch Gast-Dateisysteme selbst ZFS Gast-Dateisysteme können dann korrupt sein. ZFS sync write kann auch lediglich den Inhalt des rambasierten Schreibcaches schützen indem unvollständige, bestätigte atomare Schreibvorgänge (Metadaten + Daten) beim nächsten Reboot nachgeholt werden. Für Snaps die während eines Schreibvorgangs erstellt werden, gibt es schlicht keine technische Möglichkeit die Unversehrtheit von VM Gastdateisystemen zu gewährleisten. Sowas könnte allenfalls der VM Server in Zusammenarbeit mit den VMs. Ohne sowas kann eine VM im ZFS Snap immer korrupt sein. Vor ZFS Snaps solltr man dann immer die VMs vorher herunterfahren oder anhalten.
ESXi macht das z.B. mit dem VM quiesce Snap Modus bei dem die vmware Tools das Gast-Dateisystem kurz anhalten oder mit dem hot memory Snap Modus bei dem der Arbeitsspeicher mit im Snap ist. Ein Snap Restore liefert dann sogar eine laufende online VM im Snapzeitpunkt.
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
Ich hoffe das der quemu guest agent das auch macht - bei VMs. Nutze PVE nur privat, in der Firma haben wir vSphere Cluster.
Leider ist dein Ansatz mit NFS Share wo die VMS sind auf einem dedi zfs storage bei PVE nur so halb effizient. Ich nutze daher den PBS für Backups. Und bei LXC gehts ja gar nicht.
Zuletzt bearbeitet:
Die VMware Tools können unversehrte Gast Dateisysteme auch nur für ESXi Snaps gewährleisten, nicht für ZFS Snaps. Will man "sichere" ZFS Snaps unter ESXi so muss man auch da ZFS Snaps mit ESXi Snaps kombinieren,
vgl https://www.hardwareluxx.de/community/threads/esx-esxi-hilfethread.748644/page-292#post-29858554
Luckysh0t
Enthusiast
Das ist mir klar, ich bezog mich darauf, dass der qm agent hoffentlich die Vm in einen konsistenten zustand versetzt bevor dann ein zfs snap gemacht wird. Analog zudem was die vmware tools machen, bevor ein esxi snap passiert. Sonst hätte man ja immer die Gefahr dass ein snap, der bei PVE nunmal ein zfs snap ist, die Vms etc gefährdet.
Das wird wohl so sein, sonst bräuchte man ja den Proxmox Backup Server nicht.
Korrigiert mich wenn es anders sein sollte.
Zuletzt bearbeitet:
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.
