[linux-l] Re: ACKs bevorzugen mir fli4l

Peter Ross Peter.Ross at alumni.tu-berlin.de
Sa Aug 9 04:04:07 CEST 2003


On Fri, 8 Aug 2003, Soeren Sonnenburg wrote:

> ok... hier laeuft es mit kernel nfs und so um die 40 clients und 2.4.17+
> kerneln ganz stabil... diese art von abstuerzen ist mir nicht
> vorgekommen...

Was mir leider vorgekommen ist, sind Schwierigkeiten beim Locking, welches
rein oberflaechlich funktioniert (keine Locks von einer
zweiten Maschine zurueckweist), dann aber doch beide Maschinen schreiben
laesst - mit dem Ergebnis einer kaputten Datei:-(

Und noch besser ist es bei flock (BSD style locking). Das funktioniert
schlichtweg ueber NFS nicht (dass steht dann immerhin in der Manpage), im
Code steht an der Stelle erschreckender Weise "das brauchen wir nicht".

In meiner letzten Berliner Firma war Perl _die_ wichtigste
Programmiersprache, und unser erster Linux-Versuch (von Solaris kommend)
ging deshalb in die Hose, weil die default-Einstellung des installierten
Perls (Details leider vergessen, ich glaube perl-5.6 unter Debian woody)
flock zum Locking verwendet.

Da ich mir bis dahin ueber dieses Detail keine Gedanken gemacht hatte,
habe ich ein wenig gebraucht, um rauszufinden, warum Perl nicht locken
konnte.

Immerhin konnte man, wenn ich mich recht erinnere, das bei Perl immerhin
beim Kompilieren angeben.

Desweiteren, auch ohne Locking, ist die Cachestrategie von Linux nicht
sauber, es stehen Daten im Cache des NFS-Clients, die nicht mehr aktuell
sind.

Linux hat aus Performancegruenden ein recht "optimistisches" Caching
(klar, wenn ich nicht nachgucke, ob Daten noch aktuell sind, bin ich
schneller - ein Grund fuer Geschwindigkeitsvorteile bei NFS-Benchmarks,
wie z.B. vor 1 1/2 Jahren in der iX)

Um mal eine Analogie zu verwenden - ich empfinde Linux als MySQL unter den
NFS-Implementierungen.

Schoen schnell und fuer "ReadOnly-Umgebungen" gut geeignet.

Es gibt sicherlich viele Szenarien, in denen diese Cache- und Lockprobleme
praktisch nie auftreten, ich habe bei den letzten beiden Arbeitgebern das
aber gebraucht, und mache seitdem um Linux-NFS einen Bogen, wenn es geht.

4.4BSD entwickelte NQNFS (Not Quite NFS) weiter, ein wichtiges Detail sind
"Leases". Das funktioniert besonders huebsch und flott und stabil in
NQNFS-Umgebungen (alles BSD, oder auch Solaris, Sun hat da einiges gelernt
- ueber andere kommerzielle Unixe kann ich nicht reden), ohne dass
Nicht-NQNFS-Clients die Stabilitaet stoeren - sie koennen nur von durch
NQNFS erreichbare Performancevorteilen nicht profitieren, weil hier eine
"pessimistische" Strategie gefahren wird.

Bei Linux fehlt mir der Durchblick, um einige Design-Details zu
verstehen, mein Einblick und meine Erfahrungen sprechen gegen Linux-NFS.

Gruss
Peter



Mehr Informationen über die Mailingliste linux-l