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.
- 7289 megtekintés
Hozzászólások
Soft mount a te barátod.
man 5 nfs
- A hozzászóláshoz be kell jelentkezni
"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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
timeo és retrans opciókat vedd kisebbre. De túl jól nem fog működni így sem, ha a szerver elmegy.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
huh, erre a megoldasra en is kivancsi vok
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Pl. http://www.cyberciti.biz/tips/how-do-i-forcefully-unmount-a-disk-partit…
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...)
- A hozzászóláshoz be kell jelentkezni
+1, de ezt automatikusan kéne :)
Amugy mindjart kesz a workaround scriptem.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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()
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
dupla
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
ha nfs, akkor rpcinfo:
http://www.expertslogin.com/linux-administration/rpcinfo-linux-command-…
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az övé a szerver is, gyanítom, hogy nem fogja kilőni akkor amikor épp használja.
- A hozzászóláshoz be kell jelentkezni
Szar a wifi. Megeshet az ilyesmi.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni