[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS unmount, Stale NFS file handle, Nach Netzwerk trennung.



Am 22. März 2012 04:24 schrieb Michael Strauß <mailms@mszet.de>:
> Am Wed, 21 Mar 2012 18:50:40 +0100
> schrieb Martin Steigerwald <Martin@lichtvoll.de>:
>
>> > Du machst mit -l einen Lazy unmount. Das heißt das
>> > Dateisystem wird erst ausgehangen, bis alle
>> > Dateien geschlossen sind. Die Fehlermeldung deutet eventuell
>> > darauf hin, dass dies vermutlich niemals passieren wird.
>>
>> Das stimmt so meines Wissens nicht. -l heißt sofort aushängen. Und
>> Anwendungen, die dann noch drauf zugreifen, bekommen Fehler zurück. D.h.
>> die Referenzen auf Dateien bleiben noch erhalten, solange sie in
>> Verwendung sind.
>>
> [...]
>>
>>        -l     Lazy  unmount. Detach the filesystem from the filesys‐
>>               tem hierarchy now, and cleanup all references  to  the
>>               filesystem   as  soon  as  it  is  not  busy  anymore.
>>               (Requires kernel 2.4.11 or later.)
>
> Lies einfach was da steht: Das Filesystem wird sofort aus der Verzeichnis-
> Hierarchie (oder dem Mountpoint) entfernt. Es wird aber erst geschlossen,
> wenn keine Anwendung mehr darauf zugreift.

Meinse wissens habe ich alles beendet.
Aber
root@pushka4:~# lsof|grep pushka1
lsof: WARNING: can't stat() nfs4 file system /mnt/srv.pushka1 (deleted)
      Output information may be incomplete.
lsof: WARNING: can't stat() nfs4 file system /mnt/srv.pushka2 (deleted)
      Output information may be incomplete.
lsof: WARNING: can't stat() nfs4 file system /mnt/srv.pushka3 (deleted)
      Output information may be incomplete.
lsof: WARNING: can't stat() nfs4 file system /mnt/srv.pushka4 (deleted)
      Output information may be incomplete.
lsof: WARNING: can't stat() nfs4 file system /mnt/srv.pushka5 (deleted)
      Output information may be incomplete.

was bedeutet es? übrigens verwende ich nfs4


> [Zitat von oben]
>> Und Anwendungen, die dann noch drauf zugreifen, bekommen Fehler zurück.
> Nein, das gerade eben nicht.
>
> Gerade Ausprobiert mit 2 xterms:
> 1:~$ cd /mnt/windata
> 1:/mnt/windata$
>
> 2:~$ su root
> 2:Passwort:
> 2:# umount -l /mnt/windata
> 2:#
>
> 1:/mnt/windata$ ls
> ADOBEAPP         CMNPROP.DLL                         MIXER.EXE
> AUDIO3D.DLL      CMUNINST.DAT                        MSDOS.SYS
> [...]
>
> Man sieht: Es gibt keine Fehler! Und das erste xterm kann weiterhin auf die
> unmountete Partition zugreifen, da es das Verzeichnis, indem es sich befindet
> weiterhin geöffnet hat.
>
>> > NFS bis Version 3 ist zustandslos. Das heißt, gleiche Operationen
>> > führen zum gleichen Ergebnis, egal ob du zwischen drin NFS neu
>> > startest.
>>
>> Wenn Du mit zustandslos UDP meinst, das stimmt so nicht. NFSv3 verwendet
>> standardmäßig TCP.
>
> Wenn ich TCP/UDP meinen würde, dann würde ich es auch so benennen!
>
> Ich meine:
> http://de.wikipedia.org/wiki/Zustandslosigkeit
>
> In dem Thread geht es um OSI-Schicht 7. Da kümmert TCP/UDP wenig.
>
>> Allerdings ist NFSv3 im Vergleich zu NFSv4 auf der NFS-Protokoll-Ebene
>> dann doch weitgehend stateless. Aber eben nicht ganz, wie Stale NFS
>> Filehandle zeigt.
>
> Das Filehandle wird in der Anwendung auf den Client gespeichert, wenn dieser
> die Datei öffnet. Das Dateiöffnen ist natürlich nicht Zustandslos. NFSv3 merkt
> sich beim Dateiöffnen gar nichts. Es übermittelt den inode der Datei, die der
> client zu öffnen wünscht als Filehandle an die Clientanwendung.
>
> Grüße
> Michael
>
>
>
>
>
>
>
>
> --
> Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-REQUEST@lists.debian.org
> mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl)
> Archive: [🔎] 20120322012410.2ffcbfc9@merkur.home.mszet.de">http://lists.debian.org/[🔎] 20120322012410.2ffcbfc9@merkur.home.mszet.de
>



-- 
Best Regards
Vlad Vorobiev


Reply to: