NFS timeout parák

 ( Joejszaka | 2013. január 3., csütörtök - 11:23 )

Sziasztok!

Az otthoni hálózatomon van egy debianos és egy ubuntus gép. A Debian a szerver, és NFS-en keresztül megoszt egy médiavinyót az Ubuntuval.

A problémám az, hogy a debianos szerver nem megy mindig, és ha az nfs fel van csatolva a kliens gépen miközben leáll a szerver, a kliens gép hosszú percekre unresponsive-vá válik. Nincs erre egy megoldás, hogy ez ne így legyen? Konkrétan nem bírok belépni a /media könyvárba ilyenkor.

A kliensen az fstab:
172.30.100.102:/ /media/eee nfs4 proto=tcp,port=2049,user
0 0

A szerveren:
/etc/exports:
/export 172.30.100.0/24(rw,fsid=0,no_subtree_check,sync)
/export/media 172.30.100.0/24(rw,nohide,insecure,no_subtree_check,sync)

Kösz előre is a segítséget.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Soft mount a te barátod.
man 5 nfs

"Although soft-mounting the directories causes the error to be detected sooner, it runs a serious risk of data corruption. In general, read/write directories should be hard-mounted."

Mit is jelent ez a gyakorlatban?

Szerintem ha amúgy is tcp-n van használva az NFS, akkor semmi különöset. De ettől függetlenül elég szar az NFS disconnect esetén, van, hogy úgy leakad, hogy csak egy reboot segít.

Azt, hogy az writeback buffer biztosan elveszik ha megszakad a hálózati kapcsolat/leáll a szerver. Ezzel szemben hard mountnál a writeback buffer kiírásra kerül amint visszaállt a kapcsolat. A soft mount akkor okozhat súlyos adatvesztést, ha írás közben szakadozik a hálózat.

Hát, nem tudom. Ha soft-tal csatolom fel, bemountolok a kliensen, kilövöm a szervert, továbbra is kiakasztja a kliens gépet.

A végén még nekem kell írni valamit, ami időintervallumonként csekkeli az nfs-t? Nagy workaroundnak tűnik.

timeo és retrans opciókat vedd kisebbre. De túl jól nem fog működni így sem, ha a szerver elmegy.

Vajon ez a probléma samba esetén meg van oldva?

Azért használok nfs-t, mert a gyorsabb volt nekem, mint a samba. De ez a disconnect probléma megkeseríti az életemet. Értsd, samba megosztáson a filmlejátszás akadozott, nfs megosztáson nem.

A samba az nfs-sel szemben soft mount by default és alacsonyabb a default timeout is. Ezt tekinthetjük úgy is, hogy meg van oldva. :) Ellenben a soft mount nfs-hez hasonlóan nálózati hiba esetén ezzel az adatvesztést kockáztatja.

huh, erre a megoldasra en is kivancsi vok

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Pl. http://www.cyberciti.biz/tips/how-do-i-forcefully-unmount-a-disk-partition.html
Nálam általában a lazy umount beválik. Elengedi a beragadt mount pontot és nem hal tőle meg a rendszer.
# umount -l /mnt

Where,
-l : Also known as Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore.

Elég felhasználóbarát megoldás :) Szerintem ezért sem terjed a Linux, nincs egy normális hülyetűrő hálózati fájlrendszer implementáció benne. Még vállalati környezetben is necces, ráadásul kerberos nélkül zero security az nfs, kerberossal meg elég macerás.

Vállalati környezetben azért elég jól elvan a linux. Hirtelen nem jut eszembe olyan aplikáció ami alól ha kirántod a disket vígan futna tovább anélkül, hogy a kérdező által említett probléma -unreszponzitivás, fagyás- fellépne.

-
Debian Squeeze

Oké, hogy az applikáció nem fut tovább, de sokszor lerohad az egész rendszer :) Az is fasza volt, hogy egy NetApp hiba miatt kb. az összes Unix szervert bootolni kellett (nem csak Linuxokat mondjuk...)

+1, de ezt automatikusan kéne :)
Amugy mindjart kesz a workaround scriptem.

+1

import subprocess
import time
import threading
import ConfigParser

def check(ready, directory):
    #print "ls begin"
    res = subprocess.check_output(["ls", directory])
    #print "ls returned"
    ready[directory] = 1

def forceUnmount(mydir):
    params = "-l " + mydir;
    res = subprocess.check_output(["umount", "-l", mydir])

class MountChecker(object):
    def __init__(self, dirs):
        self.mounted_dirs = dirs
        self.ready = { '/': 0}

    def isResponsive(self, directory):
        self.ready[directory] = 0;
        mythread = threading.Thread(target = check, args=[self.ready, directory])
        mythread.start()
        time.sleep(0.01)
        if self.ready[directory] == 0:
            time.sleep(1)
        if mythread.isAlive():
            try:
                mythread._Thread__stop()
            except:
                print(str(mythread.getName()) + ' could not be terminated')
        return self.ready[directory]


    def do(self):
        for i in self.mounted_dirs:
            if self.isResponsive(i):
                print i + " is responsive"
            else:
                print i + " is NOT responsive"
                forceUnmount(i)

    def printDebug(self):
        for i in self.mounted_dirs:
            if self.isResponsive(i):
                print i + " is responsive"
            else:
                print i + " is NOT responsive"



mc = MountChecker(["/media/eee", "/media/Windows7_OS"]);
mc.do()

Ez a script leellenorzi a ket megadott konyvtarat, es ha nem reszponziv, umount-olja oket.

Innentol csak be kell rakni a cron-ba, hogy percenket fusson rootkent, es problem solved.

dupla

az a baj, hogy nalunk az ls _is_ szepen egy D-s process lesz (kilohetetlen :( ), amig umount-tal le nem csatoljuk a meghalt nfs-t...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Csak forceUnmount() fv-t kell átírni, hogy ez megjavuljon. Gondolom, ha sima könyvtári rutinokból hívok egy listázást, az is jó lesz. Vagy esetleg van ötleted, hogyan tudnánk eldönteni, hogy responsive-e?

Ha használod a scriptet és nem tudod megcsinálni, akkor megcsinálom.
Nekem így is működik :)

ha legkozelebb belefutunk ilyenbe, stracevel megnezem mit csinal. de tippem szerint valami rendszerhivas van (stat, akarmi), ami meg varakozik a nemletezo nfs-re. Igy csak var-var-var... mivel D-s process lett, igy killelni sem lehet. :( persze umount force uten visszater, de akkor mar keso.

es ugyanigy befagy minden ami azt a mount-ot akarja hasznalni (df, ls, cd)

a progihoz azt tudom mondani, hogy valami timert/alarmot kene beallitani, es ha az lejar akkor is force umountolni. (ha meg ls/stat sikeres, akkor lelovi a timert)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"a progihoz azt tudom mondani, hogy valami timert/alarmot kene beallitani, es ha az lejar akkor is force umountolni. (ha meg ls/stat sikeres, akkor lelovi a timert)"

Igy mukodik, pontosan. 1sec-es timer van benne :)
Ha az ls nem tér vissza 1 sec-en belül, akkor umount -l, és kill ls.

me fail. :( igazad van, nem neztem meg tuzetesen a progit, az ls-ig jutottam...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerintem neked automount kell; csak akkor legyen csatolva a szerver, ha szükség van rá. Mondjuk én magam nagyon rég automountoltam, nem tudom milyen állapotban van ma.

Az automount jó, de ha épp épp fel van csatolva a fájlrendszer, és úgy lövik ki alóla a szervert, azon nem segít. Legfeljebb annyit, hogy kevesebb eséllyel lesz mountolva az nfs épp a legrosszabb pillanatban.

Az övé a szerver is, gyanítom, hogy nem fogja kilőni akkor amikor épp használja.

Szar a wifi. Megeshet az ilyesmi.

Hja, arra valóban a lazy umount a jó megoldás + hard mount.

A fentebb ajánlott soft mount adatvesztést okozna pl akkor, ha elszáll a wifi miközben mozgatsz a hálózati mountra - az eredeti törlödik, a másolat pedig elszáll a writeback bufferből és kakukk.