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

openbsd:
http://www.monkey.org/openbsd/archive/misc/9910/msg00455.html

Try a soft mount or an interruptable mount (see mount_nfs(8), esp.
the -i and -s flags). But if you mounted the device hard (default),
you're hosed, either wait for the connection to come up again or reboot.
Regards, Hannah.

linux:
флаги lazy, force (lazy - just detach fs, force - Force unmount (in case of an unreachable NFS system).

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

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 и т.п.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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