LINUX.ORG.RU

NFS и обрыв связи с сервером

 , ,


0

1

Если смонтировать NFS и отключить NFS-сервер на удалённом серваке, то начинается настоящая беда: `df -h` вешает консоль, `umount /nfs_шара` делает тоже самое никак не реагируя на команду. Помнится лет 8 назад когда я ещё пользовался этим говном на FreeBSD была аналогичная проблема и решалась она какими-то специфическими ключами при монтировании nfs-шары, либо через umount с ключом -f (force), в OpenBSD же оно не работает. Спасает ребут, либо временное включение NFS-сервера.

Подскажите пожалуйста как сию проблему можно решить на OpenBSD (на Linux тоже интересует) более-менее человеческим способом.

Благодарю.

★★★★★

Ответ на: комментарий от takino

Да, про -i уже подсказали. Но мне интересно как выйти из сложившейся ситуации, а не в будущем. Должен же быть какой-то выход. А если его нет, то необходимо предложить разработчикам, ибо это не ок ни разу, имхо.

soko1 ★★★★★
() автор топика
Последнее исправление: soko1 (всего исправлений: 1)

http://mdoc.su/o/mount_nfs

     -i      Make the mount interruptible, which implies that file system
             calls that are delayed due to an unresponsive server will fail
             with EINTR when a termination signal is posted for the process.
и
     -s      A soft mount, which implies that file system calls will fail
             after retrans round trip timeout intervals have been reached (see
             -x).

А вообще, то, что ты описал — нормальное и стандартное поведение NFS. И неважно где. Кое-где есть конечно костыли и подпорки (umount -l -f и т.п.)

beastie ★★★★★
()
Ответ на: комментарий от soko1

Но мне интересно как выйти из сложившейся ситуации, а не в будущем.

Поднять другой NFS сервер на том же IP, что и оригинальный. Отмонтировать. Донор-сервер прибить.

ref (по аналогии): http://serverfault.com/questions/56588/unmount-a-nfs-mount-where-the-nfs-serv...

beastie ★★★★★
()
Ответ на: комментарий от beastie

А вообще, то, что ты описал — нормальное и стандартное поведение NFS.

Вот это очень хреново. Как будто не для людей сделано. Никогда не любил этот протокол.

soko1 ★★★★★
() автор топика
Ответ на: комментарий от soko1

Что поделать. При потере коннекта и обращении к 'диску' он уходить в 'disk state', а 'disk state', как мы все знаем, не прерываем.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Да оно у меня уже и при поднятом ранее NFS не хочет отмонтироваться, курва. Ребутать комп чтобы отмонтировать nfs-шару, 314ц какой-то. Хорошо что это не сервер.

soko1 ★★★★★
() автор топика
Ответ на: комментарий от beastie

Что поделать. При потере коннекта и обращении к 'диску' он уходить в 'disk state', а 'disk state', как мы все знаем, не прерываем.

Мне интересно чем руководствовались разработчики протокола при таком раскладе. Уж явно не головой :)

soko1 ★★★★★
() автор топика
Ответ на: комментарий от soko1

Ну, не забывай, когда и для чего это было сделано. =)

Это сейчас нестабильные интернеты, а раньше — это были ламповые стабильные локалки.

И основное применение NFS — это thin clients. А там, если сервер сдох, то и от клиента проку нету.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)

Я на линуксе решаю через umount -l

zinfandel ★★
()

Если смонтировать NFS и отключить NFS-сервер
отключить NFS-сервер

Почему сервер нужно отключать? Всмысле почему это считается нормальной, а не аварийной ситуацией?

А если писать на усб-диск и не дождавшись сброса буферов, выдернуть его? Это тоже проблема дизайна usb диска? О чем думали разработчики, когда не сделали программно управляемый замок на усб коннекторах?

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)

Рекомендации:

использовать autofs, тогда не используемые достаточное время nfs-шары будут размонтированы

монтировать с опцией intr и в крайнем случае soft

sdio ★★★★★
()
Ответ на: комментарий от sdio

Почему сервер нужно отключать? Всмысле почему это считается нормальной, а не аварийной ситуацией?

Всякое может случиться. Например, исчезнуть интернет. Особенно если речь идёт не о сервере, а о ноутбуке. Я и не утверждаю что это не аварийная ситуация, но с каждой аварийной ситуации должен быть какой-то выход кроме глупой перезагрузки. Согласен?

А если писать на усб-диск и не дождавшись сброса буферов, выдернуть его? Это тоже проблема дизайна usb диска? О чем думали разработчики, когда не сделали программно управляемый замок на усб коннекторах?

По крайней мере это не должно помешать работе ОС в целом.

soko1 ★★★★★
() автор топика
Ответ на: комментарий от soko1

По крайней мере это не должно помешать работе ОС в целом.

Если это конечно не FreeBSD 5.0...5.3, где такая ситуация приводила к кернел панику и ребуту :)

soko1 ★★★★★
() автор топика
Последнее исправление: soko1 (всего исправлений: 1)
Ответ на: комментарий от soko1

после восстановления связи, если сервер не перезагружался, работа продолжится. данные важнее всего иначе обрыв связи приведет к необратимой потере данных (незакрытых файлов)

sdio ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.