Clemens Hermann <haribeau(at)gmx.de> wrote:
> Am 07.09.2002 um 12:26:12 schrieb Oliver Fromme:
> > Name-based virtual hosts ist
> > da prinzipbedingt nicht drin.
>
> ausser man verwendet z.B. den apache als inverse proxy und
> schickt damit die Requests in den passenden jail.
Stimmt, an diese Möglichkeit hatte ich gar nicht gedacht.
Gute Idee.
(Nur SSL geht damit natürlich nicht, aber das ist ja eh
klar.)
> > Prinzipiell wird natürlich aller Code geshared, der aus
> > denselben Dateien kommt (Binaries, Shared-libraries). Wenn
> > Du hundert Apachen startest (das gleiche Binary), dann ist
> > der Code nur einmal im Speicher. Das funktioniert auch
> > dann, wenn es Hardlinks sind (d.h. verschiedene Namen der
> > gleichen Datei, also gleiche inode-Nummer; siehe »ls -i«).
>
> gilt aber vermutlich nicht für lokale NFS-mounts, oder?
Da hast Du (leider!) recht. Lokale (Loopback-) NFS-Mounts
haben eine Reihe von Vorteilen, aber die Tatsache, daß Bi-
naries nicht geshared werden, macht es leider nicht beson-
ders skalierbar.
Das Problem ist, daß das VM-System sich an vnodes orien-
tiert. Zwei Binaries mit gleicher Device-Nummer _und_
gleicher inode-Nummer haben den gleichen vnode im Kernel,
werden also als »gleich« angesehen (vereinfacht ausge-
drückt), aber zwei verschiedene NFS-Mounts führen zu ver-
schiedenen Device-Nummern. Die Information über die ur-
sprüngliche Device-Nummer geht durch das NFS-Protokoll
verloren. Dies wirkt sich nicht nur negativ auf das Sharen
von Codepages aus, sondern auch auf das Cachen.
Eine weitere Möglichkeit wäre NULLFS (mount_null(8)), aber
dies ist leider unter FreeBSD 4 nicht stabil nutzbar. :-(
Gruß
Olli
-- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Sat 07 Sep 2002 - 15:31:40 CEST