OpenBSD Hackathon 2005

simonz

OpenBSD Fanboy
oenone schrieb:
seit wann nutzt knoppix den openbsd kernel?
Sorry, da hab ich mich wohl etwas falsch ausgedrückt.
Ich meinte: warum haut OpenBSD unionfs aus dem Kernel, obwohl es bei Knoppix, soweit ich weiß, ganz gut funktioniert?
 
ich verstehe dich immer noch nicht richtig...

du fragst also, warum Kernel XY das Feature Z rauswirft, obwohl Feature C beim Kernel AB funktioniert?

unionfs bei OpenBSD ist nicht das gleiche wie unionfs bei Linux.

Außerdem stehen die Gründe in dem von dir angegebenen Artikel deutlich drin:
http://kerneltrap.org/node/5184

auf bald
oenone
 
oenone schrieb:
du fragst also, warum Kernel XY das Feature Z rauswirft, obwohl Feature C beim Kernel AB funktioniert?

unionfs bei OpenBSD ist nicht das gleiche wie unionfs bei Linux.
Hm, das hatte ich nicht bedacht. Es geht also um die jeweilige Implementierung im jeweiligen Kernel.
Also ist die OpenBSD Variante nicht zufriedenstellend gewesen und wurde deshalb vorerst rausgenommen.

Alles klar, ich verstehe und entschuldige mich für die Missverständnisse.
 
PlantMan schrieb:
Sorry, da hab ich mich wohl etwas falsch ausgedrückt.
Ich meinte: warum haut OpenBSD unionfs aus dem Kernel, obwohl es bei Knoppix, soweit ich weiß, ganz gut funktioniert?

Das unionfs, was bei Knoppix drin ist, ist etwas ganz anderes (angesehen davon, dass man ehe keine Fileystem-Implementationen verschiedener Betriebssysteme einfach vergleichen kann).

Knoppix nutzt das hier:
http://www.fsl.cs.sunysb.edu/project-unionfs.html

Das hat wenig mit dem nullfs/unionfs unter BSD zu tun (abgesehen von geklauten Namen).

Ersteres kann verschiedene Dateisysteme überlappen und als ein ganzes darstellen (z.B. original sourcen von CD mit lokalen Patches erscheinen als komplett gepatchte sourcen).

Letzteres erlaubt es dateisysteme mehrfach zu mounten und wird oft zusammen mit FreeBSD Jails genutzt (z.B. hat man /usr/ports nur einmal da, mountet es aber in jede Jail rein).
 
PlantMan schrieb:
Hm, das hatte ich nicht bedacht. Es geht also um die jeweilige Implementierung im jeweiligen Kernel.
Also ist die OpenBSD Variante nicht zufriedenstellend gewesen und wurde deshalb vorerst rausgenommen.

Ich kann mir ehrlich gesagt auch unter Linux keine zufriedenstellende Loesung ohne krude Hacks vorstellen.

Z.B.: Du bis im Rootverzeichnis des union-gemounteten Filesystem. Welchen Inode hat .?

Oder: Du loeschst im "oberen" Filesystem eine Datei oder eine ganze Verzeichnishierarchie. Diese darf im "unteren" natuerlich nicht angefasst werden. Die Implemeniterung (in BSD) hat dafuer sehr ekelhafte Hacks verwendet. IIRC wurden dafuer im oberen Filesystem whiteout Entries angelegt, also spezielle Verzeichniseintraege, die ungefaehr bedeuteten "Dieses File als nicht-existent betrachten, auch wenn es im unteren Filesystem enthalten ist". Und was machst Du, wenn das Verzeichnis anschliessend wieder angelegt wird?

You see? Das laesst sich alles nicht vernuenftig implementieren, zumal die ganzen Hacks ja im UFS (bzw. spaeter FFS) selbst enthalten sein muessen.

ps: alle technischen Angaben ohne Gewaehr -- ist schon ein Weilchen her, dass ich "Design & Implementation of 4.4. BSD" gelesen habe.
 
kili schrieb:
ps: alle technischen Angaben ohne Gewaehr -- ist schon ein Weilchen her, dass ich "Design & Implementation of 4.4. BSD" gelesen habe.

Muss es wohl sein, sonst haettest du ja "The Design and Implementation of the FreeBSD Operating System" gelesen... *scnr* :D
 
busfahrer schrieb:
Muss es wohl sein, sonst haettest du ja "The Design and Implementation of the FreeBSD Operating System" gelesen... *scnr* :D

Na, soo lange ist es wirklich nicht her (ca. ein Jahr oder so).

Uebrigens ist IIRC TDAIOT FreeBSD OS nicht einfach eine "Portierung" des Klassikers fuer FreeBSD, sondern schon ein komplett eigenes Buch. Mein ich zumindest mal irgendwo gelesen zu haben,. evtl. so gar hier.

Ciao,
Kili, der gerne TDAIOT OpenBSD OS haette :p
 
Z.B.: Du bis im Rootverzeichnis des union-gemounteten Filesystem. Welchen Inode hat .?
Ist doch klar, für Dinge die es in beiden Layern gibt wird das upper genommen.

Oder: Du loeschst im "oberen" Filesystem eine Datei oder eine ganze
Verzeichnishierarchie. Diese darf im "unteren" natuerlich nicht angefasst werden. Die Implemeniterung (in BSD) hat dafuer sehr ekelhafte Hacks verwendet. IIRC wurden dafuer im oberen Filesystem whiteout Entries angelegt, also spezielle Verzeichniseintraege, die ungefaehr bedeuteten "Dieses File als nicht-existent betrachten, auch wenn es im unteren Filesystem enthalten ist".
Du hast Recht, so ist das natürlich ekelhaft, es gäbe die Möglichkeit erstmal eine sauberes read-only unionfs zu machen, oder der löschvorgang wird erfolgreich beendet und es passiert einfach nichts.

Und was machst Du, wenn das Verzeichnis anschliessend wieder angelegt wird?
Das gleiche wie oben.
IMO sollte readonly sehr einfach funktionieren. Aber du hast schon recht, eine richtig saubere Lösung gibt es wahrscheinlich nicht :(

Male, der auch TDAIOT 4.4BSD gelesen hat, und das neue nicht in der Uni-Bib findet :(
 
Teilzusammenschnitt mit Unterschieden.

Ja, Theo kommt sehr strange an, so plüschig und weich :D
 
Zurück
Oben