Timeouts bei SMB-Freigaben?

  • Hi,


    hier etwas, was mir schon länger Kopfzerbrechen bereitet:
    Ich habe aus Platzgründen einige Aufnahmen auf einen Windows-Rechner ausgelagert. Den Ordner habe ich dazu freigegeben und wird auf dem Linux-Rechner (in diesem Beispiel ist das ein LinVDR, aber das Problem würde ja vermutlich überall auftreten) automatisch beim Start per smbmount gemountet.


    Wenn der Windows-Rechner abgeschaltet wird, das Video-Verzeichnis vorher aber nicht per Hand geumountet wurde, hängt bei einem Zugriff darauf immer alles mehrere Minuten. Ich kann blöderweise nichteinmal nachträglich mit umount drangehen, weil dann auch umount hängen bleibt. Auch der Parameter -f ändert daran nichts.


    Hat jemand einen Trick, wie man nicht mehr erreichbare SMB-Freigaben automatisch unmounten oder wenigstens per Hand killen kann, ohne, dass es zu den Hängern kommt?

  • Super,
    Du hängst also an dem gleichen Problem wie ich:


    http://www.vdrportal.de/board/thread.php?threadid=44596&sid=&hilight=autofs+smb


    Ich benutze autofs, das macht aber absolut keinen Unterschied im Verhalten, als wenn ich von hand gemounted habe. Auch eine Umstellung auf NFS bringt absolut nichts.


    Angeblich soll das mit nem 2.4.x Kernel nicht auftreten, habe ich aber noch nicht ausprobiert.



    Bin Ratlos.

  • Naja, AutoFS mountet ja automatisch. Aber es kann auch nicht hellsehen, wann ich die Windows-Kiste ausknipse. Und dann hängt wieder alles. Von daher Murks.


    Ich habe neulich einen Abend lang Google zu dem Thema befragt und heraus kamen einige Samba-Mailinglisten, in denen Leute genau diese Fragen gestellt haben, aber nie eine Antwort bekommen haben. Hat etwas für Frust gesorgt. Selbst unter dem ach so verhassten Windows wird ja nach einem kurzen Timeout ein Fehler angezeigt, wenn eine Freigabe weg ist. :§$%

  • Zitat

    Naja, AutoFS mountet ja automatisch. Aber es kann auch nicht hellsehen, wann ich die Windows-Kiste ausknipse. Und dann hängt wieder alles. Von daher Murks.


    Jo, das meine ich ja: ob nun von Hand, oder per autofs - wenn der Server down geht (bei mir auch ein Debian System) geht nichts mehr.


    :§$% Alles Mist und keinerlei Idee wo man ansetzen kann.


    Gruß

  • Mist, sogar die Wikipedia ist gerade wegen einer NFS-Geschichte down...


    Ne, im Ernst. Ich habe nochmal weitergesucht. Das Ganze sieht so aus, dass Prozesse, die nicht mehr auf die Freigabe zugreifen können dann in einen "uninterruptible wait" genannten Zustand verfallen. Soll heißen: Da nützt auch kill -9 nichts mehr. Also ist ein Reboot angesagt. *lol* Der nächste, der mir mit der Uptime seines Linux-Rechners kommt, kriegt das unter die Nase gerieben.
    Anyway: Bei NFS-Freigaben kannst du mal die Option "soft" versuchen. Habe da sowas in meiner Sucheskapade gelesen:


    http://www.die.net/doc/linux/man/man8/mount.8.html


    Nützt bei SMB nur leider nix.

  • Stimmt,


    mit der option -soft hab ich auch getestet - Ergebnis gleich null.


    Also für mich folgender Stand:


    smbmount von Hand, autofs mit smb. autofs mit nfs: wenn der Server runterfahrt, schmiert der Client ab und ein Reboot ist notwendig.


    Gruß

  • Zitat

    Original von harot


    Jo, das meine ich ja: ob nun von Hand, oder per autofs - wenn der Server down geht (bei mir auch ein Debian System) geht nichts mehr.


    :§$% Alles Mist und keinerlei Idee wo man ansetzen kann.


    Das kommt davon das die Unix-adepten 24/7 propagieren.
    Offenbar geht kaum jemand der unix leute von nur temporär verfügbaren servern aus.
    Bei windows ging alles von peer-to-peer netzwerken aus. Also war dort 24/7 eher die ausnahme. Daher auch der offensichtlich bessere angang bei temporären mounts.


    Übrigens funktioniert bei nfs das ganze wieder wenn man den server wieder anmacht. Sobald die verbindung wieder steht klapt auch der unmount wieder und man barucht den client nicht zu rebooten.


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

  • Wie sieht es den mit "-l" aus?


    Auszug aus 'man umount':
    " -l Lazy unmount. Detach the filesystem from the
    filesystem hierarchy now, and cleanup all refer*
    ences to the filesystem as soon as it is not busy
    anymore. (Requires kernel 2.4.11 or later.)"


    allerdings meine ich mich zu erinnern, dass die Busybox bei LinVDR das nicht hergibt, lass mich aber gerne eines besseren belehren.


    Gruß
    Neo

    VDR #1:
    SW: LINVDR 0.7 (2.6.20.1 @Dr. Seltsam) VDR 1.4.5-2-extp22 + Mahlzeit-ISO 3.2
    HW: Asus Pundit-R - Pentium III 2GHz - 7'' TFT für GraphTFT - Nexus-S Rev. 2.3
    VDR #2 (Client):
    SW: LinVDR 0.7 (2.6.17.3 @Dr. Seltsam) VDR 1.4.0-1 + DXR3 @Dr. Seltsam
    HW: T-Online Streaming Box S-100 - Pentium M 788MHz - DXR3 Karte - 1GB CF
    Registered User: #1096

  • Ich glaub, ich hab da was gefunden:



    und dann



    http://www.ussg.iu.edu/hyperma…x/kernel/0601.1/2666.html


    Eventuell kann uns das helfen.



    Ich werde mal den patch in den 2.6.15.4 einbauen und dann testen.


    Gruß

  • Hi,


    sehr interessantes Thema, berichte doch mal ob das mit dem Patch hilft.

    HD DVB-C System / Ubuntu 14.04 x64 / Kernel 3.13.0-48 x64; VDR 2.2.x; VDRadmin 3.6.10 / ACPI Wakeup

    SoftHD-Device GIT / Vdpau / Nvidia 337.25

    ASUS AT5IONT-I; Atom D525; 4GB; Nvidia GT218; 1x DD Cine C/T v6; 1x DD DuoFlex C/T v2; (20~40 Watt)

  • Ich verfolge einen anderen Ansatz (der Patch bekämpft ja nicht die Ursache):


    Also habe ich, was ich schon länger vorhatte, mal eine Dev-Umgebung installiert, wenigstens um den Kernel neu kompilieren zu können (mir war auch u.a. das OSD zu lahm und einige andere Sachen, ist aber eine andere Story...). Naja, jedenfalls habe ich CIFS-Support reinkompiliert und kann jetzt meine Freigaben wenigstens mit "mount -t cifs -o soft, ..." mounten. Von daher fällt schonmal kein Prozess mehr in den uninterruptible Dornröschenschlaf. Der Timeout dauert aber immernoch ziemlich lange.
    Daher versuche ich gerade im CIFS-Kernelquellcode an ein paar hardcoded Timeout-Werten herumzupfuschen (kann man leider nur so nennen, aber mir ist mittlerweile alles egal). Dabei fiel mir auf, dass der erste Zugriff auf einen toten Server immer ca. 30 Sekunden dauert (dann wird der Status intern auf "cifsNeedReconnect" gesetzt) und jeder weitere Zugriff timed dann nach "nur" 10 Sekunden aus. Den zweiten Timeout habe ich schon lokalisiert. Mal sehen, vielleicht werde ich noch etwas schlauer. Aber bitte nicht zuviel erwarten.

  • OK, werd mit auf den Zug springen.


    Der Versuch gestern abend hat nicht wirklich was gebracht, nach dem ich verstanden habe, daß der patch einen Fehler im fuse file system behebt und nicht in nfs oder smb. (hab mal wieder was gelernt: was macht fuse eigentlich) Trotzdem könnte man mal den Ansatz weiter testen: mount der Laufwerke über fuse und fusesmb.


    Aber zurück:


    Dein test mit cifs bringt also die Büchse nicht mehr zum sterben, wenn der Server down ist ? Wenn ich Dich richtig verstehe, blockiert nur irgendwas eine Zeitlang ?



    Gruß


    Olaf

  • Also, ich habe ein wenig getestet. Kernel ist der 2.6.16-rc2. Die geänderten Dateien transport.c, cifssmb.c und connect.c habe ich angehängt. Originale sichern! Entpacken nach /usr/src/linux/fs/cifs/
    Vielleicht sollte man ein Diff machen...


    Naja, dann Kernel mit CIFS-Support kompilieren. Gemountet wird so:
    mount -t cifs //WIN_SERVER/FREIGABE /mnt/server -o soft,username=xxxxx,password=xxxxx


    In der Praxis sieht's dann so aus:
    Server läuft, Verbindung steht



    Dann Netzwerkkabel rausziehen. Ergibt nun einen kleinen Hänger von 6 Sekunden (ohne die Änderung wären das 30 Sekunden).



    Weitere Zugriffe dauern nur noch halb so lange.



    Sobald das Netzwerkkabel wieder drinsteckt, ist alles wieder normal.



    Verwendung auf eigene Gefahr. Performanceeinbrüche kann es u.U. wohl geben, aber das fällt bei meiner Krücke von Server nicht auf. Vielleicht findet sich ja jemand, der etwas mehr Ahnung und noch andere Ideen hat.

  • Hi,
    sehr interessant.


    Kann jemand einen kernel backen für LINVDR7 ??


    Ich kanns nicht - hätte daran Interesse!!


    Grüsse


    Magicdragon67



    clocker


    SUPER ARBEIT - Respekt :wow :wow :wow :wow :wow :wow :wow

  • Naja, lob mich nicht, bevor du es nicht getestet hast. Es ist ja immernoch so, dass die Sache mit dem Umount von nicht mehr vorhandenen Freigaben nicht geht. Hänger gibt es also so oder so. Auch wenn diese nicht mehr entgültig sind, sondern max. 6 Sekunden.
    Und ich hatte auch schon mal einen Timeout beim Umounten einer vorhandenen Freigabe. Also, es gibt noch Verbesserungsbedarf.


    Aber wenn du mit einem für Athlons kompilierten Kernel was anfangen kannst, kann ich meinen mal hochladen.

  • So, neue Erkenntnisse:


    Das Umounten von CIFS-Dateisystemen geht, selbst wenn der entsprechende Rechner down ist! Wichtig ist, dass man entweder die angehängte umount.cifs verwendet (anstatt des Default-umount) oder eine neuere Version der BusyBox. Es gibt da nämlich die Version 1.1.0, welche besagten Bug nicht mehr hat. Jetzt muss ich nur noch herausfinden, mit welchen Optionen die LinVDR-BusyBox kompiliert wurde...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!