Kombination: nullfs und unionfs

[soul_rebel]

Kann jemand bestätigen, dass sich nullfs und unionfs-mounts sowohl miteinander als auch untereinander nicht kombinieren lassen?

Hintergrund:

Ich habe zur Verwaltung von Jails so meine eignen Skriptchen geschrieben, die Teile des Basissystems über ro-nullfs-mounts einbinden, damit ich nicht die bases der jails alle einzeln mit updaten muss. Die Jail-spezifischen Änderungen / anderen Dateien würde ich gerne über unionfs in einem seperaten Verzeichnis abfangen.
Neben der Einfachheit der Updates, hat das den Vorteil, dass man sehr schnell sieht wenn in einem Jails etwas verändert wurde.

Nur leider geht es nicht. Sobald ich ein mount_unionfs mache, verschwinden unterhalb von uniondir die mountpunkte der nullfse bzw. deren Inhalte.

Das scheint mir im Widerspruch zu sein zu

The union file system manipulates the namespace, rather than individual file systems. The union operation applies recursively down the directory tree now rooted at uniondir Thus any file systems which are mounted under uniondir will take part in the union operation. This differs from the union option to mount(8) which only applies the union operation to the mount point itself, and then only for lookups.

Das tritt bei mir bei mehreren Rechnern auf... kann das jemand mal bei sich doppelchecken? [1]
Oder hab ich hier etwas falsch verstanden?

%cd /tmp/
%mkdir TEST1
%mkdir TEST1/SUB
%mount_nullfs /bin/ /tmp/TEST1/SUB/
%mkdir /tmp/TEST2
%ls /tmp/TEST1/SUB/
[          chmod      dd         ed         kenv       ls         pgrep      rcp        rmail      sleep      test
cat        cp         df         expr       kill       mkdir      pkill      realpath   rmdir      stty       unlink
chflags    csh        domainname getfacl    link       mv         ps         red        setfacl    sync       uuidgen
chio       date       echo       hostname   ln         pax        pwd        rm         sh         tcsh
%mount_unionfs /tmp/TEST2 /tmp/TEST1
%ls /tmp/TEST1/SUB/
%

 

[Yamagi]

Die werden sich nicht kombinieren lassen, allerdings habe ich es nicht selbst getestet. Sowohl Nullfsd als auch Unionfs sind sogenannte "stacked Filesystems", ein Konzept was das FreeBSD VFS bis heute (anders als zum Beispiel Linux) nicht wirklich vorsieht. Sie Aussage aus der Manpage bezieht sich fast unter Garantie noch auf das alte, nie wirklich funktionierende Unionfs und nicht auf die komplette Reimplementierung durch Goto Daichi. Um ein wenig technischer zu werden, normalerweise funktioniert es so: Dateisystem (UFS) -> Vnode. Gestackte Dateisysteme wie Nullfs bauen darein eine Schleife: Dateisystem (UFS) -> Vnode -> Nullfs -> Vnode. Möchtest du zwei Dateisysteme aufeinanderstapeln ist das Problem, dass die richtige Vnode abgreifen musst, was nicht garantiert werden kann. Unionfs und Nullfs funktionieren zwar beide parallel, sie blockieren sich aber. Du sieht jeweils nur eines von beiden. Einen Test mache ich heute Abend gern.

 

[Raptor]

Eigentlich habe ich es sogar exakt so unter einem semi-produktivem System laufen. Unter FreeBSD 7.0 mit ein paar Patches lief das richtig genial, unter 7.1 habe ich plötzlich richtig Probleme. Nach ungewisser Laufzeit kommen Prozesse in einen Z oder D State, ich kann sie nicht killen, Zugriffe auf die Jails (auch jexec in ein Jail hinein) gehen sofort in den State und dadurch: nicht einmal mehr ein Reboot möglich. Wenn mir jemand _irgendwelche_ Tipps geben kann, warte ich auch gern mit weiteren Details auf

Aber Back to Topic:

/dev/ufs/root on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ufs/usr on /usr (ufs, local, noatime, soft-updates)
/dev/ufs/home on /usr/home (ufs, local, noatime, soft-updates)
/usr/jails on /usr/shadow (nullfs, local, noatime, read-only)
<below>:/usr/jails/.base on /usr/jails/auth (unionfs, local, noatime)
devfs on /usr/jails/auth/dev (devfs, local)
<below>:/usr/jails/.base on /usr/jails/monitor (unionfs, local, noatime)
devfs on /usr/jails/monitor/dev (devfs, local)
[snip für etwa 10 weitere]

unter /usr/shadow ist damit ein ro abbild der Änderungen der Jails.

find /usr/shadow/$jail ! -empty ! -type d
listet dementsprechend komfortabel alle Änderungen hübsch auf.
Das wars doch was du meintest, oder hab ich dich falsch verstanden?

 

[soul_rebel]

Eigentlich habe ich es sogar exakt so unter einem semi-produktivem System laufen. Unter FreeBSD 7.0 mit ein paar Patches lief das richtig genial, unter 7.1 habe ich plötzlich richtig Probleme. Nach ungewisser Laufzeit kommen Prozesse in einen Z oder D State, ich kann sie nicht killen, Zugriffe auf die Jails (auch jexec in ein Jail hinein) gehen sofort in den State und dadurch: nicht einmal mehr ein Reboot möglich. Wenn mir jemand _irgendwelche_ Tipps geben kann, warte ich auch gern mit weiteren Details auf

Hört sich mies an

Aber Back to Topic:

/dev/ufs/root on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ufs/usr on /usr (ufs, local, noatime, soft-updates)
/dev/ufs/home on /usr/home (ufs, local, noatime, soft-updates)
/usr/jails on /usr/shadow (nullfs, local, noatime, read-only)
<below>:/usr/jails/.base on /usr/jails/auth (unionfs, local, noatime)
devfs on /usr/jails/auth/dev (devfs, local)
<below>:/usr/jails/.base on /usr/jails/monitor (unionfs, local, noatime)
devfs on /usr/jails/monitor/dev (devfs, local)
[snip für etwa 10 weitere]

unter /usr/shadow ist damit ein ro abbild der Änderungen der Jails.

find /usr/shadow/$jail ! -empty ! -type d
listet dementsprechend komfortabel alle Änderungen hübsch auf.
Das wars doch was du meintest, oder hab ich dich falsch verstanden?

Jein. Also dein /usr/jails/.base enthält an sich ja keine nullfs-mountpunkte, oder habe ich das falsch erkannt? Es ist eine "richtige " Kopie der base? Ich wollte die base ja nicht kopieren, sondern auch in den Jails die Ordner des Hosts nehmen...

Und unterhalb von /usr/jails/monitor kannst ja jetzt z.B. nicht mehr /usr/home mit ro einbinden...

 

[Raptor]

Ah, ich verstehe. Ja, .base ist bei mir ein eigenes System, ich wollte Host und Jails strikt trennen. Aber es sollte ja nichts dagegensprechen, /etc usw. per nullfs ro dahin zu mounten. Der Komplexität ist da ja keine Grenze gesetzt Beachten sollte man aber wahrscheinlich vfs.numvnodes bzw. kern.maxvnodes. Ich schätze das pro gestacktes fs natürlich pro Datei eine vnode verbraten wird. Bei mir kurzfristig 250k... leider war das aber auch nicht der Grund fürs abnippeln.

 

[soul_rebel]

Ah, ich verstehe. Ja, .base ist bei mir ein eigenes System, ich wollte Host und Jails strikt trennen. Aber es sollte ja nichts dagegensprechen, /etc usw. per nullfs ro dahin zu mounten. Der Komplexität ist da ja keine Grenze gesetzt

Anscheinend ja schon. Das ist ja das Problem (s.o.)

 

[nakal]

Ich würde Dir wirklich empfehlen, sich nach dem Handbuch zu richten und auf unionfs vollständig zu verzichten. Das läuft bei mir tadellos.

 

[soul_rebel]

Ich würde Dir wirklich empfehlen, sich nach dem Handbuch zu richten und auf unionfs vollständig zu verzichten. Das läuft bei mir tadellos.

Mein alter setup, nutzt ja auch nur nullfs und kein unionfs, das hat ja auch funktioniert, war aber nicht so übersichtlich, wie es hätte sein können.

rc.d zu nutzen, make world und ports kommen für das szenario nicht in Frage.

Ich denke, ich werde eine extra Kopie der Base machen und die per unionfs drunter mounten, so wie raptor das macht. Da habe ich den extra Aufwand eines zweiten base-ordners, aber spar mir die unzähligen nullfs-mounts und die extra-etc-Verzeichnisse...

 

[nakal]

Ich weiß nicht inwiefern Du Dir das durchgelesen hast, aber da erstellt man eine Master-Jail, die als rootfs dient und in allen Jails read-only gemountet wird, wenn sie erstellt werden. Dann mountet man in jede Jail unter /s ein read-write-Verzeichnis und da biegt man alle Links hin, die ein writeable-Verzeichnis benötigen.

/etc ist zum Beispiel unter jeder Jail varierbar, da gelinkt nach /s/etc. Das ist auch i.A. sinnvoll.

Die Master-Jail kannst Du mit dem Basissystem aktualisieren, aber musst Du nicht (auch wenn es hier geschenkt ist), wenn Du nicht willst. (Das klappt so lange wie der Kernel stabil bleibt (ioctl etc dürfen sich nicht strukturell ändern).)

 

[soul_rebel]

Hehe, ich hab mir das schon durchgelesen, aber ich kann überhaupt keinen Vorteil ggü. Raptors Setup erkennen.

Wenn ich schon einen extra base-ordner habe gehts doch auch mit unionfs, ist imo übersichtlicher.

 

[nakal]

Ok. Da hab ich wohl mit jemand anders im Chat vorhin geredet, der meinte, dass unionfs das ganze System instabil macht. Ich dachte, das wäre die Motivation Deines Postings, das unionfs los zu werden.

 

[soul_rebel]

Nene, ich wollte schon unionfs nehmen, ich wollte nur den untergrund den ich mit unionfs den jails anbiete mit nullfs zusammenschustern.
Das klappt nicht.

Ich werde, wegen der eindeutig anderslautenden Man-Seite wohl ein PR schreiben und micht erstmal mit Raptors Lösung zufrieden geben. Hoffentlich hat die dann nicht diese Instabilitätsprobleme....

 

[Yamagi]

Moment mal. Also, Unionfs wurde vom Sprung von FreeBSD 6.2 auf 6.3 und auf 7.0 komplett reimplementiert, da der alte Code einfach nicht zu Retten war. Die Manpage ist allerdings nicht aktualisiert worden. Sie ist also schlicht falsch. Der neue Code funktioniert im Gegensatz zum alten (panic: ...) grundsätzlich. Leider sind diese "Stacked Filesystems" wie schon oben gesagt nicht gerade FreeBSDs Stärke. Ich kann hier auf meinem 7.1 unionfs nicht einmal mounten, er macht es schlicht nicht. Siehe dazu auch http://people.freebsd.org/~daichi/unionfs/ Bei Fragen würde ich GOTO Daichi direkt schreiben, er ist eigentlich sehr entgegenkommend.

EDIT: Jetzt mountet er es plötzlich doch. Hä?!

 

[soul_rebel]

Ich find PRs schreiben eigentlich immer besser. Zumindest bei den projekten wo ich drin stecke, hilft mir ein Tracker-Item viel mehr als ein E-Mail oder ein Foren-Post irgendwo... schließlich hat man da alles an einem Platz und auch eine Übersicht über alle Issues.

Aber wenn du meinst, dass er lieber E-Mails bekommt dann wende ich mich an ihn persönlich

 

[Raptor]

@nakal: wir hatten im Chat geredet und ja, die Lösung aus dem Handbuch ist nur wenig mehr komplizierter

@soul_rebel: wie gesagt, _prinzipiell_ ist es stabil, unter 7.0 lief der server etwa 3 Monate mit mehrere Domänen für Mail(dovecot+postfix+dspam), XMPP, Datenbanken, Web (nginx+php-fpm) durchgängig und fehlerfrei. Wieder zu bemerken: mit dem Unionfs aus 7-STABLE und einem zusätzlichen Patch von irgendeinem Posting von Daichi bezüglich devfs, bzw. mfs auf /tmp.
Jetzt ist er auf 7.1 mit dem dabei enthaltenen unionfs und _eigentlich_, soweit ich das beurteilen kann, genau die vorher eingespielten Patches innehat... und diesen schwer reproduzierbaren Bug herrvorruft. Ich würde daher momentan nicht empfehlen, es bei einem kritischen System so einzusetzen. Wenn der Server in den von mir beschriebenen State geht, hilft nur noch ein hard(!) reset des Serverproviders. Glücklicherweise ist UFS und die laufenden Apps unglaublich fehlerresistent

 

[Yamagi]

Es ist dir überlassen. PR arbeitet er - im Gegensatz zu einigen anderen Herren - eigentlich immer schnell und freundlich ab. Ich selbst spreche nur gern direkt mit den Personen, da ich Bugtracker nicht mag.