Zapobieganie zawieszaniu się systemu klienta przez zerwane połączenie NFS

Mamy udział NFS 4, dzielący wolumen między wieloma serwerami (serwer NFS i klienci wszyscy Debian 8). Mieliśmy ostatnio problemy z awariami sieci powodującymi zamrożenie systemów klienckich.

Nasze opcje NFS były minimalne, tylko rw(a więc domyślne hard, fgitp).

Teraz eksperymentuję z tymi opcjami, ale nie otrzymuję oczekiwanego zachowania: rw,soft,bg,retrans=6,timeo=150

(Zwiększyłem retrans, aby zrównoważyć część ryzyka miękkiego)

Procedura, którą testuję, to:

• Maszyna rozruchowa
• cd do /mnt/mountpoint
• Sprawdź poprawność połączenia NFS
• cd /
• zabić sieć ifdown eth0
• cd do /mnt/mountpoint
• ls

W tym momencie linia poleceń zawiesza się i nie mogę jej przerwać. Po pewnym czasie komunikat „nfs: server [nazwa serwera] nie odpowiada, upłynął limit czasu”, który wydaje się powtarzać raz na minutę (w nieokreślony sposób).

Co chciałbym / mam się spodziewać, aby operacja zakończyła się niepowodzeniem i zwróci kontrolę.

Czy ktoś mógłby mi powiedzieć, co robię źle z tymi ustawieniami?

(PS: Próbowałem również montować przy użyciu autofs, ale widziałem podobne zachowanie)

Dziękuję Ci

intrpowinny pozwolić ci odzyskać kontrolę po trafieniu ^C, ale zwykle nie od razu.

   intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the
                  file  operation  and cause it to return EINTR to the calling program.  The default is to not allow file
                  operations to be interrupted.

Jak mówisz, problemem są tutaj oczekiwania. Problemy z siecią mogą być tymczasowe, ale niepowodzenie operacji jest trwałe. Dlatego większość operacji domyślnie blokuje się, dopóki operacja się nie zakończy.

To standardowa odpowiedź, ale patrząc na bieżącą stronę podręcznika widzę to:

                  The  intr / nointr mount option is deprecated after ker-
                  nel 2.6.25.  Only SIGKILL can interrupt  a  pending  NFS
                  operation on these kernels, and if specified, this mount
                  option is ignored  to  provide  backwards  compatibility
                  with older kernels.

Więc nie wydaje mi się to problemem NFS3 / NFS4, ale decyzja o tym, jak intrdziała. Powinieneś być w stanie wykonać KILLten proces, ale to może nie dać ci wiele użyteczności.

Nie udało mi się znaleźć dyskusji na temat przyczyny usunięcia tej opcji. Czy możesz zabić - ZABIJ swój proces?

Niektóre z moich odpowiedzi to opinia oparta na doświadczeniu. Tam, gdzie mam fakty, będę (staram się pamiętać) link do nich.

1. NFS 4 jest uważany za ulepszenie w stosunku do wersji 2 i 3. Jednak nie widziałem jeszcze mocnego argumentu przemawiającego za potrzebą ulepszeń. Być może dlatego, że zamierzam eksportować systemy plików do klientów Windows z Sambą i do klientów Unix / Linux z NFS.
2. Nie polecałbym softw prawie żadnych okolicznościach. Pozwala to na odrzucenie danych w przypadku błędu . Zamiast tego sugerowałbym hard,intr.
3. Jak zauważyłeś, intrnie działa na NFS 4, ale wydaje się, że jest to zmiana jądra a nie NFS.
4. NFS Automounter ( autofs) działa dobrze w moich przypadkach użycia z NFS w wersji 2 i 3, i pomaga chronić moje systemy klienckie przed awarią serwera poprzez montowanie systemów plików NFS tylko wtedy, gdy są one wymagane.

Moją sugestią byłoby rozważenie przejścia z NFS 4 na NFS 3 i sprawdzenie, czy to pomoże w konkretnym przypadku użycia. Nie myśl o tym jako o obniżeniu wersji.