PVE Datastores mit verschiedenen knotenabhängigen ZFS-Zielen

Ich hatte das noch nie getestet, aber eben gelernt, dass ZFS beim Pool erzeugen auch direkt im Hintergrund ein Volume erzeugt, falls man Dateien in diesen Mountpoint kopiert.

Für die Dateien wird aber tatsächlich das Dateisystem genutzt, weshalb das für VM Disks nicht optimal ist.
Was ich eben auch gelernt habe, das default Volume ohne Dataset Create kann kein Compression oder andere nette Features von ZFS nutzen,
 
Last edited:
  • Like
Reactions: Johannes S
zpool create -O compression=lz4 usw usf, aber man lernt nie aus, ansonsten wird es ja auch langweilig ... :)
 
zpool create -O compression=lz4 usw usf, aber man lernt nie aus, ansonsten wird es ja auch langweilig ... :)
In der Offiziellen Doku stand es aber anders erklärt. Da steht tatsächlich, um die Compression des Pools zu nutzen muss man ein Dataset erstellen. Weiß aber auch nicht von wann die ist. Welche weiteren Features verloren gehen wurde leider auch nicht ausgeführt.
 
das "root" dataset eines pools sollte aus anderen gründen nicht direkt mit daten gefüllt werden, ist aber prinzipiell ein ganz normales filesystem dataset wie andere auch, inkl mountpoint ;)
 
Es gibt immer noch, auch im Proxmox-Team selbst, oft unklare bis falsche Vorstellungen wie ZFS funktioniert. Insbesondere wie ZVOLs und FILESYSTEMs zusammenhängen, dabei ist es nicht so schwierig. In ZFS gibt es zwei Typen von DATASET: VOLUME und FILESYSTEM. Diese kann man sich mit "zfs list -o name,type" anzeigen lassen. Jedes dataset außer dem root-Filesystem, das immer ein Filesystem ist, hat ein Parent-Filesystem (Filesystem nicht dataset). Das Kind erbt dabei die erbbaren Attribute von seinem Parent, z.B. so etwas wie compression und dedup. Insbesondere lebt JEDES ZFS-VOLUME in einem ZFS-Dateisystem, nämlich seinem Parent. Parents können wie gesagt nur Filesystem nicht VOLUME sein. Der Mountpoint eines ZFS-Dateisystems ist davon noch unabhängig, denn er kann separat gewählt werden. Defaultmäßig ist er gleich seinem Namen im Pfad des Parent-Filesystems. Dies dazu, weil jemand von Proxmox auf meinen Bugzilla-Verbesserungsvorschlag meint, ZVOL würden nicht in einem Dataset leben, sondern es sei eine separate Hierarchie was halt falsch ist.

Ich möchte nochmal auf meinen Vorschlag zurückkommem, doch seitens Proxmox zuulassen, dass man mehrere Einträge für denselben ZFS-Storagenamen (was immer ein ZFS-FILESYSTEM ist) zuzulassen, solange die Servereinträge diejunkt sind. Das ist nun wirklich eine einfach Erweiterung wovon schon fast alles dazu, denn es gibt ja bereits den Lookup bzw. des Servers selbst geprüft werden muss, ob der Storage dort als vorhanden eintragen ist oder nicht. Jetzt müsste das nur so erweitert werden, dass die ganze Liste durchgegangen wird.
 
  • Like
Reactions: waltar
Es gibt immer noch, auch im Proxmox-Team selbst, oft unklare bis falsche Vorstellungen wie ZFS funktioniert.

Naja, das Hauptargument hier in der Diskussion war aber nicht, wie ZFS funktioniert oder nicht funktioniert, sondern dass dein Vorschlag das Interface sehr viel komplizierter macht, der Mehrwert dafür aber (aus Sicht der Entwickler und zumindestens einiger User hier im Thread) zu gering ist.

Zur Frage, wer jetzt ZFS besser verstanden hat, äußere ich mich als simpler Sysadmin lieber nicht, ich habe das letzte mal vor fünfzehn Jahren an der Uni Code verbrochen, der über ein simples Shell- oder Pythonskript hinausging
 
Last edited:
  • Like
Reactions: Falk R.
Es gibt immer noch, auch im Proxmox-Team selbst, oft unklare bis falsche Vorstellungen wie ZFS funktioniert. Insbesondere wie ZVOLs und FILESYSTEMs zusammenhängen, dabei ist es nicht so schwierig. In ZFS gibt es zwei Typen von DATASET: VOLUME und FILESYSTEM. Diese kann man sich mit "zfs list -o name,type" anzeigen lassen. Jedes dataset außer dem root-Filesystem, das immer ein Filesystem ist, hat ein Parent-Filesystem (Filesystem nicht dataset). Das Kind erbt dabei die erbbaren Attribute von seinem Parent, z.B. so etwas wie compression und dedup. Insbesondere lebt JEDES ZFS-VOLUME in einem ZFS-Dateisystem, nämlich seinem Parent. Parents können wie gesagt nur Filesystem nicht VOLUME sein. Der Mountpoint eines ZFS-Dateisystems ist davon noch unabhängig, denn er kann separat gewählt werden. Defaultmäßig ist er gleich seinem Namen im Pfad des Parent-Filesystems. Dies dazu, weil jemand von Proxmox auf meinen Bugzilla-Verbesserungsvorschlag meint, ZVOL würden nicht in einem Dataset leben, sondern es sei eine separate Hierarchie was halt falsch ist.

Ich möchte nochmal auf meinen Vorschlag zurückkommem, doch seitens Proxmox zuulassen, dass man mehrere Einträge für denselben ZFS-Storagenamen (was immer ein ZFS-FILESYSTEM ist) zuzulassen, solange die Servereinträge diejunkt sind. Das ist nun wirklich eine einfach Erweiterung wovon schon fast alles dazu, denn es gibt ja bereits den Lookup bzw. des Servers selbst geprüft werden muss, ob der Storage dort als vorhanden eintragen ist oder nicht. Jetzt müsste das nur so erweitert werden, dass die ganze Liste durchgegangen wird.
Wenn das alles so einfach ist, dann programmiere doch ein eigenes Addon. Das kannst du den anderen wenigen Leuten, die es brauchen einfach über Github/Gitlab zur Verfügung stellen. Die große Masse der Proxmox User ist das garantiert zu viel und brauchen das einfach nicht.
 
  • Like
Reactions: Johannes S
Es gibt immer noch, auch im Proxmox-Team selbst, oft unklare bis falsche Vorstellungen wie ZFS funktioniert. Insbesondere wie ZVOLs und FILESYSTEMs zusammenhängen, dabei ist es nicht so schwierig. In ZFS gibt es zwei Typen von DATASET: VOLUME und FILESYSTEM. Diese kann man sich mit "zfs list -o name,type" anzeigen lassen. Jedes dataset außer dem root-Filesystem, das immer ein Filesystem ist, hat ein Parent-Filesystem (Filesystem nicht dataset). Das Kind erbt dabei die erbbaren Attribute von seinem Parent, z.B. so etwas wie compression und dedup. Insbesondere lebt JEDES ZFS-VOLUME in einem ZFS-Dateisystem, nämlich seinem Parent. Parents können wie gesagt nur Filesystem nicht VOLUME sein. Der Mountpoint eines ZFS-Dateisystems ist davon noch unabhängig, denn er kann separat gewählt werden. Defaultmäßig ist er gleich seinem Namen im Pfad des Parent-Filesystems. Dies dazu, weil jemand von Proxmox auf meinen Bugzilla-Verbesserungsvorschlag meint, ZVOL würden nicht in einem Dataset leben, sondern es sei eine separate Hierarchie was halt falsch ist.

ich nehme an du meinst hier mich ;) ich glaube immer noch dass mein verstaendnis davon wie ZFS funktioniert (intern und bei PVE) ausreicht, um diesen feature request zu beurteilen (und finde den vorwurf "falsche vorstellungen" von einem projekt zu haben, bei dem ich dich schon darauf hingewiesen habe, dass ich upstream contributor bin, ehrlicherweise nicht sehr freundlich) - ich hab auch nicht behauptet das zvols eine separate hierarchie haben, sondern dass sie nicht in einem "filesystem" liegen (der unterschied zwischen "reside in a filesystem" - was du geschrieben hast - und "has a parent dataset" - was du offenbar gemeint hast, und ich ja auch selbst in meiner antwort geschrieben hab?). vielleicht liegts auch an sprachbarrieren dass hier missverstaendnisse entstanden sind..

Ich möchte nochmal auf meinen Vorschlag zurückkommem, doch seitens Proxmox zuulassen, dass man mehrere Einträge für denselben ZFS-Storagenamen (was immer ein ZFS-FILESYSTEM ist) zuzulassen, solange die Servereinträge diejunkt sind. Das ist nun wirklich eine einfach Erweiterung wovon schon fast alles dazu, denn es gibt ja bereits den Lookup bzw. des Servers selbst geprüft werden muss, ob der Storage dort als vorhanden eintragen ist oder nicht. Jetzt müsste das nur so erweitert werden, dass die ganze Liste durchgegangen wird.

das grundprinzip "eine storage definition fuer alle nodes" ist in PVE bewusst gewaehlt, und nicht etwas von dem wir fuer einen nischen use case abweichen werden. das hab ich (und andere) nun schon mehrmals auf unterschiedlichste art versucht zu kommunizieren - die komplexitaet (im code und der langfristigen wartbarkeit, nicht auf user seite, die allermeisten user wuerden dieses feature ja ohnehin nicht nutzen) steht einfach nicht dafuer, zumal ein ganz einfacher workaround besteht, der 90% aller faelle abdeckt - pools und datasets auf verschiedenen nodes gleich benennen (dasselbe gilt fuer LVM VGs, directory pfade, NFS/Samba/Ceph/.. server und viele andere dinge genauso).

nur als beispiel, damit du nicht glaubst ich oder wir waeren irgendwie grundsaetzlich verbohrt - bei hardware mappings besteht diese einfach moeglichkeit ("alles gleich benennen/strukturieren") nicht, deswegen haben wir dort die option eingefuehrt pro node unterschiedliche physische ressourcen als eine logische ressource zu definieren und in einer gast config zu referenzieren.

bei storages geht die kosten/nutzenrechnung unserer meinung nach einfach nicht auf - und in so einem fall ist es unsere (oft undankbare) aufgabe "nein" zu sagen.