Moin,
Es geht um mehrer NASen!
Ist-Zustand 1:
poolname : Pool01 mit einem Vdev (Raidz3)
2 Main-Datasets auf dem Pool (Sichern & Sonstiges) sowie mehrere Child-Datasets
Ist-Zustand 2:
poolname : Pool01 mit einem Vdev (Raidz2)
1 Main-Dataset auf dem Pool (XXX)
(ein weiteres Dataset soll noch hinzukommen, nämlich das Backup/ die Replikation von System 1)
Wie werden vorhandene Datasets beim Pool-Import behandelt / eingebunden?
Als Child-Datasets eines automatisch neu angelegten Root-Datasets (<Poolname>), wobei bereits angewendete ACLs erhalten bleiben, oder werden die ACLS verworfen und das Dataset als Root-Dataset eingebunden, dann natürlich nicht mit dem Poolnamen versehen. Wobei dieses nicht möglich wäre bei System 1.
Hintergrund:
FreeNAS legt beim erstellen eines Pools (from Scratch) ein Root-Dataset mit dem Poolnamen an, auf diesem werden auch die Homeverzeichnisse der FreeNAS-User angelegt und dieses Dataset unterstütz keine ACLs.
ACLs werden erst von Child-Datasets unterstützt.
XigmaNAS ist hier etwas "puristischer" in Einzelschritten, man legt erst das VDEV an, erstellt dann einen Pool mit diesem VDEV (oder auch mehreren) an. Bereits jetzt könnte man den Pool ohne angelegte Datasets oder Volumes (ZVOL) nutzen (/mnt/<POOLNAME>) - allerdings ohne Kompression, Deduplikation oder ACLs. (Hatte ich fälschlicherweise vor einigen Jahren so gemacht.)
Auf dem Pool werden dann Datasets (/mnt/<POOLNAME>/<DATASETNAME>) und/oder Volumes (/dev/zvol/<POOLNAME>/File:<ZVOLTNAME>) angelegt
Achja, falls es interessiert warum ich wechseln möchte: Die ZFS Replikation (Send / Receive) zwischen Systemen ist bei FreeNAS einfach über die GUI einzurichten, bei XigmNAS nur in der Shell oder als Script möglich, sämtliche Scripte die ich gefunden habe, können kein NETCAT - auf verschlüsseltes SSH kann ich im lokalen Netzwerk verzichten.
Mit der Shell / Kommandozeile und irgendwelchen Programmierten Scripts, die ich eh nur zum Teil verstehe, stehe ich nach Möglichkeit auf Kriegsfuß, ich stehe auf dem Standpunkt, daß das in heutiger Zeit nicht mehr notwendig sein muß - wahrscheinlich trete ich damit wieder einen Shitstorm los, das geht mir aber sonstwo vorbei.
Ja, es mag 0,1% spezielle Anwendungsfälle / Konstellationen geben, wo die Shell das mächtigere Werkzeug ist, für die übrigen 99,9% reichen die Möglichkeiten einer GUI aus - PUNKT.
Es geht um mehrer NASen!
Ist-Zustand 1:
poolname : Pool01 mit einem Vdev (Raidz3)
2 Main-Datasets auf dem Pool (Sichern & Sonstiges) sowie mehrere Child-Datasets
Ist-Zustand 2:
poolname : Pool01 mit einem Vdev (Raidz2)
1 Main-Dataset auf dem Pool (XXX)
(ein weiteres Dataset soll noch hinzukommen, nämlich das Backup/ die Replikation von System 1)
Wie werden vorhandene Datasets beim Pool-Import behandelt / eingebunden?
Als Child-Datasets eines automatisch neu angelegten Root-Datasets (<Poolname>), wobei bereits angewendete ACLs erhalten bleiben, oder werden die ACLS verworfen und das Dataset als Root-Dataset eingebunden, dann natürlich nicht mit dem Poolnamen versehen. Wobei dieses nicht möglich wäre bei System 1.
Hintergrund:
FreeNAS legt beim erstellen eines Pools (from Scratch) ein Root-Dataset mit dem Poolnamen an, auf diesem werden auch die Homeverzeichnisse der FreeNAS-User angelegt und dieses Dataset unterstütz keine ACLs.
ACLs werden erst von Child-Datasets unterstützt.
XigmaNAS ist hier etwas "puristischer" in Einzelschritten, man legt erst das VDEV an, erstellt dann einen Pool mit diesem VDEV (oder auch mehreren) an. Bereits jetzt könnte man den Pool ohne angelegte Datasets oder Volumes (ZVOL) nutzen (/mnt/<POOLNAME>) - allerdings ohne Kompression, Deduplikation oder ACLs. (Hatte ich fälschlicherweise vor einigen Jahren so gemacht.)
Auf dem Pool werden dann Datasets (/mnt/<POOLNAME>/<DATASETNAME>) und/oder Volumes (/dev/zvol/<POOLNAME>/File:<ZVOLTNAME>) angelegt
Achja, falls es interessiert warum ich wechseln möchte: Die ZFS Replikation (Send / Receive) zwischen Systemen ist bei FreeNAS einfach über die GUI einzurichten, bei XigmNAS nur in der Shell oder als Script möglich, sämtliche Scripte die ich gefunden habe, können kein NETCAT - auf verschlüsseltes SSH kann ich im lokalen Netzwerk verzichten.
Mit der Shell / Kommandozeile und irgendwelchen Programmierten Scripts, die ich eh nur zum Teil verstehe, stehe ich nach Möglichkeit auf Kriegsfuß, ich stehe auf dem Standpunkt, daß das in heutiger Zeit nicht mehr notwendig sein muß - wahrscheinlich trete ich damit wieder einen Shitstorm los, das geht mir aber sonstwo vorbei.
Ja, es mag 0,1% spezielle Anwendungsfälle / Konstellationen geben, wo die Shell das mächtigere Werkzeug ist, für die übrigen 99,9% reichen die Möglichkeiten einer GUI aus - PUNKT.
