mount.cifs: как избежать длительных тайм-аутов после переключения IP-адресов (проводной <=> wifi)

При отсоединении моего ноутбука от док-станции с помощью проводного Ethernet-подключения я позволил администратору сети автоматически включить радио Wi-Fi. При входе в док-станцию ​​я позволил ей отключить Wi-Fi, потому что проводное соединение предпочтительнее.

Проблема: все обращения к файлам или папкам на общих ресурсах cifs, которые я монтировал перед зависанием на 120 секунд. Это приводит к зависанию приложений, если они получают доступ к этим общим ресурсам (например, сеансы оболочки в этих каталогах, файловые менеджеры с открытой вкладкой и т. Д.). Их процессы застряли в ужасном непрерывном состоянии.

Журнал ядра сообщает: kernel: CIFS VFS: сервер не ответил в течение 120 секунд. Воссоединение...

Вопрос: Как я могу сократить этот тайм-аут, чтобы мне не приходилось тратить 2 с лишним минуты на кофе каждый раз, когда я переключаюсь на док-станцию ​​и обратно, потому что все мои приложения зависают?

Больше деталей:

  • Оба интерфейса имеют разные IP-адреса в одной подсети и, очевидно, оба могут достигать файлового сервера.
  • Пример строки /etc/fstab:

    // сервер / установка /mnt/net/install cifs uid=bob, учетные данные =/etc/cifs-учетные данные,_netdev, пользователь,soft 0 0

  • пример вывода из монтирования | grep cifs:

    // сервер / установить в / mnt / net / установить тип cifs (rw,nosuid,nodev,noexec,relaytime,vers=1.0, кеш = строгий,username=bob, домен =bobsdom,uid=1000,forceuid,gid=0,noforcegid, адр =[ServerIP], Unix,posixpaths,serverino, ACL,rsize=1048576,wsize=65536,actimeo=1,_netdev, пользователь)

Что я пробовал:

  • Варианты "мягкого" и "жесткого" монтажа. Они не меняют это поведение, хотя текст справочной страницы "soft" предполагает, что
  • Убедитесь, что на любом интерфейсе нет потери пакетов, а задержки и пропускная способность превосходны (Ethernet GBit и Wi-Fi 802.11ac с сильным сигналом). Это дает мне уверенность, что это действительно тайм-аут CIFS из-за смены IP-адреса.
  • Сервер (samba 3.6) не имеет проблем с сетью и потери пакетов.
  • Погуглил ручку в cifs, чтобы уменьшить время ожидания до 15 секунд. Только нашел один для Windows. Он называется HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\SessTimeout и является именно тем , что я хочу. Интересно, что MS также сократила время ожидания в Win 8.1 до 20 секунд...
  • Использование метрик маршрута вместо включения / выключения Wi-Fi, чтобы оба маршрута работали, и чтобы ядро ​​просто предпочитало маршрут Ethernet. Однако этот подход имеет недостатки, поскольку ядро ​​отправляет ответы на пакеты, поступающие по беспроводному выходу через проводной интерфейс. Может быть решена с помощью некоторой магии "IP-правила", но я бы действительно предпочел просто включить радио Wi-Fi.

1 ответ

Одно из рабочих решений - настроить оба интерфейса на один и тот же статический IP-адрес. Таким образом, cifs не работает по таймауту, потому что ему не нужно повторно устанавливать соединение с другого IP в той же подсети.

Это также означает, что SSH-соединения остаются активными во время проводных<=>переключателей Wi-Fi без необходимости использования таких необычных инструментов, как Mosh.

У него тоже есть недостатки:

  • Требуются статические IP-адреса вместо DHCP
  • Конфликт IP, если оба моих интерфейса работают одновременно. Мой скрипт диспетчера сети предотвращает это, однако.
Другие вопросы по тегам