Sziasztok!
Ha van a rendszerbe becsatolva egy fájlrendszer (samba, nfs, usb stick stb.), akkor hogyan tudom ellenőrizni, hogy arra tudok-e írni?
Programból kéne fájlműveletet végrehajtani egy becsatolt fájlrendszeren.
Ebben az esetben ez egy hálózati meghajtó. Az írás előtt milyen paranccsal tudom megnézni, hogy a fájlművelet végre tud-e hajtódni?
mount /tavoli/filesystem /mnt
Google-lel kerestem de ott csak olyat találtam, hogy fel van-e monutolva vagy nincs. Azt nem, hogy a "kapcsolat" él-e.
Ha ezt a parancsot használom pl: # mountpoint -q /mnt && echo "mounted" || echo "not mounted"
akkor disconnect esetén ez a végtelenségig vár. Legalábbis elég hosszú ideig, hogy az ne legyen jó.
Ha lehet, akkor nem azt nézném meg, hogy a hálózati kapcsolat él-e, hanem konkrétan a mount poninton levő eszköz működik-e.
üdv: redman
- 3241 megtekintés
Hozzászólások
Jó kérdés - szerintem az elérés módjától függhet - nfs esetén pl. nagyon nem mindegy, hogy hard vagy soft,intr opciókkal van csatolva a távoli cucc.
Inkább az írási/olvasási műveletre állíts be egy timeout-ot (Hint: sigalarm), ez nyelvfüggő, de példákat ez alapján már találhatsz szerintem.
- A hozzászóláshoz be kell jelentkezni
Esetleg igy: odateszel egy egyedi filet a hálózati meghajtóra, és a meglétét ellenőrzöd.
- A hozzászóláshoz be kell jelentkezni
Nem tudok odatenni, mert minden fájlműveletnél, és már az ellenőrzésnél (lásd mountpoint) nincs visszatérési érték, csak vár, vár, vár...
Nekem az kéne, hogy abban a pillanatban elérhető-e a távoli meghajtó vagy nem.
Nem kell timeout, nem érdekes, hogy miért elérhetetlen. Csak, hogy elérhető-e: true, false
- A hozzászóláshoz be kell jelentkezni
Milyen megosztott terület, hogyan csatoltad fel, milyen OS-ből, milyen programból szeretnéd elérni?
A "nem tudok odatenni fájlt" de facto hülyeség: a túloldalon leraksz egy "network_mount_is_alive" nevű fájlt, "yes" tartalommal, lokálisan meg mielőtt felcsatolod (egyszer) leraksz egy ugyanilyen nevűt, amibe "no" kerül.
Ez után a "timeout 3 cat /mnt/network_mount_is_alive" legfeljebb 3s után szépen megmondja, hogy mi a helyzet. Ha "no", akkor nincs csatolva, ha üres, akkor csatoltad, de nem érhető el (ekkor a retval!=0), ha yes, akkor ö'öm és bódottá :-)
- A hozzászóláshoz be kell jelentkezni
Most pl egy samba megosztás csatoltam fel.
"A "nem tudok odatenni fájlt" de facto hülyeség"
Nem hülyeség, mert ha kihúzom a gépből a hálókábelt, akkor nincs visszatérési érték. (nem az a kérdés, hogy fel van-e mountolva vagy nem. Mindig fel van mountolva.)
Igen csinálhatok "mesterséges" timeoutot, de ez olyan favágás módszernek tűnik nekem.
Nem hiszem el, hogy a "nagyok" nem használnak hálózati meghajtókat. És ha használnak, akkor honnan tudják, hogy a hálózat írás előtt elérhető-e?
Ez tulajdnképpen egy recorder alá lenne, aminek írás előtt ellneőriznie kéne, hogy tud-e írni. És nem ér rá 1 másodpercet várni. Azonnal kell az infó.
Próbálkoztam java-ban, c-ben, és linux parancssorban is.
Mindegyik vár a válasszal addig, amíg vissza nem dugom a hálókábelt.
- A hozzászóláshoz be kell jelentkezni
Ott látom a problémát hogy van egy instabil hálózati környezeted, amiben működtetni akarsz valamit. Feltételezem, hogy van bé terv arra, ha nem tud írni a hálózati meghajtóra, gondolom akkor a lokális diskre fanyalodik. Ilyen esetben én inkább azt csinálnám, hogy mindig a helyi diskre ír, ahonnét átkanalazza valami az nfs share-re, így a hálózati hiba nem befolyásolja a recorder működését. Egész addig, amíg meg nem telik a helyi disk.
Plusz azt az egy másodpercet akár egy századmásodpercre is lehet csökkenteni. A lényeg az, hogy a fő szálat ne blokkolja ha várnia kell valamiért.
- A hozzászóláshoz be kell jelentkezni
Igen lehet, hogy instabil. Még az a szerencse, hogy nem az enyém. :)
Valószínű, hogy ez a megoldás lesz amit mondasz. helyi diszkre, aztán az valamilyen backup módszerrel meg lementi máshova, ha tudja.
- A hozzászóláshoz be kell jelentkezni
No még egyszer. Azon a gépen, amiről kapod a megosztást, odapakolsz egy fájlt, vagy akkor, amikor működik, és utána figyelsz rá, hogy megmaradjon.
A timeout neked favágásnak tűnik, oké. Milyen más ötleted van? Azt, hogy írhatsz-e egy fájlt, hogyan tudod másképp ellenőrizni, minthogy megpróbálod? Aa a próba sikertelen, akkor azt mondod, hogy nem megy, ha sikerül, akkor meg azt, hogy sikerült. A sikertelenséget meg az jelzi, hogy hibával tért vissza vagy x ideig nem tért vissza az írási művelet.
Persze, hogy vár, mert a fájlművelet nem fog timeout-tal elszállni - csak ha te megoldod.
- A hozzászóláshoz be kell jelentkezni
Hát... gány megoldást tudok:
(touch /mnt/aa && (rm /mnt/aa ; touch /tmp/bb))&
sleep 3
if [ -f /tmp/bb ]
then
rm /tmp/bb
HakunaMatata
fi
Ezt tetszőleges nyelven lehet implementálni, de ha reális az esély arra, hogy pl. az nfs szerver eltűnik a távolban, akkor pl. hard mount esetén igen sok probléma merülhet fel.
A semminél persze jobb, de nem vagyok rá büszke :D
- A hozzászóláshoz be kell jelentkezni
Sajnos nem jó, mert ahogy az ellenőrzésnél is, ha fájlműveletet akarok, akkor vár a csatlakozási pontra, hogy elérje.
Ha kihúzom a hálózati kábelt, akkor vár az eszközre.
De a "HakunaMatata" tetszik :D
- A hozzászóláshoz be kell jelentkezni
Igen, 3 másodpercig. Vagy a sleep 3 helyett lehet akár sleep 1 is, és akkor egyig fog várni. Csiszolható még, hogy ciklusban mondjuk 3x lekérdezed, hogy ott-e a /tmp/bb, pici várakozással, és akkor minimális késleltetést fog okozni egy-egy teszt.
Maga az ellenőrzés külön szálon fut, függetlenül a fő száltól. Ennek van előnye és hátránya is, pl. rossz esetben akár pár ezer touch is futhat, várva a nyomorult fájlrendszerre.
- A hozzászóláshoz be kell jelentkezni
Ronda gány, és ha hard opcióval van csatolva az nfs, akkor ott fognak ácsorogni a taccsok. soft,intr mount kell, és Linux (GNU) környezetnél ott van a timeout(1)
- A hozzászóláshoz be kell jelentkezni
Sőt, én bg,soft,intr-t használnék...
--
Coding for fun. ;)
- A hozzászóláshoz be kell jelentkezni
Az intr már egy ideje nem csinál semmit :)
man 5 nfs
- A hozzászóláshoz be kell jelentkezni
Jééé... :D Köszi az infót! Rég olvastam mant. :)
--
Coding for fun. ;)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
check=`cat /proc/mounts | grep mnt | awk ' {print $2} '`
for i in $check
do touch $i/salalala.test
lala="$?"
if [ "$lala" == "0" ]
then echo "A $i/ mehajtó elérhető!"
else echo "A $i/ meghajtó elérhetetlen!"
fi
done
(cat /proc/mounts | grep mnt = grep mnt /proc/mounts ;-)
- A hozzászóláshoz be kell jelentkezni
soha nem fogom felfogni, hogy miert jo a cat foo | grep bar a grep bar foo helyett.
tovabba:
$ awk '/localhost/ {print $1}' /etc/hosts
127.0.0.1
::1
t
- A hozzászóláshoz be kell jelentkezni
Nem arról van szó, hogy miért jó vagy rossz, egyszerűen szokás kérdése, 1x éve megszoktam.
(Azért írtam a végére mert már itt vki belekötött a dologba, ott is lényegtelen volt a belekötése mert a feladat megoldásához nem tett hozzá.)
- A hozzászóláshoz be kell jelentkezni
Egyébként más előnye is lehet a nem közvetlen fájlban-grepnek; én pl. gyakran keresek olyan fájlban, aminek az első sora fejléc, és azt nem szeretném greppeltetni. Magyarán a tail -n +2 foo|grep bar megoldás gyakran hatékonyabb, és jó érzést csinál, ha megszokom. Itt bizsereg a jobb oldalam körül.
- A hozzászóláshoz be kell jelentkezni
Ez nagyon remek, attól eltekintve, hogy az első hard mountolt nfs könyvtárba beleáll mint a gerely, ha ki van húzva a drót.
- A hozzászóláshoz be kell jelentkezni
Javítsd kérlek.
- A hozzászóláshoz be kell jelentkezni
Szerintem pont az a kerdes, hogyan lehet javitani :)))
- A hozzászóláshoz be kell jelentkezni
timeout 1 touch $i/salalala.test
Bár a hardmount-ot nem tudom hogy viseli...
- A hozzászóláshoz be kell jelentkezni
Villámteszt alapján jól.
- A hozzászóláshoz be kell jelentkezni
Sejthettem volna, problémát megoldani nehezebb mint hibát találni a megoldásig vezető úton. ;-)
- A hozzászóláshoz be kell jelentkezni
Csak ismételni tudnám magamat. Az én megoldásomnál a várakozás leteltével mindenképp kiderül, hogy csodás-e minden. A várakozást lehet csökkenteni, vagy ciklusban ellenőrizni, hogy ha hamarabb létrejön a fájl, mondjuk egy század- vagy tizedmásodperc után, akkor futhasson tovább a fő ág.
Ezen elv alapján több nyelven is meg lehet valósítani az ellenőrzést. Sajnos ennek a módszernek az a hibája, hogy ha hosszan áll fenn a hiba és/vagy sokszor kell ellenőrizni amikor épp halott a mount, akkor az ellenőrzést végző ágak (a touch ága) felszaporodnak és eszik az erőforrásokat.
- A hozzászóláshoz be kell jelentkezni
mountpoint?
- A hozzászóláshoz be kell jelentkezni
olvasd el légyszi mégegyszer a kérdést. thx.
- A hozzászóláshoz be kell jelentkezni
Szerintem a kernelen belül kéne megnézni hogy vannak-e túl régóta várakozó fájlműveletek.
- A hozzászóláshoz be kell jelentkezni
Nem tudok róla, hogy lenne olyan koncepció a kernelben, hogy egy adott mount point épp "disconnected". A "nagyok" úgy csinálják, mondjuk NFS esetén, hogy ha a szerver behal, és nem úgy jön vissza, hogy a kliens tudja folytatni ott, ahol abbahagyta, akkor umount/mount, rosszabb esetben reboot.
Ha ilyet akarsz, akkor szerintem userspace-ből tedd fel a fájlt oda, ahová kell, mondjuk smbclienttel pl.
Ezt itt is fölvetettem, és egy zavaros hozzászóláson kívül más reakció nem volt:
http://hup.hu/node/115927#comment-1478706
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy unalmas vagyok, de neked is ajanlom figyelmedbe az autofs-t. Ebben az esetben egy siman az
ls /net/servername_vagy_IP/sharename parancs is eleg lenne a vizsgalathoz.
Toni
- A hozzászóláshoz be kell jelentkezni
Egyrészt az a parancs semmit se mond arról, hogy az adott file írható-e, bár ez csiszolható. Másrészt a /etc/auto.net (legalábbis nálam) fájlban található opcióktól függően (opts="-fstype=nfs,hard,intr,nodev,nosuid"), ez épp úgy beledermed a tesztbe mint bármelyik másik, ha kihúzzák a kábelt.
Hacsak nincs nagyon alacsonyra véve a timeout (/etc/default/autofs) _és_ nincs írás a fájlrendszerre. De az is csak csökkenti az esélyt.
- A hozzászóláshoz be kell jelentkezni