Сервер A раньше был сервером NFS. Сервер B монтировал экспорт этого. Все было отлично. Затем А умер. Просто выключил. Ушел. Пропал.
Однако эта папка все еще монтируется на B. Я, очевидно, не могу cd
в нее или что-либо еще. Однако umount /mnt/myfolder
просто виснет и не будет размонтироваться. Можно ли как-то размонтировать его без перезапуска B?
И клиент, и сервер являются машинами Linux.
Предполагая Linux:
umount -f -l /mnt/myfolder
Будет вроде решить проблему:
-f
Принудительное отключение (в случае недоступности системы NFS). (Требуется ядро 2.1.116 или новее.)
-l
Ленивый демонтировать. Отключите файловую систему от иерархии файловой системы и очистите все ссылки на файловую систему, как только она больше не будет занята. (Требуется ядро 2.4.11 или новее.)
-f
также существует в Solaris и AIX.
Разработка намека дано Дэвидом Пашли ,
если "umount -l" не решит вашу проблему, вы можете настроить фальшивый сервер с тем же адресом, что и ушедший - но вам на самом деле не нужно устанавливать новый разорвать или что-нибудь. Самый простой выход из ситуации блокировки/зависания - это настроить локальный IP-интерфейс псевдонима следующим образом:
ifconfig eth0:nfstmp 11.22.33.44 netmask 255.255.255.255
umount -l /mnt/deadnfsmount # -l or -f or whichever that gets the job done
ifconfig eth0:nfstmp down
(очевидно, что 11.22.33.44 является (прежним) IP-адресом (ныне мертвого) NFS-сервера)
Возможно, было бы целесообразно добавить параметр intr
к любому /etc/fstab
записи, которые могут закончиться зависанием или падением. Если вы не используете параметры soft
или intr
, то когда сервер, на котором размещены файлы NFS, выходит из строя, сервер, на котором монтируются файлы (клиент), может зависнуть при загрузке ,.
В соответствии с man 5 nfs
:
мягкий/жесткий
Определяет поведение восстановления клиента NFS после истечения времени ожидания запроса NFS. Если ни одна из этих опций не указана (или если указана сложная опция), запросы NFS повторяются бесконечно. Если указана программная опция, то клиент NFS не выполнит запрос NFS после повторной передачи ретрансляций, в результате чего клиент NFS вернет ошибку вызывающему приложению.
... и далее он говорит, что intr
предпочтительнее soft
, но имеет аналогичный эффект предотвращения зависания.
umount -f /mnt/myfolder
должен решить это. Смотрите страницу руководства umount.
Для Solaris перезапуск клиента NFS разрешит "жесткую спираль смерти". Команда для Solaris 10: "svcadm restart network/nfs/client". В последнее время я не пробовал это на Linux-боксе (потому что все они монтируются с флагом "intr", поэтому у них редко возникает эта проблема), но, вероятно, это тоже исправит проблема.
Мне никогда не удавалось получить umount -f
работать. Полезный прием - настроить другой сервер, монтирующий тот же экспорт, присвоив ему тот же IP-адрес, что и у старого сервера. Ваш клиент NFS должен думать, что все вернулось как обычно, и процессы будут разблокированы. Затем вы можете размонтировать точку монтирования и удалить IP-адрес с временного сервера NFS.
Кроме того, использование automount будет обрабатывать размонтирование общих ресурсов NFS, когда они станут доступны, что позволит избежать застревания в этой ситуации в будущем.
Я встречал эту же проблему. Поскольку сервер NFS был удален, я не могу размонтировать nfs из клиента. Я попробовал следующий трюк, посмотрите, может ли он быть полезным. Поскольку исходный сервер NFS пропал, я создаю новый сервер с тем же IP-адресом и экспортом. Затем я пытаюсь umount -f/mnt/nfs_part. Теперь я наконец смог размонтировать NFS.
просто специфическое для OS X продолжение, так как команды монтирования в основном не зависят от nix: флаг -l (lazy) не существует в OS X, однако флаг -f (force) существует и оказался достаточным , Кроме того, сгенерированные системой точки монтирования находятся в/Volumes (/ Volumes/myserversexport)
Я только что заметил, что принудительное отключение в ядре 3.2.0 зависает при подключении NFSv4. Размонтирование NFSv3 работает нормально.
$ mount [...] -o nfsvers=3