NFS Problem bei gleichzeitigem lesen und schreiben

Hallo

Ich habe einen gesharten Datenfolder, auf welchen zwei Webserver über NFS zugreifen. Funktioniert alles tiptop, bis beide Server zur selben Zeit dasselbe File editieren. Dem zu editierenden File fehlt dann einzelne Zeilen oder ist nicht mehr lesbar.

Ich vermute, es ist ein Lockproblem. Obwohl der Lock- sowie Statdeamon laufen, habe ich immer noch das Problem.

Hier ist ein Auszug vom Server:
# rpcinfo -p localhost
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 39003 nlockmgr
100021 3 udp 39003 nlockmgr
100021 4 udp 39003 nlockmgr
100021 1 tcp 39204 nlockmgr
100021 3 tcp 39204 nlockmgr
100021 4 tcp 39204 nlockmgr
100005 1 udp 39004 mountd
100005 1 tcp 39205 mountd
100005 2 udp 39004 mountd
100005 2 tcp 39205 mountd
100005 3 udp 39004 mountd
100005 3 tcp 39205 mountd
100024 1 udp 39021 status
100024 1 tcp 42914 status


Auf dem Client:
# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 32770 nlockmgr
100021 3 udp 32770 nlockmgr
100021 4 udp 32770 nlockmgr
100021 1 tcp 32772 nlockmgr
100021 3 tcp 32772 nlockmgr
100021 4 tcp 32772 nlockmgr
100005 1 udp 32771 mountd
100005 1 tcp 32773 mountd
100005 2 udp 32771 mountd
100005 2 tcp 32773 mountd
100005 3 udp 32771 mountd
100005 3 tcp 32773 mountd
100011 1 udp 850 rquotad
100011 2 udp 850 rquotad
100011 1 tcp 853 rquotad
100011 2 tcp 853 rquotad
100024 1 udp 41978 status
100024 1 tcp 59030 status

Wäre echt toll wenn mir jemand weiterhelfen könnte.
Liebe Grüsse
Thomas

Tom75 schrieb:

Ich habe einen gesharten Datenfolder, auf welchen zwei Webserver über NFS zugreifen. Funktioniert alles tiptop, bis beide Server zur selben Zeit dasselbe File editieren. Dem zu editierenden File fehlt dann einzelne Zeilen oder ist nicht mehr lesbar.

Zum Vergrößern anklicken....

Na is doch klar, wenn sie gleichzeitig schreiben, wo soll denn das enden? Gleichzeitig schreiben kann man auch nicht gefahrenlos auf der lokalen Maschine ohne proper Locking.

Ich vermute, es ist ein Lockproblem. Obwohl der Lock- sowie Statdeamon laufen, habe ich immer noch das Problem.

Zum Vergrößern anklicken....

Das sieht mir eher nach einem Problem deiner Anwendung aus, was sagst du dazu?

Vielen Dank für deine Antwort.

Es ist ein PHP-Script, welches im r/w Mod ein File neu schreibt. Das Problem liegt wohl nicht beim Script, da es nur einmal augeführt wird pro Aufruf.

Habe ich da was falsch verstanden mit NFS-Lock? Ich gehe davon aus, dass wenn ich den Lock- sowie Stat-Deamon auf Client und Server aktiviere, das File gelockt wird falls es im r/w modus geöffnet wird und der nächste r/w Request dann warten muss.

Ich vermute eher, in deinem PHP-Ding fehlt ein Aufruf zu flock(). Was bringt es dir, dass der NFS-Locking-Daemon gestartet ist, wenn deine Anwendung es nicht nutzt :?:

Danke für den Tipp. Das hatte ich bereits auprobiert, doch leider ohne Erfolg.

Woran machst du das fest?

So, ich habe nach langem Googeln eine brauchbare Lösung gefunden. Mein Fehler war dass ich auf dem Client nicht die richtige Reihenfoge verwenet habe. Das editierbare File wird nicht mehr verrissen, ist aber zeitweise beim Einlesen leer. Das kann ich jedoch mit meinem Script abfangen.
Also ich habe die Daemons in folgender Reihenfolge gestartet:

Client
rpc.portmap
rpc.statd
rpc.lockd
--
Server
rpc.portmap
rpc.statd
rpc.lockd
rpc.mountd
rpc.nfsd
rpc.rquotad

Die Reihenfolge sollte egal sein, mit der Ausnahme dass portmap logischerweise als erstes da sein muss.

jengelh schrieb:

Ich vermute eher, in deinem PHP-Ding fehlt ein Aufruf zu flock(). Was bringt es dir, dass der NFS-Locking-Daemon gestartet ist, wenn deine Anwendung es nicht nutzt :?:

Zum Vergrößern anklicken....

was alleine auch nichts bringt, da php einfach eine neue instanz startet, die vom lock nicht zwingend was wissen muss und durch das lock z.b. einen leeren cache erstellt. dann wird der, der zuletzt kommt, zuerst malen.

abhilfe:
ein file vor dem schreiben erstellen (z.b. dateiname.lock) und nach dem schreiben das file wieder löschen --> und nächster kunde.

über das script die datei abfragen und das schreiben einer weiteren instanz erst dann erlauben, wenn instanz 1 das file wieder gelöscht hat.