Dateien lassen sich halb löschen. NFS-Problem?

[apollo]

Hallo forum!

Ich beschreibe für unser Rechenzentrum ein Problem, das es echt in sich hat. Leider kann ich noch nicht alle technischen Informationen angeben. Aber das lässt sich sicher nachholen.

Nun zum Problem: Wir haben auf einem Filer ein großes Volume als Austauschlaufwerk für alle möglichen DFÜ-Sachen. Das Laufwerk wird über NFS exportiert, damit Windows-, Linux- und UnixWare-Kisten lesend und schreibend darauf zugreifen können. Gerade im Unix- und Linux-Umfeld laufen in der Nacht eine Menge Scripts, die das Laufwerk im Zugriff haben.

Dabei gibt es auch Dateien, die während der Script-Verarbeitung auf null Byte Größe zurückgesetzt werden. Das geschieht unter Linux/Unix mit dem Befehl

> beispiel.txt

Das hat bis gestern noch wunderbar funktioniert. Jetzt passiert folgendes: Wenn eine Datei unter UnixWare angelegt wurde und dann von Linux aus mit obigem Code gelöscht werden soll, bleibt die Größe der Datei bestehen und alle Bytes werden auf Hex "00" gesetzt. Wurde die Datei unter Linux erzeugt, funktioniert alles gut. Als Beispiel mal ein bisschen Konsolen-screendumps:

UnixWare:root-> echo asdf > a

Linux:root-> echo asdf > b
Linux:root-> ls -l a b
-rw-r--r--    1 root     root            5 Okt 18 09:12 a
-rw-r--r--    1 root     root            5 Okt 18 09:13 b
Linux:root-> diff a b
Linux:root-> > a            # reset der Datei a
Linux:root-> > b            # reset der Datei b
Linux:root-> ls -l a b
-rw-r--r--    1 root     root            0 Okt 18 09:13 a
-rw-r--r--    1 root     root            0 Okt 18 09:13 b
Linux:root-> hexdump -Cv a
Linux:root->

UnixWare:root-> ls -l a b 
-rw-r--r--    1 root     root              5 Okt 18 09:13 a
-rw-r--r--    1 root     root              0 Okt 18 09:13 b
UnixWare:root-> hd a       # entspricht dem Linux-Hexdump
0000    00 00 00 00 00                                     .....
0005

Nach Einschätzung unseres Sysops riecht das nach einem NFS-Problem. Habt ihr irgendwelche intelligenten Ideen? Was ich ausschließen kann:
- Rechte-Probleme. Ich bin root, das Laufwerk ist zum Lesen/Schreiben gemountet

Gruß,

apollo

 

[TeXpert]

ich würde jetzt so spontan auf eine Art Caching-Problem tippen... mach auf dem Unixwaresystem mal einen Sync auf das Filesystem..

denn irgendwie ist die Datei ja leer nur das der Rechner immer noch von einer entsprechenden Größe ausgeht.

als Fehlerquelle könnte ich mir spontan auch den Filesystemtreiber auf dem Unix-ware-System vorstellen,

mach das Experiment mal andersrum und leere die Dateien auf Unixware und nicht unter Linux

 

[apollo]

mach auf dem Unixwaresystem mal einen Sync auf das Filesystem..

Ich trau mich nicht. Immerhin ist das Laufwerk permanent in Verwendung. Werde aber den Tipp weitergeben.

mach das Experiment mal andersrum und leere die Dateien auf Unixware und nicht unter Linux

Habe ich schon probiert. Das geht komischerweise.

Übrigens muss ich die Datei nicht unbedingt reseten, um die falsche Größe zu bekommen.

UnixWare:root-> echo asdf > a

Linux:root-> echo asdf > b
Linux:root-> echo as > a
Linux:root-> echo as > b
# Auf Linux ist alles OK, den ls spare ich hier

UnixWare:root-> ls -l a b
-rw-r--r--    1 root     root              5 Okt 18 09:53 a
-rw-r--r--    1 root     root              3 Okt 18 09:54 b
UnixWare:root-> hd a
0000    61 73 0a 00 00                                     as...
0005

 

[TeXpert]

nachdem die Änderung ja richtig funktioniert, wenn Du das von UW aus machst deutet IMHO sehr viel auf ein Caching-Bug bei UW hin --> mach mal einen Supportcall immerhin wollen die viel Geld für Ihren Mist

ansonsten unter UW mal man mount bzgl. nfs optionen näher untersuchen

 

[apollo]

nachdem die Änderung ja richtig funktioniert, wenn Du das von UW aus machst deutet IMHO sehr viel auf ein Caching-Bug bei UW hin --> mach mal einen Supportcall immerhin wollen die viel Geld für Ihren Mist

ansonsten unter UW mal man mount bzgl. nfs optionen näher untersuchen

Habe ich schon. Bei mount kann man angeben, ob man version 3 oder 2 fahren will. Der NFS-Deamon ist eher spartanisch mit Optionen ausgestattet (vergleichbar mit GNU/Linux).

Naja, vielleicht werde ich mich mal in English-sprachigen Foren rumschlagen müssen. Mal sehen...

Auf jeden Fall Danke für deine Hilfe!

 

[TeXpert]

du könntest manuell ein Verzeichnis mal mit "sync" mounten und sehen ob das dann geht, OK, es geht Performance flöten aber evtl. ist das ein Würgaround...

 

[Kurt M]

es könnte auch eine Inkompatibilität bei der Bearbeitung von Textdateien sein.
Wie wäre es, wenn man das Löschen mit

rm x.txt ; touch x.txt

macht ?

 

[TeXpert]

die Idee ist prinzipiell richtig, hat aber einen gravierenden Nachteil.

1. die Datei bekommt einen neuen inode kann Probleme machen
2. wenn die Datei von einem anderen Prozess (typischerweise Logfiles von daemonen) verwendet wird, dann hagelt es bei dem daemon Fehlermeldungen oder mehr... insbesondere müssen einige Daemonen dann neu gestartet werden, damit die wieder neu in die Logfiles schreiben können. der Apache ist so ein Kandidat bzgl. des weblogs ...

und dieses Problem kannst Du mit dem Kürzen über stdout umgehen.

 

[apollo]

es könnte auch eine Inkompatibilität bei der Bearbeitung von Textdateien sein.
Wie wäre es, wenn man das Löschen mit

rm x.txt ; touch x.txt

macht ?

Naja, der Gedanke mit rm und touch kam mir auch. Nur will ich nicht derjenige sein, der abertausende von Scriptzeilen nach ">" durchsucht und das Zeug anschließend testet. Außerdem wäre dieser "Würgaround" (ein wirklich schönes Wort von TeXpert) nur wenig beruhigend, da das eigentliche NFS-Problem bestehen bleibt.

Zum Thema Inkompatibilität: Das Problem ist nicht der vi. Wir catten auf diesem Laufwerk eigentlich wild Dateien zusammen, kopieren sie hin und her usw. Ein Austausch-Laufwerk eben. Und da gehen nicht nur Textdateien sondern auch alle anderen möglichen und unmöglichen Dateien rüber.