Предотвращение разрыва соединения NFS от зависания клиентской системы

У нас есть общий ресурс NFS 4, разделяющий том между несколькими серверами (NFS-сервер и все клиенты Debian 8). Недавно у нас были некоторые проблемы, когда перебои в сети приводили к зависанию клиентских систем.

Наши параметры NFS были минимальными, просто rw(и так по умолчанию hard, fgи т. Д.).

Сейчас я экспериментирую с этими параметрами, но не получаю ожидаемого поведения: rw,soft,bg,retrans=6,timeo=150

(Я увеличил ретранс, чтобы компенсировать некоторый мягкий риск)

Процедура, которой я следую, чтобы проверить это:

• Загрузочная машина
• cd в /mnt/mountpoint
• Проверьте соединение NFS в порядке
• cd /
• убить сеть ifdown eth0
• cd в /mnt/mountpoint
• ls

В этот момент командная строка зависает, и я не могу ее прервать. Через некоторое время сообщение «nfs: server [servername] не отвечает, время ожидания истекло», которое, кажется, повторяется раз в минуту (неопределенно).

Что бы я хотел / ожидал, чтобы произошла ошибка операции и вернуть контроль.

Может кто-нибудь сказать мне, где я не так с этими настройками?

(PS: я также пытался монтировать с помощью autofs, но видел похожее поведение)

Спасибо

intrдолжен позволять вам снова получить контроль, когда вы нажмете ^C, но обычно не сразу.

   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.

Как вы говорите, ожидания являются проблемой здесь. Проблемы с сетью могут быть временными, но сбой операции является постоянным. Поэтому большинство операций по умолчанию просто блокируются, пока операция не завершится.

Это стандартный ответ, но, глядя на текущую справочную страницу, я вижу это:

                  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.

Так что это не проблема NFS3 / NFS4, а решение о том, как это intrработает. Таким образом, вы должны быть в состоянии KILLв процессе, но это может не дать вам много пользы.

Мне не удалось найти обсуждение того, почему опция была удалена. Можете ли вы убить-убить свой процесс?

Некоторые из моих ответов - это мнение, основанное на опыте. Там, где у меня есть факты, я постараюсь (не забывать) ссылаться на них.

1. NFS 4 считается улучшением по сравнению с версиями 2 и 3. Тем не менее, я еще не видел сильного варианта использования для нужд улучшений. Возможно, это потому, что я стремлюсь экспортировать файловые системы для клиентов Windows с Samba и для клиентов Unix / Linux с NFS.
2. Я не рекомендовал бы ни softпри каких обстоятельствах. Это позволяет сбрасывать данные при ошибке . Вместо этого я бы предложил hard,intr.
3. Как вы указываете, intrэто не подходит для NFS 4, но кажется, что это изменение ядра, а не NFS.
4. NFS Automounter ( autofs) хорошо работает для моих сценариев использования с NFS версий 2 и 3 и помогает защитить мои клиентские системы от сбоев сервера, монтируя файловые системы NFS только тогда, когда они необходимы.

Я предлагаю вам рассмотреть вопрос о переходе с NFS 4 на NFS 3 и посмотреть, поможет ли это в вашем конкретном случае использования. Не думайте об этом как о понижении рейтинга.