On Wed, Oct 29, 2008 at 10:39:04AM +0200, Georgi Chorbadzhiyski wrote: > Around 10/29/08 09:50, Момчил Иванов scribbled: > > Nickola Kolev написа: > >> Според мен проблемът е точно в затварянето на TCP сесията/сесиите. Ако по > >> пътя между теб и NFS сървъра има маршрутизатор и той не е под твой контрол, > >> няма много какво да направиш. В противен случай обърни внимание на > >> функционалността на TCP Keepalive. Преди да почовъркаш из /proc или през > >> sysctl, можеш да хвърлиш едно око тук: > >> > >> http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html > >> > >> Естествено, това е само предположение, но пък звучи резонно, макар че > >> никак не разбирам от NFS. > > > > току що си събудих машината и определено проблемът идва от дългото време > > през което спи. mount показва файловите системи като монтирани, но при > > опит да вляза в някоя от тях cd зависва, както зависва и df. linux-а > > показва, че имам следната връзка, която още не е затворена (1 е nfs > > сървъра): > > > > tcp 0 1 10.67.54.3:696 10.67.54.1:2049 > > FIN_WAIT1 > > > > а freebsd-то показва: > > > > tcp4 0 0 10.67.54.1.* 10.67.54.3.696 CLOSED > > tcp4 0 0 10.67.54.1.* 10.67.54.3.928 CLOSED > > tcp4 0 0 10.67.54.1.* 10.67.54.3.928 CLOSED > > tcp4 0 0 10.67.54.1.* 10.67.54.3.928 CLOSED > > tcp4 0 0 10.67.54.1.* 10.67.54.3.928 CLOSED > > > > ще погледна връзката за keepalive-а и ще си поиграя с tcp timeout-ите и > > на 2-те машини, вероятно това е проблемът. Има ли начин на linux-а да му > > задам fin1 timeout-а? в proc има /proc/sys/net/ipv4/tcp_fin_timeout, > > което според документацията е за fin2 > > Не е ли по-лесно да пуснеш nfs по udp? Протокол е stateless и не > му трябва постоянно отворена връзка, за да работи. Доколкото си > спомням по udp си работи по подразбиране, а tcp се препоръчва > само ако ти трябва по-голяма стабилност. Например при мен когато > монтирах по udp nfs root и машината клиент имаше много udp, нещата > не вървяха хич добре. Превключвайки на tcp се оправиха нещата, но > при теб понеже гасиш клиент, udp би било по-добър вариант.
Хмм... на мен що ми се струва, че и работните групи, които правят стандартите за NFS, и доста хора по доста операционни системи все препоръчват да се ползва NFS върху TCP - от една страна за стабилна връзка и надеждно предаване на пакети, от друга страна именно за да е малко по-лесно да се разбират сървърът и клиентът, когато някой от тях бива спрян "правилно". В повечето случаи или сървърът, или клиентът биват спирани "както трябва" и просто затварят TCP връзката съвсем официално и чисто, така че другата страна да разбере, че са си отишли. Точно това ми е било източник на СТРАШНО много проблеми с NFS върху UDP - когато едната машина просто се рестартира или спре, другата *няма начин* да разбере, че този mount вече не е валиден, и стават едни идиотски зависвания. При NFS върху TCP при чисто спиране имаме затворена TCP връзка, а при внезапно рестартиране още на първия пакет след това получаваме отговор RST - и в двата случая клиентът разбира много бързо, че сървърът вече не го обича. Разбира се, и при NFS върху TCP има неприятни случаи, както конкретно този, за който всъщност май не мога да дам съвет... но неприятните случаи са доста по-малко, отколкото при UDP. Да, има малко overhead, иска малко повече буфери за подреждане на опашката от пакети, но като цяло си е по-добър вариант - дори и да не говорим за всякаквите хубави видове автентикации и криптиране и т.н. във NFSv4. Поздрави, Петър -- Peter Pentchev [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence,
pgpcqTNk4P21W.pgp
Description: PGP signature
_______________________________________________ Lug-bg mailing list [email protected] http://linux-bulgaria.org/mailman/listinfo/lug-bg
