Discussion:
Qualitaet Netatalk (was: Re: Drobo Pro nach Austausch zu langsam)
(zu alt für eine Antwort)
Thomas Kaiser
2011-05-03 12:20:34 UTC
Permalink
Klar, Netatalk, wie es viele NAS-Vendors einsetzen, taugt, wenn
aktuell genug und nicht kaputtgepatcht. Helios EtherShare für
Unix-Plattformen dito, unter Windows gibt's AFAIK nur noch
ExtremeZ-IP (das allerdings auch klaglos tut). Alle Lösungen haben
sogar echte Vorteile gegenüber Apples Implementierungen: sie
funktionieren, ohne auf HFS+ angewiesen zu sein, d.h. können auf
Dateisystemen aufsetzen, denen man ein Eckchen lieber seine Daten
anvertraut.
Aha, ich habe noch keine Netatalk-implementierung gesehen, der ich
getraut hätte - aber ehrlich gesagt waren's auch nicht so viele.
Man muß da klar unterscheiden. Netatalk hat mit dem Versionssprung auf
2.0 einen sehr großen Schritt nach vorne gemacht, sowohl was die
Features anbelangte [1] als auch, was die Ausrichtung anbelangte. War
Netatalk zu Zeiten von 1.4 irgendwann nur noch ein Ein-Personen-Projekt,
dann quasi tot und zu 1.5/1.6-Zeiten das Werk von Admins, die sich da
halt reingepatcht haben, was sie grad gebraucht haben oder für lustig
hielten, stand beginnend mit Version 2.0 v.a. eines im Fokus der
Entwicklungen: "Es richtig machen", d.h. keine faulen Kompromisse mehr
sondern der Versuch, die AFP-Specs vollumfänglich zu unterstützen.

Damit einhergehend das Rausschmeißen alten Codes, der die Specs verletzt
(und allenfalls "betriebsblinden" Admins das Leben erleichtert) hat,
mühevolle Diskussionen auf der Netatalk-Entwickler-Liste im Sinne des
"richtig oder gar nicht machens" (die teils auch glücklicherweise dazu
geführt haben, daß sich ein paar Netatalk-Coder zurückgezogen haben) und
ebenfalls mühevolles Erstellen einer Doku, die hoffentlich wenigstens
ein wenig dem Anspruch gerecht wurde, hilfreich zu sein, Hintergründe zu
erläutern, Warnungen auszusprechen.

Ein Netatalk 2.0 mit dem richtigen CNID-Backend (CNID --> Catalog Node
IDs, das sind eindeutige IDs, die für Mac-Dateireferenzierungen genutzt
werden. HFS(+) hat sowas eingebaut, alle anderen spezifikationskonformen
AFP-Server müssen sowas mittels eines Datenbank-Mechanismus *konsistent*
nachbauen) auf einem Dateisystem, das ausschließlich per Netatalk
befuttelt wurde (d.h. _keine_ lokalen Änderungen, _keine_ Koexistenz mit
bspw. Samba oder NFS-Daemons), war schon eine stabile Sache.

Das war/ist seit jeher einer der Knackpunkte: CNID-Konsistenz, d.h. die
Wahl des richtigen Datenbank-Backends für maximale Stabilität und das
Verhindern von Manipulationen des Dateisystems an Netatalks Datenbank
vorbei.

2.1 hat erneut eine Menge Verbesserungen gebracht -- IMO ist auch die
Qualität des Codes nochmals deutlich gestiegen. Und mit der jetzt vor
Veröffentlichung stehenden Version 2.2 wird sich nochmals einiges in die
gleiche Richtung gehende tun:

<http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2beta4.html>

Wenn man sich an die paar "goldenen Regeln" hält, dann kann man mit
Netatalk 2.x einen ausgesprochen soliden und dito performanten
AFP-Server hinstellen, der sich vor anderen AFP-Lösungen (grad denen von
Apple) nicht verstecken muß. Die Frage ist halt leider regelmäßig: Macht
das der NAS-Hersteller des Vertrauens auch? Oftmals leider nein. Mir
fehlt da aber der Überblick, inwieweit die Netatalk-Verbauer unter den
NAS-Klitschen, da ein Händchen dafür haben oder nicht.
Die anderen Lösungen sind glaub ich nicht ganz günstig, also nicht
unbedingt, was ich für den Heimgebrauch will.
Ja, ExtremeZ-IP gab's (gibt's?) wohl am Günstigsten in Form irgendeiner
LaCie Network Disk (die haben eine halbwegs aktuelle Version davon
lizensiert, weshalb _diese_ Version der LaCie-Netzwerk-Dinger auch
uneingeschränkt cross-platform-tauglich sind -- aber man muß höllisch
aufpassen, denn LaCie hat auch relativ ähnlich benannte NAS im Programm,
die auf Linux und OpenSource-Komponenten basieren und für die das nicht
zutrifft).

Und Helios scheint am reinen Datei- und Druckserver-Markt kein
wirkliches Interesse (mehr) zu haben, wenn man sich die Preispolitik
bzw. die Preise von EtherShare so anschaut...

Gruss,

Thomas

[1] Ich zitiere der Einfachheit halber aus der Presseerklärung zum
2.0-Release, die ich auf meinem Rechner "gefunden" habe:

* Unterstützung von AFP 3.1, d.h. volle MacOS X Kompatibilität,
lange Dateinamen, UTF8-Support und Dateigrößen von mehr als 4
GByte
* Direkte Interaktion mit CUPS, d.h. automatische Freigabe aller
CUPS-Queues per AppleTalk
* Komplette Überarbeitung des CNID-Systems sorgt für eine stabile
und konsistente Verwaltung von File- und Directory-IDs
* Mehr als 100 Seiten Anwender-Dokumentation im PDF-, Text- und
HTML-Format
* Kerberos V Unterstützung und damit die Möglichkeit, echtes "Single
Sign On" im Macintosh-Netzwerk zu praktizieren
* Beseitigung zahlloser Bugs im Vergleich zu Vorgängerversionen
Hermann Schaefer
2011-05-03 18:30:55 UTC
Permalink
Post by Thomas Kaiser
Und Helios scheint am reinen Datei- und Druckserver-Markt kein
wirkliches Interesse (mehr) zu haben, wenn man sich die Preispolitik
bzw. die Preise von EtherShare so anschaut...
Öh.. hatten die denn mal? :D
Meine erste Begegnung mit Helios war unter HP/UX, und schon damals (~1992?) war
das _sauteuer_.
Thomas Kaiser
2011-05-03 20:52:29 UTC
Permalink
Post by Hermann Schaefer
Post by Thomas Kaiser
Und Helios scheint am reinen Datei- und Druckserver-Markt kein
wirkliches Interesse (mehr) zu haben, wenn man sich die Preispolitik
bzw. die Preise von EtherShare so anschaut...
Öh.. hatten die denn mal? :D
Meine erste Begegnung mit Helios war unter HP/UX, und schon damals
(~1992?) war das _sauteuer_.
Aber im Gegensatz zu "damals" bzw. auch noch vor ein paar Jahren sehen
es die Leute heute oftmals nicht mehr ein, "nur" für einen Dateiserver
solche Summen zu berappen.

Und wenn sie tatsächlich die sonstigen Helios-Features nicht _brauchen_
bzw. die mal gekauften Features dummerweise brachliegen lassen, obwohl
sie damit viel schneller, eleganter und effizienter arbeiten könnten,
dann ist der Preis heute wohl auch schwer zu verargumentieren.

Wohlgemerkt rede ich bei der Preisbetrachtung von einem reinen
Dateiserver. Gibt halt in dem Bereich inzwischen auch andere Anbieter,
die plattformübergreifendes Filesharing in stabil bieten, womit ein
zeitweise mal dagewesenes Alleinstellungsmerkmal von Helios irgendwie
weggefallen ist.

Gruss,

Thomas
Michael Grundmann
2011-05-17 21:52:03 UTC
Permalink
Am 03.05.11 22:52, schrieb Thomas Kaiser:

Hallo,
Post by Thomas Kaiser
Und wenn sie tatsächlich die sonstigen Helios-Features nicht _brauchen_
bzw. die mal gekauften Features dummerweise brachliegen lassen, obwohl
sie damit viel schneller, eleganter und effizienter arbeiten könnten,
dann ist der Preis heute wohl auch schwer zu verargumentieren.
da hast du total recht. Ich habe bemerkt, dass wir auch nur noch den
reinen Dateiserver von Helios benutzen. Dementsprechend habe ich sehr
auf die Aktualisierungen von Netatalk geachtet. Ein grosses Problem ist
die Suche innerhalb eines Netatalk-Volumes. Diese funktioniert in der
aktuellen Beta noch nicht richtig. Von daher bleibe ich nach wie vor bei
Helios - auch wenn es nur der 'teure' Dateiserver ist. Und ja, ich habe
bei den Tests peinlichst darauf geachtet, dass nur Netatalk-Zugriffe
stattfanden. Bei anderen Situationen hilft bisher ein dbd -r -f auch nichts.
Aber ich denke ebenfalls, dass bei dem Netatalk-Projekt richtig gute
Leistung gebracht wird und werde es weiter sehr genau beobachten, da wir
es bei manchen Freigaben auch benutzen.

Gruß
Michael
Thomas Kaiser
2011-05-18 10:03:19 UTC
Permalink
Post by Michael Grundmann
Post by Thomas Kaiser
Und wenn sie tatsächlich die sonstigen Helios-Features nicht
_brauchen_ bzw. die mal gekauften Features dummerweise brachliegen
lassen, obwohl sie damit viel schneller, eleganter und effizienter
arbeiten könnten, dann ist der Preis heute wohl auch schwer zu
verargumentieren.
da hast du total recht. Ich habe bemerkt, dass wir auch nur noch den
reinen Dateiserver von Helios benutzen.
Und das ist genau der Fehler. Das riesige Potential brachliegen zu
lassen.
Post by Michael Grundmann
Aber ich denke ebenfalls, dass bei dem Netatalk-Projekt richtig gute
Leistung gebracht wird
Das ist überhaupt keine Frage. Aber Netatalk ist halt erstmal "nur" ein
Dateiserver, dem auch für diese Funktionalität noch bisserl was fehlt
(weitere ad-Utilities [1] u.v.a. ein gemeinsamer VFS-Layer mit Samba).
Und ein Netatalk/Samba-Gespann, das eine File-Event-Schnittstelle
bietet, wäre dann sogar wieder was für Workflows :-)

Gruss,

Thomas

[1] <http://netatalk.sourceforge.net/2.2/htmldocs/ad.1.html>

Goetz Hoffart
2011-05-03 20:19:29 UTC
Permalink
einem Dateisystem, das ausschließlich per Netatalk befuttelt wurde (d.h.
_keine_ lokalen Änderungen, _keine_ Koexistenz mit bspw. Samba oder
NFS-Daemons), war schon eine stabile Sache.
A propos: muss ich an einem Linux-Server ein AFP-Volume lokal mounten,
das er selbst exportiert, um mit einem Script programmgesteuert Dateien
und Verzeichnisse anzulegen?

In der Netatalk-FAQ/Howto/Wiki habe ich nichts dazu gefunden.

Grüße
Götz
--
http://www.knubbelmac.de/
Thomas Kaiser
2011-05-03 21:03:38 UTC
Permalink
Post by Goetz Hoffart
einem Dateisystem, das ausschließlich per Netatalk befuttelt wurde
(d.h. _keine_ lokalen Änderungen, _keine_ Koexistenz mit bspw. Samba
oder NFS-Daemons), war schon eine stabile Sache.
A propos: muss ich an einem Linux-Server ein AFP-Volume lokal mounten,
das er selbst exportiert, um mit einem Script programmgesteuert
Dateien und Verzeichnisse anzulegen?
Bis einschl. 2.1 wäre das wohl der Idealzustand. Wobei ich nicht auf dem
aktuellen Stand bin (bin ja quasi mit 2.0 aus der aktiven Entwicklung
ausgestiegen), wie gut Netatalks CNID-Implementierung damit umgehen
kann, wenn *nur* was dazukommt. In der Situation ist es IIRC so, daß der
afpd dynamisch bzw. on-the-fly CNIDs vergibt und die entsprechenden
AppleDouble-Dateien mit Standard-Dateimetadaten anlegt.

Problematisch wird's in jedem Fall in Situationen, in denen Dateien oder
Ordner verändert werden (also mv oder rm), weil hier ohne entsprechende
Vorkehrungen zwangsläufig eine Diskrepanz zwischen Dateisystem und
Inhalt der CNID-Datenbank auftritt. Und evtl. auch die zugehörigen
AppleDouble-Dateien mit Metadaten/Resourceforks nicht mit berücksichtigt
werden (die alten Tools apple_cp, apple_mv und apple_rm, deren Sinn und
Zweck es war, sich darum zu kümmern, waren schon immer Schrott, weil sie
sich nicht um CNIDs gekümmert haben).
Post by Goetz Hoffart
In der Netatalk-FAQ/Howto/Wiki habe ich nichts dazu gefunden.
Ab 2.2 gibt es das ad-Kommando:

"Complete Netatalk volume compatible `ad` file utility suite"
<http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2beta4.html>

Manual Page hier:
<http://netatalk.sourceforge.net/2.2/htmldocs/ad.1.html>

Gruss,

Thomas
Goetz Hoffart
2011-05-04 05:58:10 UTC
Permalink
Post by Thomas Kaiser
"Complete Netatalk volume compatible `ad` file utility suite"
<http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2beta4.html>
<http://netatalk.sourceforge.net/2.2/htmldocs/ad.1.html>
Hervorragend. Danke!

(und da war ich froh, mit Debian Squeeze ein einigermaßen aktuelles
Netatalk-Paket zu bekommen und nicht mehr nervig compilieren zu müssen,
und nun geht's wieder los ... naja, kommt davon, wenn man 'stabile' OSse
nutzen will :)

Grüße
Götz
--
http://www.knubbelmac.de/
Patrick Kormann
2011-05-03 23:56:06 UTC
Permalink
Post by Thomas Kaiser
Man muß da klar unterscheiden. Netatalk hat mit dem Versionssprung auf
2.0 einen sehr großen Schritt nach vorne gemacht, sowohl was die
Danke für den ausführlichen Review. Vielleicht komme ich mal in die
Situation, netatalk noch eine Chance geben zu 'müssen'.
Patrick M. Hausen
2011-05-06 08:21:28 UTC
Permalink
Hallo,
[mit] Version 2.2 wird sich nochmals einiges in die
<http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2beta4.html>
Danke fuer den Hinweis, wird Zeit, von 2.1 auf 2.2 zu aktualisieren,
besonders deshalb:

* Builtin Zeroconf registration of the AFP server and TimeMachine volumes

Howl ist auf FreeBSD deprecated und fliegt demnÃ?chst aus der
Ports-Collection und Avahi erscheint mir von den Features her
völliger Overkill zu sein, wenn man nur sein TM-Volume lokal
bekannt machen will. Allein aus den Compile-Time-Optionen
des Ports bin ich schon nicht schlau geworden ;-)

Gruss,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
***@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
Ralph Böhme
2011-05-06 08:47:35 UTC
Permalink
Post by Patrick M. Hausen
Hallo,
[mit] Version 2.2 wird sich nochmals einiges in die
<http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2beta4.html>
Danke fuer den Hinweis, wird Zeit, von 2.1 auf 2.2 zu aktualisieren,
* Builtin Zeroconf registration of the AFP server and TimeMachine volumes
Howl ist auf FreeBSD deprecated und fliegt demnÃ?chst aus der
Ports-Collection und Avahi erscheint mir von den Features her
völliger Overkill zu sein, wenn man nur sein TM-Volume lokal
bekannt machen will.
Das benutzt libavahi-client. ;)

Gruß Ralph
Loading...