[Sammelthread] ZFS Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Und plötzlich verspĂŒre ich keinen Drang mehr, von Solaris weg zu kommen und auf OpenZFS zu migrieren đŸ« 
 
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:
  • Danke
Reaktionen: you
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. :(
 
Also mein pve ist schon mal potentiell betroffen:
zfs-linux (2.2.0-pve3) bookworm
:(
Wie krieg ich die version bei TruNAS raus.... grml.
 
Uuuuuhm fuck, NOW I got some pipi in my hose:
root@truenas[~]# zfs version
zfs-2.1.11-1
zfs-kmod-v2023072100-zfs_0eb787a7e


Wie krieg ich jetzt raus ob und was betroffen ist?
 
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
Code:
zfs_dmu_offset_next_sync=0
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.
 
Also so wie ich das verstanden habe ist 2.1.x safe, 2.2.x nicht. Das einzige das bei mir auf 2.2.0 lÀuft sind meine SSD-Mirrors im proxmox, darauf laufen meine VMs - die sind gebackupped auf mein TrueNAS, das mit 2.1.11 lÀuft...
 
Also so wie ich das verstanden habe ist 2.1.x safe, 2.2.x nicht. Das einzige das bei mir auf 2.2.0 lÀuft sind meine SSD-Mirrors im proxmox, darauf laufen meine VMs - die sind gebackupped auf mein TrueNAS, das mit 2.1.11 lÀuft...
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:
Und plötzlich verspĂŒre ich keinen Drang mehr, von Solaris weg zu kommen und auf OpenZFS zu migrieren đŸ« 

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.
 
Wie es scheint sollen die Probleme auf https://github.com/openzfs/zfs/issues/11900 zurĂŒckgehen.
Hier die (fĂŒr mich) beste Zusammenfassung:

RichardBelzer commented 3 hours ago

So are we tracking three different disk corruption issues?
  1. With strict hole reporting (i.e. zfs_dmu_offset_next_sync set to 1). This has been a silent disk corruption issue since 2.1.4 and a fix is not in any current release.
  2. With block cloning which results in silent disk corruption. This is only an issue in 2.2.0 and has been resolved in 2.2.1 by disabling it, but no long term fix exists yet.
  3. When using LUKS which results in write errors with ZFS on 2.2.1. A fix is not in any current release.
So the safest thing to do for now to avoid further data loss is just use 2.1.13 and set zfs_dmu_offset_next_sync=0? Is that the blessed thing to do by the OpenZFS team until an official release is made for 2.1.14 and 2.2.2?
 
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.
 
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.
 
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.
 
Samba auf Posix ACL und Unix uid statt Solaris SMB auf NFS4 ACL mit Windows SID eher nicht.
Also das hier ist unter Linux nicht gleichwertig, da die direkte Abbildung der Windows SID fehlt?
 
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.

Ggf einfach Housten, Poolsman,... verwenden.
 
Ggf einfach Housten, Poolsman,... verwenden.
Hmmm,:unsure:

These Terms of Use constitute a legally binding agreement made between you, whether personally or on behalf of an entity ("you") and Ambyco, LLC (doing business as Poolsman).....
.....

Ambyco, LLC
19 Amangeldi Imanov Street
Floor 11, Suite 36
Nur-Sultan 010000
Kazakhstan
da bleib ich lieber bei napp-it.
 
Also das hier ist unter Linux nicht gleichwertig, da die direkte Abbildung der Windows SID fehlt?

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.

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

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.local

Ich 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:
oder hat jemand eine Idee wie man Proxmox dazu bringen kann, Gast-Dateisystem-sichere ZFS Snaps zu erstellen
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).
 

AnhÀnge

  • snap.txt
    1,6 KB · Aufrufe: 19
  • snaplogin.txt
    133 Bytes · Aufrufe: 18
Zuletzt bearbeitet:
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.

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:
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:
Ich hoffe das der quemu guest agent das auch macht - bei VMs. Nutze PVE nur privat, in der Firma haben wir vSphere Cluster.
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
 
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,
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.
 
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.
 
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