Re: [Lug-bg] NFS mounts след Sleep/Wake
- Subject: Re: [Lug-bg] NFS mounts след Sleep/Wake
- From: Peter Pentchev <roam@xxxxxxxxxxx>
- Date: Wed, 29 Oct 2008 11:28:21 +0200
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 roam@xxxxxxxxxxx roam@xxxxxxxx roam@xxxxxxxxxxx
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,
Attachment:
pgpKNXKNY2c5U.pgp
Description: PGP signature
_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg
|