NFSv4 после suspend/hybernate [solved]
Имеется сервер с net-fs/nfs-utils-1.2.0 (nfsv3 nfsv4 tcpd) на ядре 2.6.29-gentoo-r5 и клиент с пакетом той же версии и таким же ядром. Шара на клиенте подключается с помощью записей в fstab, навроде
homegate:/distfiles /usr/portage/distfiles nfs4 hard,intr,proto=tcp 0 0
при загрузке и работает замечательно.
Проблемы начинаются, если клиент отправится в спячку или ждущий режим, а затем выйдет из них часов через 5-6 или больше. Примерно до 5 минут не работают эти точки монтирования, не выводят содержимое и тд. После вроде начинает работать. Пробовал вручную отмонтировать эти шары перед уходом в сон. Не помогает: при включении и попытке подмонтироваться также тупняк минут 5. При этом никаких подозрительных сообщений не выводится (пробовал с mount -v). Поиск в интернете показал вот это:
http://linux-nfs.org/pipermail/nfsv4/2008-December/009610.html и http://marc.info/?l=linux-nfs&m=122477622004792&w=2
Вкратце: у человека та же самая проблема и в dmesg пробегают сообщения вида «nfs: server ... not responding, still trying». К сожалению, я слишком поздно полез смотреть, но не сомневаюсь, что проблема у меня такая же. По второй ссылке более подробно расписано.
If the server sends us an RST error while we're in the TCP_ESTABLISHED
state, then that will not result in a state change, and so the RPC client
ends up hanging forever (see
http://bugzilla.kernel.org/show_bug.cgi?id=11154)We can intercept the reset by setting up an sk->sk_error_report callback,
which will then allow us to initiate a proper shutdown and retry...We also make sure that if the send request receives an ECONNRESET, then we
shutdown too...
и даже дана ссылка на обсуждение ядра дебиана. Там обсуждают патч sunrpc и тд и тп.
У меня вопрос: уже используется ядро 2.6.29, на носу размаскировка 2.6.30, а проблема всё никак не может быть решена? Что у там у пользователей новым 2.6.30? Всё также nfs тупит? Или в моём случае надо другое смотреть?
Ах, да, клиент на amd64.
- Для комментирования войдите или зарегистрируйтесь
Заметил, что у ноутбука с x86
Заметил, что у ноутбука с x86 архитектурой и ядром той же версии, что и на сабжевом клиенте, проблем нет. Почему — непонятно. Сравнил в настройках ядра раздел File system-Network file system — критических отличий нет. Да и нечего там выбирать: nfsv4 клиент и всё с ним связанное.
А что если использовать
А что если использовать autofs, с маленьким таймаутом? (Монтирует при обращении к директории, после n секунд без обращения - отмонтирует) ?
Имею сообщить, что на 2.6.29
Имею сообщить, что на 2.6.29 (~x86) и ранее /etc/init.d/nfs restart однозначно результировал в OOPS, а с версии .30 все стало чисто и комфортно. Что там было, уже лень разбираться, да и вряд ли оно на вашу проблему похоже. Сублиминальный вам мессаж -- освежите ядро.
:}
Решил проблему. Останавливаю
Решил проблему. Останавливаю не только сервис монтирования, но и всё сопутствующее. Вот, скрипт, который отрабатывает при запуске suspend/hibernate и валяется по адресу /usr/lib64/pm-utils/sleep.d/20nfsmount:
#!/bin/sh . "${PM_FUNCTIONS}" case "$1" in hibernate|suspend) /etc/init.d/nfsmount stop /etc/init.d/rpc.idmapd stop /etc/init.d/rpc.statd stop ;; thaw|resume) /etc/init.d/rpc.statd start /etc/init.d/rpc.idmapd start /etc/init.d/nfsmount start ;; *) exit $NA ;; esacКроме того, надо поправить в скрипт запуска-останова монтирования, /etc/init.d/nfsmount из:
stop() { ebegin "Unmounting NFS filesystems" umount -a -t nfs,nfs4 eend $? }в
stop() { ebegin "Unmounting NFS filesystems" umount -l -a -t nfs,nfs4 eend $? }C неделю, как работает, вроде бы без проблем.