H
holgerw
Guest
Hallo,
vielen Dank für die zahlreichen informativen Anmerkungen. Ich habe auch schon einiges nun dazu gelesen:
Es gibt da wohl zwei Wege, Resultat ist das gleiche, so habe ich es in einem Beitrag des engl. FreeBSD-Forums verstanden.
D.h., entweder zfs shares über nfs traditionell einzubinden und diesbezüglich nichts weiter einstellen bei zfs (sharensf ist defaultmäßig deaktiviert) oder sich mit sharensf befassen.
Viele Grüße
Holger
vielen Dank für die zahlreichen informativen Anmerkungen. Ich habe auch schon einiges nun dazu gelesen:
Es gibt da wohl zwei Wege, Resultat ist das gleiche, so habe ich es in einem Beitrag des engl. FreeBSD-Forums verstanden.
D.h., entweder zfs shares über nfs traditionell einzubinden und diesbezüglich nichts weiter einstellen bei zfs (sharensf ist defaultmäßig deaktiviert) oder sich mit sharensf befassen.
Pit, ich habe es so verstanden, dass das zwei Möglichkeiten mit gleicher Auswirkung sind und es da wohl eher um Geschmack geht, als um Vor- und Nachteile.
Okay, das werde ich mal machen, welcher Wert ist denn da sinnvoll? Der Rechner wird neben seiner Funktion als Desktopsystem auch zum Bau größerer lokaler Repos mit poudriere gebraucht.
Viele Grüße
Holger
pit234a
Well-Known Member
Ich habe es so verstanden, dass 'zfs set sharensf' eine Eigenschaft eines Datasets ist. Auch, wenn beide Methoden eine ähnliche oder gar identische exports schaffen, ist es doch ein Unterschied, ob ich ein Verzeichnis frei gebe, oder ein Dataset. Ich muss ja in der klassischen Exports darauf achten, dass ich nicht etwas freigeben möchte, das einen Mountpoint unterhalb meines gewählten export-Verzeichnisses hat. Dass ich nun einem Dataset die Eigenschaft geben kann, dass es sich exportieren soll, erscheint mir ein bemerkenswerter Unterschied, den ich allerdings gar nicht weiter durchdacht habe. Ich wollte es bei der Gelegenheit nur mal anregen, sich den Unterschied näher anzusehen.
Genau so hab ich es auch verstanden - zfs kennt ja letztendlich nur die Datasets und nicht irgendwelche darauf liegenden Verzeichnisstrukturen!
Insofern ist 'exports' und 'zfs set sharensf' noch lange nicht das Gleiche oder gar nur unterschiedliche Syntax, die das Gleiche bewirkt!
Nachtrag:
Auch hier zeigt sich, dass eine gut durchdachte Struktur der Datasets bei zfs ( also eher mehr - als weniger, getragen von Gedanken: was will ich später vielleicht mal mounten und welchen Verzeichnis/Dataset könnte ich andere Eigenschaften geben ( zB Access Time ja/nein, Checksumme ja/nein usw. ) - durchaus Sinn macht
Auch hier zeigt sich, dass eine gut durchdachte Struktur der Datasets bei zfs ( also eher mehr - als weniger, getragen von Gedanken: was will ich später vielleicht mal mounten und welchen Verzeichnis/Dataset könnte ich andere Eigenschaften geben ( zB Access Time ja/nein, Checksumme ja/nein usw. ) - durchaus Sinn macht
KobRheTilla
used register
Doch ist es. Die Datei /etc/exports muss man von Hand editieren, die Datei /etc/zfs/exports wird von den zfs-Tools generiert, wenn das sharenfs-Attribut manipuliert wird.
Wenn zfs_enable in der rc.conf gesetzt ist, erhält der mountd beide Dateien als Quelle für die exports, ansonsten beachtet er nur die /etc/exports.
Generell kann man sagen, dass man zum Export eines ZFS auch die ZFS-Tools nutzen sollte, also das sharenfs-Attribut setzen. Zum Export anderer Dateisysteme editiert man nach wie vor die /etc/exports von Hand.
Rob
chaos
*nix'ler
Wie gesagt, unter der Bedingung, dass man mit einer (generierten) Zeile für die Share in der /etc/zfs/exports auskommt.
Wenn man mehrere Zeilen braucht, dann legt man besser alle in der /etc/exports an. Wegen Übersicht und so.
H
holgerw
Guest
Hallo,
Es läuft dann wohl doch auf bestimmte Anwendungszwecke plus Geschmack hinaus. Aber finde ich gut, verschiedene Wege kennen zu lernen.
Okay, dann befasse ich mich, wie @Vril schon riet, auch mal mit sharenfs
Also ist man mit der traditionellen Methode flexibler, hmmm: Ich bin da Anfänger, lese hier zwei Meinungen, die ich allerdings beide sehr plausibel finde.
Es läuft dann wohl doch auf bestimmte Anwendungszwecke plus Geschmack hinaus. Aber finde ich gut, verschiedene Wege kennen zu lernen.
Ach Leute...
Jedes dataset ist ein eigenes gemountetes Filesystem. Hast du noch nie df oder mount mit ZFS benutzt und mal geguckt, was tatsächlich alles gemountet ist? Dann würde man das doch auf Anhieb sehen und müsste hier nicht Zeug erzählen.
Das Setzen der sharenfs-Eigenschaft auf einem Dataset ist _nichts_ Anderes als dass der Wert der Eigenschaft in /etc/zfs/exports reingekippt wird und der mountd ein Signal kriegt, damit er das neu einliest.
Man muss doch nur mal /etc/rc.d/mountd angucken, wie ichs ganz weit oben schon geschrieben hab. Dann sieht man, dass beide Methoden unter der Kontrolle von mountd stehen.
Dieses Gehampel mit sharenfs ist nur reine Bequemlichkeit, damit man den exports-Eintrag an jedem Dataset an Ort und Stelle hat und nicht mental zwischen der Dataset-Struktur und der exports hin- und herwechseln muss.
Jedes dataset ist ein eigenes gemountetes Filesystem. Hast du noch nie df oder mount mit ZFS benutzt und mal geguckt, was tatsächlich alles gemountet ist? Dann würde man das doch auf Anhieb sehen und müsste hier nicht Zeug erzählen.
Das Setzen der sharenfs-Eigenschaft auf einem Dataset ist _nichts_ Anderes als dass der Wert der Eigenschaft in /etc/zfs/exports reingekippt wird und der mountd ein Signal kriegt, damit er das neu einliest.
Man muss doch nur mal /etc/rc.d/mountd angucken, wie ichs ganz weit oben schon geschrieben hab. Dann sieht man, dass beide Methoden unter der Kontrolle von mountd stehen.
Dieses Gehampel mit sharenfs ist nur reine Bequemlichkeit, damit man den exports-Eintrag an jedem Dataset an Ort und Stelle hat und nicht mental zwischen der Dataset-Struktur und der exports hin- und herwechseln muss.
hab ich was anderes behauptet???
Was meinst Du mit "Zeug erzaehlen" denn konkret?
pit234a
Well-Known Member
ich habe, wie schon erklärt, nicht weiter darüber nachgedacht und es noch gar nicht selbst gemacht. Es kommt mir aber weniger auf den Mechanismus des Exportierens an.
Vielleicht mache ich mal ein Beispiel.
Angenommen, es gibt drei User, User1, User2, User3 und ich will für jeden dessen $HOME exportiern.
Wenn ich nun drei Datasets mit /usr/home/User1 ... /usr/home/User3 habe und jeweils sharenfs nutze, stellt sich jeder eine klare Reaktion des Systems vor.
Was aber, wenn ich nun in dem Fall eine klassische /etc/exports und gar kein sharenfs wähle und /usr/home frei gebe?
Müssen Datasets eigentlich immer gemountet werden? Ich meine mich an eine entsprechende Eigenschaft zu erinnern, die aber gesetzt sein muss und wohl auch unterlassen werden kann. Falls dem so ist, was, wenn ich ein nicht gemountetes Dataset mit sharenfs exportiere?
Was, wenn ich auf einem Dataset einen Mountpoint liegen habe und dort ein Medium mit Daten eingebunden ist?
Also, ich meine eigentlich alle Fälle, die nicht identisch sind mit "exportiere genau ein Dataset". Dabei ist sicher egal, ob klassisch oder sharenfs.
Ich vermute aber Unterschiede in anderen Punkten, weil eine Eigenschaft eines Datasets eben genau auf diesem liegt, eine Freigabe aus dem Dateisystem aber nicht unbedingt an ein Dataset gebunden ist. Letztere kann höher oder tiefer im Dateibaum liegen.
Und dann kann man sich eben auch Mischformen vorstellen, es muss ja nicht alles im System ZFS sein. Ich habe zB früher FreeBSD auf UFS gehabt (habe immer noch auf einem PC) und dann Daten auf ZFS, die ich exportieren wollte und solche Konstruktionen machen für mich auch heute noch durchaus Sinn, in speziellen Konstellationen. Wenn ich recht erinnere, habe ich damals Freigaben aus dem UFS einrichten müssen und diese haben das darunter liegende ZFS nicht automatisch mit freigegeben. Ich brauchte also noch eine zusätzliche Freigabe für mein ZFS Dataset.
Vielleicht mache ich mal ein Beispiel.
Angenommen, es gibt drei User, User1, User2, User3 und ich will für jeden dessen $HOME exportiern.
Wenn ich nun drei Datasets mit /usr/home/User1 ... /usr/home/User3 habe und jeweils sharenfs nutze, stellt sich jeder eine klare Reaktion des Systems vor.
Was aber, wenn ich nun in dem Fall eine klassische /etc/exports und gar kein sharenfs wähle und /usr/home frei gebe?
Müssen Datasets eigentlich immer gemountet werden? Ich meine mich an eine entsprechende Eigenschaft zu erinnern, die aber gesetzt sein muss und wohl auch unterlassen werden kann. Falls dem so ist, was, wenn ich ein nicht gemountetes Dataset mit sharenfs exportiere?
Was, wenn ich auf einem Dataset einen Mountpoint liegen habe und dort ein Medium mit Daten eingebunden ist?
Also, ich meine eigentlich alle Fälle, die nicht identisch sind mit "exportiere genau ein Dataset". Dabei ist sicher egal, ob klassisch oder sharenfs.
Ich vermute aber Unterschiede in anderen Punkten, weil eine Eigenschaft eines Datasets eben genau auf diesem liegt, eine Freigabe aus dem Dateisystem aber nicht unbedingt an ein Dataset gebunden ist. Letztere kann höher oder tiefer im Dateibaum liegen.
Und dann kann man sich eben auch Mischformen vorstellen, es muss ja nicht alles im System ZFS sein. Ich habe zB früher FreeBSD auf UFS gehabt (habe immer noch auf einem PC) und dann Daten auf ZFS, die ich exportieren wollte und solche Konstruktionen machen für mich auch heute noch durchaus Sinn, in speziellen Konstellationen. Wenn ich recht erinnere, habe ich damals Freigaben aus dem UFS einrichten müssen und diese haben das darunter liegende ZFS nicht automatisch mit freigegeben. Ich brauchte also noch eine zusätzliche Freigabe für mein ZFS Dataset.
H
holgerw
Guest
Hallo,
das traditionelle Verfahren ist ordnerbezogen, das mit sharenfs ist datasetbezogen.
Die traditionelle Methode bietet zunächst einmal mehr Flexibilität, die bekomme ich bei der sharenfs-Methode nur dadurch, indem ich diverse weitere Subdatasets anlege, die ich aber wiederum mit unterschiedlichen zfs-Optionen versehen kann (wenn ich dafür denn überhaupt Bedarf habe).
Ich finde gut, dass man sich diese unterschiedlichen Ansätze klar macht.
Viele Grüße
Holger
das traditionelle Verfahren ist ordnerbezogen, das mit sharenfs ist datasetbezogen.
Die traditionelle Methode bietet zunächst einmal mehr Flexibilität, die bekomme ich bei der sharenfs-Methode nur dadurch, indem ich diverse weitere Subdatasets anlege, die ich aber wiederum mit unterschiedlichen zfs-Optionen versehen kann (wenn ich dafür denn überhaupt Bedarf habe).
Ich finde gut, dass man sich diese unterschiedlichen Ansätze klar macht.
Viele Grüße
Holger
Das spielen auch die Limitierungen des alten MOUNT-Protokolls mit hinein, was in NFSv2 und NFSv3 verwendet wird. Das erlaubt nämlich pro Dateisystem oder bei ZFS Dataset nur eine einzige Freigabe pro Client. Angenommen /usr ist ein Dataset. Ich kann /usr/src vor client1.local und /usr/obj für client2.local freigeben, aber nicht /usr/src und /usr/obj für client3.local. Außerdem muss zumindest theoretisch der ganze Verzeichnisbaum von / an freigegeben werden. In unserem Beispiel also / und /usr, /usr alleine reicht nicht. Allerdings haben viele praktische Implementierungen, auch FreeBSDs und Linux, diese Einschränkung nicht mehr. NFSv4 ist dann eine ganz andere Suppe. Es nutzt das MOUNT-Protokoll gar nicht mehr und hat daher auch seine Beschränkungen nicht.
Ja, sharensf ist exports - und vorallem die Eigenschaft eines zfs Datasets.
Und! exports ist nicht sharensf weil in der exports mit der option -alldirs es möglich wird, auch Unterverzeichnisse als Mountpunkte festzulegen
KobRheTilla
used register
Ich wünsche mir, dass in Zukunft auf Basis der Fakten (Systemdokumentation und Quelltexte) argumentiert wird und nicht aus dem Bauch heraus. In den Manpages ist es eindeutig beschrieben:
Ebenso hätten die ersten Hinweise von TCM und chaos hinsichtlich der exports/mountd ruhig mal für voll genommen werden können. Das ist doch das schöne an einem skriptbasierten rc-System: man kann einfach mal nachsehen, was genau passiert.
Diese Diskussion war in großen Teilen mal wieder nutzlos.
Rob
Danke