lazy umount

Es gibt 40 Antworten in diesem Thema, welches 11.960 mal aufgerufen wurde. Der letzte Beitrag (11. Juni 2014 um 21:20) ist von chris78.

  • Also falls bei mir ein umount nicht funzt, ist dat erste was ich (schon immer) mache ein pwd um zu schauen, ob ICH mich gerade noch drauf befinde.

    Danke, diese Information erleichtert das Helfen beträchtlich :thumbsup:
    Ich gehe jetzt mal davon aus, dass Du dann auch weißt bzw. sicherstellst, keine Hintergrund-Jobs in diesem Verzeichnis mehr laufen zu haben.

    ein umount /dev/sda1 bzw. umount /media/hdd (sda1 ist hier gemountet!) funzt nicht, Fehlermeldung: umount: can't umount /media/hdd: Device or resource busy

    Okay, damit ist klar: Ein anderer Prozess greift darauf zu. Bei einem "richtigen" lsof müsste jetzt "lsof /media/hdd" funktionieren. Da das busybox-lsof keine Argumente kennt, probier mal stattdessen "lsof | fgrep hdd" und "lsof | fgrep sda". Irgend eine Ausgabe? Wenn nicht, wiederhol das Experiment mit einer Shell in dem Verzeichnis und sieh Dir an, wie "lsof" diesen Shell-Prozess anzeigt.

    Nochmal zu PostingBitte melde dich an, um diesen Link zu sehen. ne Verständis-Frage:
    /media/hdd ist vor dem Mounten ein leeres Verzeichnis in meinem JFFS-Filesystem - und nach einem erfolgreichen umount auch !
    wenn ich dann ein touch /media/hdd/testfile mache, landet das testfile doch in meinem jffs-filesystem, oder nicht ?
    Zeigt der Befehl mount mit nicht IMMER die eingehängten Geräte an ? Und ich dachte im Umkehrschluß: was mount NICHT anzeigt, ist auch nicht (mehr) eingehängt .... hmm .... ?(

    Jein (tm): Wenn Du Dich vor dem Mounten in /media/hdd aufhältst, wird die entsprechende Shell das gemountete Dateisystem nie sehen (weil die Shell noch eine Referenz auf das "darunterliegende" Verzeichnis hat). Wenn Du aber zwischen dem Mounten und dem Unmounten in das Verzeichnis wechselst, wird das Unmounten fehlschlagen (da die Shell noch eine Referenz hat). Nimmst Du nun ein Lazy-Unmount, so hat die Shell immer noch eine Referenz, und das Device ist immer noch gemountet. Dass "mount" und "df" und wie sie alle heißen, dies jetzt nicht mehr korrekt anzeigt, ist eine Eigenheit von Lazy-Unmount. Natürlich hätte man das im Kernel auch anders herum implementieren können, aber dann gäbe es ebenfalls Inkonsistenzen ("Laut mount ist da was gemountet, aber ich kann nicht mehr in das Verzeichnis wechseln!?").
    Und zum "touch testfile": Probier es einfach mal aus, das spart uns beiden hier viel Tipparbeit. ;)

    EDIT: Ok, ist hinfällig, hast Du ja jetzt.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ein cd.. und dann ein cd hdd ; ls brachte keine Ordnernamen mehr - nun ist der Stick wirklich ausgehängt !

    Fazit: um in einem Script sicherzugehen, ob mein Stick wirklich ausgehängt ist, muß ich nur auf einen bestimmten Ordner testen - wenn der Ordner nicht mehr vorhanden ist, dann ist der Stick ausgehängt.

    Nein, das reicht nicht. Das obige Beispiel mit dem "cd .." sorgt nur dafür, dass diese eine Shell die Referenz auf das Device verliert (und danach nicht mehr in das Verzeichnis hinein kann). Für alle anderen Prozesse, und somit auch für das hypothetische Unmount-Skript gilt aber: Wenn keine Referenz auf das Device vorlag, erscheint das Mount-Verzeichnis sofort nach dem Lazy Unmount leer. Das heißt aber nicht, dass das Device wirklich ausgehängt ist. Mach Deine Tests mal mit zwei Logins gleichzeitig (einmal im Verzeichnis, einmal draußen).

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Danke, diese Information erleichtert das Helfen beträchtlich

    Sorry, hatte vergessen, meinen Wissenstatus zu posten: ich habe 10 Linux-Geräte zu Hause und bearbeite sie hauptsächlich mit der shell/bash weils einfach schneller geht. Ein Hobby von mir: auf meine Bedürfnisse shell Scripte und cron-Jobs erstellen, die die Arbeit erleichtern/automatisieren. Ich beschäftige mich seit 2005 intensiv mit Linux. C, perl und python kann ich allerdings nicht ! so, dat is erstmal geklärt ^^

    Irgend eine Ausgabe? Wenn nicht, wiederhol das Experiment mit einer Shell in dem Verzeichnis und sieh Dir an, wie "lsof" diesen Shell-Prozess anzeigt.

    Nein, keine Ausgaben !
    Die Pipes auf fgrep können wir uns auch sparen, indem ich mal die komplette liste von lsof poste - so lang is die ja nicht.
    Wie Du sehen kannst, gibt es keine openFiles, die auf /media/hdd zugreifen.
    Wenn es einfach wäre, hatte ich wohl auch nie den lazy-Schalter von umount benutzt - jetzt weiß ich, daß das richtig problematisch ist.
    Habe mal einen fiesen Test gemacht, der Deine Aussagen bestätigte: umount -l gemacht, Stick herausgezogen, anderen stick reingesteckt und auf das gleiche Verzeichnis /media/hdd gemountet - da denn ein paar files per ftp draugebügelt - da kam nur mist raus - alte files wurden angezeigt (auch nach dem Refresh des FTP-Fensters !), obwohl die auf dem neuen stick nie drauf waren.
    Also war meine Frage aus Posting Bitte melde dich an, um diesen Link zu sehen. doch irgendwie berechtigt (tief im Unterbewußtsein aaahnte ich schon sowas ....).

    Zurück zum Problem: wie finde ich den Prozess, der auf meinen Stick noch zugreift und der ein normales umount scheitern lässt ?


    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • Kann durchaus sein, daß der Prozess nicht immer darauf sitzt sondern immer nur kurze Zeit und er wieder weg ist wenn 'lsof' vorbeischaut

  • Ja, aber dann sollte auch umount meist funktionieren und nur sehr selten scheitern.

    GI-Joe: An der lsof-Ausgabe kann ich auch nichts ablesen, aber ich vermute jetzt mal ganz verwegen, dass es der vsftpd-Prozess ist - oder kannst Du das anhand der Konfiguration ausschließen?

    EDIT: Das busybox-lsof scheint tatsächlich nur offene Files, aber nicht das jeweilige Arbeitsverzeichnis zu beachten. Probier mal, ob "ps" brauchbareren Output erzeugt.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Erst mal nochmal danke für Eure tatkräftige Unterstützung, Ihr seid echt fit in den Materien .... (egal in welchen Threads ich meine bohrenden Fragen gestellt hab :rolleyes: ) :respect:
    Ich hab wirklich schon sehr viel dazu gelernt hier im Forum !!
    Is kein Geschleime - muß aber auch mal erwähnt werden zwischendurch !!

    Zurück zum Thema:
    also ich hab den ftp-daemon, den lirc-daemon und alles andere, was nicht gerade für meine telnet-Verbindung gebraucht wird, gekillt - immer noch kein umount möglich !

    EDIT: Das busybox-lsof scheint tatsächlich nur offene Files, aber nicht das jeweilige Arbeitsverzeichnis zu beachten. Probier mal, ob "ps" brauchbareren Output erzeugt.

    leider nix brauchbares da ps auch auf busybox verlinkt und nur 2 Parameter kennt -l (long Output) -T (show threads)
    auch top liefert nix brauchbares (siehe unten).
    Dat nervt ja - shice busybox kann man nur sagen (jaaa ich weiß, hat auch seine Berechtigung ... :zzz: )
    Ich hab mir schon den tar - link auf busybox entfernt und eine tar- "vollversion" draufgemacht, damit funzen wenigstens meine Backup-Scripte ....

    Eine seltsame Sache hatte ich allerdings gerade erlebt:
    Ich habe mal den durchs Testen kaputt gegangenen USB-Stick unter Linux schön neu partitioniert (auf meinem Ubuntu-Laptop) und mit ext3 formatiert.
    Dann noch die Ordner draufgemacht (werden beim Starten der STB benötigt - sonst landen die CrossEPG- und Timeshift-writings im Flash-Speicher ....), dann den Sat-STB aus dem PowerOffZustand heraus neu gestartet.
    Funzte alles, UND: umount (OHNE -l) funzte auch !!!
    hääää ???

    o.k., nochmal nachgedacht: den ursprünglichen USB-Stick für vermutlich fehlerhaft erklärt und Diesen auch neu partitioniert und mit ext3 formatiert.
    Dann dort auch noch die Ordner draufgemacht, dann damit den Sat-STB aus dem PowerOffZustand heraus neu gestartet. und ----> umount (OHNE -l) funzt wieder nicht. auch nicht 10x hintereinander !

    Is doch merkwürdig, oder ? Ich habe auf dem ursprünglichen USB-Stick keine korrupten Files/Archive gehabt (hätte man vermutlich auch schon beim Entpacken/kopieren gemerkt ...).
    Ein fsck.ext3 -nf /dev/sdb1 (auf meinem Linux-Laptop) brachte auch keine Fehler auf dem USB-Stick ! (einen zeitaufwändigen BadBlocks-Check hab ich mit jetzt erstmal erspart ....)

    Is ja nicht so, daß das System nicht läuft, aber ich mag solche Sachen halt gern begreifen, im Moment is mir das noch n Rätsel ?(
    Sowas macht mich wuschig :motz:


    ps -l - Ausgabe


    top - Ausgabe

    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • [offtopic]

    Ihr seid echt fit in den Materien .... (egal in welchen Threads ich meine bohrenden Fragen gestellt hab :rolleyes: ) :respect:
    Ich hab wirklich schon sehr viel dazu gelernt hier im Forum !!


    geht mir genauso

    Is kein Geschleime - muß aber auch mal erwähnt werden zwischendurch !!

    find ich gut
    [/offtopic]

  • Ich Depp :facepalm:
    Zum Lesen der CWDs reicht ja ein "ls -la /proc/[0-9]*/cwd", und zum Lesen der offenen Files "ls -la /proc/[0-9]*/fd". Vorsicht, nach einem Lazy Unmount steht in den Symlinks Grütze drin, nämlich nur noch der Pfad, der hinter dem Mountpoint käme.
    Aber mal ganz was Anderes: Angenommen, Du findest jetzt den richtigen Prozess und killst ihn - wie wird das Gerät damit umgehen? Oder anders ausgedrückt: Was gibt eigentlich die Gerätedokumentation zum Thema USB-Stick her?

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • hilf mir mal auf die Sprünge: was sind CWD´s ?

    Ich habe die jeweiligen Ausgaben mal in 2 Files laufen lassen - hängen hier mit dran (als Anhang bläst das den Thread-Text nicht so auf ...) !
    aber erkennen tue ich da jetzt nix, was zum Thema passt ..... ?(

    was ich noch nicht erwähnt habe:
    es existiert ein symlink /hdd , der zeigt auf den mountpoint /media/hdd
    Ich wüßte jetzt allerdings nicht, inwiefern dieser Link das umount /media/hdd negativ beeinflussen sollte, da ja kein (gelisteter) Prozess auf /hdd zugreift.

    Angenommen, Du findest jetzt den richtigen Prozess und killst ihn - wie wird das Gerät damit umgehen? Oder anders ausgedrückt: Was gibt eigentlich die Gerätedokumentation zum Thema USB-Stick her?

    Also dem Gerät (SAT-STB) wäre das wohl egal, kaputt gehen wird da nix - (EDIT) das rcS und das Hauptprogramm enigma2 ist ja schon gekillt (= der SAT-Receiver liefert eh kein Bild und Ton mehr). Außerdem habe ich immer ein funktioniertendes JFFS-Image für den Flash-Speicher vorrätig !
    Die Dokumantation sagt nicht viel, weil das Enigma-Image, was gerade drauf lüppt, kein Hersteller-image ist sondern ein gemoddetes Szene-Image mit gewissen "Vorzügen" :anonym .
    Das umount-Problem war aber schon bei anderen Images mit jeweils anderen Kernals vorhanden.

    Kernal-Infos: uname -a
    Linux SparkReloaded_03 2.6.32.59_stm24_0211 Bitte melde dich an, um diesen Link zu sehen. PREEMPT Mon Feb 24 19:15:20 CET 2014 sh4 GNU/Linux

  • CWD = current working directory (was auch von "pwd" angezeigt wird).
    Tja, in den Files taucht kein "/hdd" auf. Wenn die Files wirklich zu einem Zeitpunkt erzeugt wurden, als das Unmounten mit "busy" abgelehnt wurde, dann bin ich jetzt am Ende meines Lateins angekommen. ?(

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Wenn die Files wirklich zu einem Zeitpunkt erzeugt wurden, als das Unmounten mit "busy" abgelehnt wurde, dann bin ich jetzt am Ende meines Lateins angekommen.

    ja, wurden unmittelbar nach dem gescheiterten umount erzeugt.

    Macht aber nix, hast mir trotzdem sehr weiter geholfen und vor allem die Augen geöffnet, welche Fallstricke es gibt in der Linux-Shell wenn man "lazy" umounten möchte :anonym

    Für mich ist jedenfalls das umount -l erstmal tabu - es wird sonst unübersichtlich/unberechenbar.
    Vor dem Entfernen des USB-Sticks wird der SAT-STB halt runtergefahren (is eh nur zu bestimmten Wartungszwecken nötig - sonst steckt er permanent drin)

    Ich probiere das Ganze bei Gelegenheit nochmal auf einem richtigen Linux-System (ohne busybox), da kann man auch besser mit lsof und ps checken, was los ist.

    so, ich muß nu ins Bett, zuviele Tippfehler mittlerweile ;)

    Vielen Dank nochmal & N8 !!

    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • 1. "sync; umount /mnt/foo" ist doppelt gemoppelt
    "umount /mnt/foo" führt ein sync für dies blocksdevice aus sofern nicht benutzt.
    Auch ein "umount -l" tut dies, nur leider erst, wenn die ressourcen nicht mehr benutzt sind. Datenverlust ist somit vorprogrammiert.

    2. lsof ist mit Kanonen auf Spazen schiessen. fuser ist einfacher.
    "fuser -m /mnt/foo" zeigt:

    Code
    /mnt/foo:  2564  7367  7378  7379  7396  7397  7408m  7520m  7742m  7878m  8098


    fuser kennt auch einen Switch "-k" der Prozesse tötet, die den Mountpoint noch benutzen.

    Ein easy-Skript könnte so ähnlich ausschauen:

    ezumount:

    Bash
    #!/bin/sh
    cd /
    if ! umount "$1" then
      fuser -m -k "$1" && umount "$1"
    fi


    Aufgerufen mit "ezumount /mnt/foo" also Root.
    Vorsicht das Scipt tötet sich ggf. auch selber ;) sollte der Vaterprozess auf dem Terminal mit "fuser -k" getoetet werden.

    Ich würde jedoch empfhelen zu schauen, wass dein Desktop Environment an Tools zu Verfügung stellt.
    Dieses Rad wurde schon oft erfunden.
    Es gibt auch pmount/pumount, die nicht an Root-Privilegien des Nutzeres gebunden sind.

  • Vorsicht... 'fuser' zeigt nicht überall Prozesse an die weiter unten sitzen.

    Beispiel:

    fuser /mnt/foo

    zeigt dir nicht an, daß auf

    /mnt/foo/bar/boing

    noch jemand zugange ist.

    Bevor man sich darauf verlässt besser vorher auf dem Zielsystem ausprobieren.

  • Gerrit: Deswegen "-m" "fuser -m /mnt/foo"

    Code
    -m NAME, --mount NAME
                  NAME specifies a file on a mounted file system or a block device that is mounted. All processes accessing files on
                  that file system are listed.  If a directory file is specified, it is automatically changed to NAME/. to  use  any
                  file system that might be mounted on that directory.
  • Nicht jede 'fuser' Implementation kennt die Option '-m'.

    Speziell bei den über 'busybox' realisierten Kommandos fehlen oft die meisten Optionen.

  • Gerrit: Da hast du leider Recht. Zuviele Varianten um korrekte Aussagen zu treffen.

    linux-utils psutils/psmic kennt es schon seit geraumer Zeit.
    Die älteste Busybox-Variante, die ich gerade gefunden habe - in meiner Umgebung ist 0.60 -, kann dies.

  • 2. lsof ist mit Kanonen auf Spazen schiessen. fuser ist einfacher.

    danke für den Tip, den werd´ ich in Zukunft bestimmt noch öfter anwenden auf "richtigen" Linux-Systemen.

    Leider hat der Tip mit fuser einen kleinen Haken auf meinem SAT-STB:

    Code
    SparkReloaded_03:~# fuser --help
    -sh: fuser: not found
    SparkReloaded_03:/# cd /
    SparkReloaded_03:/# find . -name fuser
    SparkReloaded_03:/#


    Und ich hab KEINE Ahnung, wie ich auf diesem "embedded System" fuser nachinstallieren/compilieren kann - will ich allerdings auch nicht (mir reicht der momentane workaround und das system läuft an sonsten sehr gut und stabil ...)

    Code
    SparkReloaded_03:~# uname -a
    Linux SparkReloaded_03 2.6.32.59_stm24_0211 #1 PREEMPT Mon Feb 24 19:15:20 CET 2014 sh4 GNU/Linux

    Ich würde jedoch empfhelen zu schauen, wass dein Desktop Environment an Tools zu Verfügung stellt.
    Dieses Rad wurde schon oft erfunden.

    Ich zitiere mich hierzu mal selbst:

    die "Oberfläche" in meinen Beispielen heißt sh bzw. bash. Zu klicken ist da bekanntermaßen nix :P
    Die Fragestellung bezog sich eigentlich auch auf shell only ..... (beim Server oder SAT-Receiver - Zugang mit telnet oder ssh)


    das ezumount - script liest sich aber schonmal sehr gut, das werde ich (nach ein paar Tests mit fuser auf den jeweiligen Systemen) bestimmt übernehmen :thumbup:

    EDIT:
    hab mal einen symlink auf busybox erstellt - is leider nicht drin in meiner busybox :(

    Code
    SparkReloaded_03:/usr/bin# ln -s ../../bin/busybox fuser
    SparkReloaded_03:/usr/bin# fuser --help
    fuser: applet not found
    SparkReloaded_03:/usr/bin#

    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • danke für den Tip

    Ebenso. Jetzt weiß ich auch wieder, was in meinem Hinterkopf rumspukte, als ich lsof für ungeeignet hielt... :whistling:

    hab mal einen symlink auf busybox erstellt - is leider nicht drin in meiner busybox :(

    Schade - da /proc nichts hergab, hätte mich sehr interessiert, ob fuser funktioniert. Ich hab heute einen entsprechend wissenden Arbeitskollegen gefragt, und dem fiel auch nicht viel mehr ein als "möglicherweise eine immer noch offene, aber im Dateisystem bereits gelöschte Datei". Die hätten wir im /proc-Output aber auch sehen müssen...

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Die hätten wir im /proc-Output aber auch sehen müssen...

    Genau so isses.
    Und was man dort Interessantes gefunden hätte, wäre vermutlich auch mit lsof zum Vorschein gekommen :S

    Aber was solls, durch diesen Thread haben wir (und vielleicht auch Andere) wenigstens bissel was dazu gelernt - sowas is ja auch nich schlecht ^^

    Viele Grüße,
    GI-Joe
    Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • Das Problem sind ja oft nicht nur Prozesse, die ein Working-Dir auf dem auszugängenden Medium haben, sondern die dort auch Files geöffnet haben.

    Alternativ, da fuser als auch lsof die Daten aus /proc/$PID/fd/* oder /proc/$PID/cwd holen:
    Die Shell kann das auch (getestet auf BusyBox auf einem etwas angestaubten OpenWrt und einer DBOX2).

    Code
    ls /proc/[0-9]*/cwd /proc/[0-9]*/fd/* -ld 2> /dev/null | sed -ne 's@^.*/\([0-9]\+\)/.* -> \(/.*\)$@\2 (pid \1)@ p'

    Dies funktioniert z.B. auch auf gelöschte Dateien:

    Code
    # ls /proc/[0-9]*/cwd /proc/[0-9]*/fd/* -ld 2> /dev/null | sed -ne 's@^.*/\([0-9]\+\)/.* -> \(/.*\)$@\2 (pid \1)@ p' | grep fooo
    /tmp/foooo (pid 3750)
    # ls /proc/[0-9]*/cwd /proc/[0-9]*/fd/* -ld 2> /dev/null | sed -ne 's@^.*/\([0-9]\+\)/.* -> \(/.*\)$@\2 (pid \1)@ p' | grep fooo
    /tmp/foooo (deleted) (pid 3750)

    Zur Funktionsweise:
    * ls /proc/[0-9]*/cwd /proc/[0-9]*/fd/* -ld
    Dies listet die Dateien und Verzeichnisse auf, die von einem Progamm verwendet werden.
    Der Switch "-ld" stellt sicher, dass im Falle eines Verzeichnisses der Verzeichniseintragselber und nicht dessen Inhalt angezegit wird.
    * | Die Ausgabe von ls wird die Eingabe von SED
    * sed is ein Stream Editor Input Stream -> Verarbeitung -> Output Stream
    * sed -n gibt Zeilen des Streams nicht aus, es sei denn die Stream Operation p.
    * sed -e erwartet als nächstes ein Sed-Script.
    * das SED-Script ''s@^.*/\([0-9]\+\)/.* -> \(/.*\)$@\2 (pid \1)@ p' zerfällt in zwei Teile. s-subsitutue und p-Print. Wobei Print nur im Falle eines erfolgreichen Substitute ausgeführt wird.
    * 's@^.*/\([0-9]\+\)/.* -> \(/.*\)$@\2 (pid \1)@' sucht nur File-Descriptoren (/ im Filename) und die Pid aus dem File oder Verzeichnisnamen und das Link-Ziel (alles nach dem " -> ") und erstez es durch $DATEINAME (pid $PID)


    Was übrigends Tricky ist:
    Wird der Kernel-Space-NFS-Server verwendet, kann es sein, dass unter dem Mountpoint keine benutzten Files oder Dirs angezeigt werden, jedoch, der Mountpoint trotzdem nicht ausgehängt werden kann.
    Die passiert z.B. wenn ein Teil des Verzeichnisses via NFS exportiert wird (typischer Fall an den ich mich aus meiner DBOX2-Zeit zurück erinnere.)