Post by Joe KotroczoIn welcher Unix-Gruppe sind denn AFP-Shares ontopic?
<http://www.de-soc-mac.de/de.comp.sys.mac.lokale-netze/> ;-)
Vielleicht kann mir dann ja jemand weiterhelfen.
Weiss jemand was eine CNID DB ist?
CNID == "Catalog Node ID". Gibt's auch in HFS(+) und bedeutet, daß jede
Datei und jeder Ordner eine eindeutige ID haben. Der Grund dafür: Am Mac
gibt's nicht nur starre Referenzierung anhand absoluter Pfade sondern
auch sowas wie "Greif auf die Datei mit dem Namen »Blubb.txt« im Ordner
mit der CNID 34897 zu". Das Nette daran: Wie der Ordner heißt oder wo er
liegt, ist völlig schnurz bedingt dadurch, daß die CNID konsistent
bleibt, wenn man ihn umbenannt oder verschiebt.
Zusammenhang mit AFP-Servern? Auch die müssen ein CNID-Schema korrekt
implementieren. Netatalk hat das vor Version 2.0 falsch gemacht (siehe
[1]). Mit 2.0 sind Datenbank-gestüzte Ansätze dazu gekommen, die die
CNID-Verwaltung mittels BerkeleyDB (eine OpenSource-Datenbank-Lösung)
abfeiert.
Der cnid_dbd ist ein Daemon, der auf der einen Seite mit den
verschiedenen afpsrv-Prozessen kommuniziert, die per AFP mit den Macs
sprechen. Und sich auf der anderen Seite darum kümmert, daß in der
CNID-Datenbank die Einträge konsistent bleiben.
Was da konkret bei Dir schiefläuft, weiß ich nicht (bin aus der
Netatalk-Entwicklung seit über 5 Jahren so gut wie raus). Insofern würde
ich Dir empfehlen, die "netatalk-users" Mailingliste aufzusuchen:
<http://marc.info/?l=netatalk&r=1&w=2>
<https://lists.sourceforge.net/lists/listinfo/netatalk-admins>
Dort helfen sowohl erfahrene User als auch die Entwickler mit. Ist
definitiv die erste Adresse (außer Du holst Dir kommerziellen Support
direkt bei den Entwicklern: http://www.netafp.com/)
Gruss,
Thomas
[1] Ich zitier jetzt der Einfachheit halber einen eigenen Artikel aus
'nem Linux-Magazin-Netzwerk-Sonderheft von 2004, der kurz vor dem
Release von Netatalk 2.0 entstand, der entgegen der damaligen
Vereinbarung leider nicht mehr online steht:
»Ein anderes Thema ist die Art und Weise, wie die CNIDs auf dem
Server gespeichert werden. Für Mac-Clients ist es eminent wichtig,
dass die CNIDs auf einem Server korrekt verwaltet werden - dank des
Finders in Mac OS X 10.3 gilt dies sogar wieder verschärft. Netatalk
verfolgte in der Vergangenheit verschiedene Ansätze. Neben einem
simplen Hochzählen der IDs je »afpd«-Prozess wurde versucht, die IDs
des darunter liegenden Dateisystems für die ID-Berechnung
einzusetzen. Eine zufrieden stellende Lösung fanden die Entwickler
aber erst durch die Implementierung einer Datenbank-gestützten
Methode. Aktuell existieren zwei CNID-Backends, die davon Gebrauch
machen und für den Produktionsbetrieb freigegeben sind: »cdb« und
»dbd«.
Die Unterschiede in Kürze: Bei der »cdb«-Variante greifen die
einzelnen »afpd«-Prozesse direkt auf die CNID-Datenbank zu.
Konflikte werden durch Datenbank-Locking-Schemata umgangen. »dbd«
implementiert den Zugriff auf die Datenbanken der Volumes über den
eigenen Daemon »cnid_metad(8)«. Den auf diesem Weg etwas geringeren
Durchsatz gleicht der Vorteil einer größeren Robustheit wieder aus.
Auch abstürzende Clients können die CNID-Datenbank nicht
korrumpieren.
Generell ist also »dbd« zu empfehlen. Da allerdings für jedes aktive
Volume ein eigener Prozess startet, kann es in Situationen mit
vielen Freigaben zu Problemen kommen. Dann stellt sich »cdb« als die
bessere Wahl heraus. Ein Beispiel wären Homeverzeichnisse auf
Systemen mit sehr vielen Benutzern. Ein Wechsel zwischen beiden
Schemata ist übrigens aufgrund identischer Datenstrukturen in der
CNID-Datenbank offline jederzeit möglich. Weitere wichtige Hinweise
zu Backends liefert http://netatalk.sourceforge.net/2.0/htmldocs/upgrade.html#choosecnidscheme «