forum.lissyara.su

Добрый день!

Всех с наступившими!

Вопрос к имеющим опыт с подключением диска по сети через iscsi на FreeBSD.

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

Хотелось бы, чтобы устройство (например /dev/da0) исчезало при отсутствии связи через iscsi через некоторое время.

Это возможно сделать?

Если нет, как можно отключать его вручную?

Пробовал послать процессу iscontrol сигнал SIGHUP (как написано в man). iscontrol при этом пишет на консоль, что завершился,
но на самом деле продолжает висеть как процесс и устройство da0 не исчезает (а использующее его приложение продолжает висеть).

Через camcontrol удалить da0 также не получается (или я делаю это неправильно).

При запуске iscontrol снова (и починке связи перед этим) - появляется новый процесс, новая сессия, da0 не начинает работать, и этот процесс также не убивается.

Итог - имею на сервере два зависших iscontrol, fdisk, который пытается считать с da0, и это никак не убивается ))


В общем-то идея шире. Требуется работа ZFS с физическим диском через iSCSI.
Если бы у ZFS был свой тайм-аут по неотклику части зеркала (которая доступна через iscsi) - то текущее поведение iscsi устроило бы.
Но ZFS реагирует только на удаление устройства из /dev. Если оно там есть но не откликается - система замирает в ожидании его отклика.

надо процессы килять думаю...
которые его юзают.

Здесь обсуждали, но видимо ни к чему не пришли.
http://www.mail-archive.com/open-iscsi@ ... 00766.html

iscontrol убивается по kill -HUP

Mox писал(а):iscontrol убивается по kill -HUP

Если устройство занято, то не киляется (что, собственно, автор и указал в посте).
Вообще, процессы, зависшие на IO не киляются. Вечная проблема

Спасибо за советы.

Да, iscontrol как бы "убивается" но реально продолжает висеть как зомби и висят все приложения использовавшие диск.

Обсуждение вроде-бы видел. Но оно древнее и про линукс. В нем то вроде-бы пофиксили.
В линуксе есть вот такие опции:
http://linux-iscsi.sourceforge.net/iscsi.conf.5.html

ConnFailTimeout=<secs>
Specify the time in seconds to wait for a session re-establishment. If a session is not re-established in 'ConnFailTimeout' seconds then I/Os on the session will be failed immediately without honoring the timeout associated with the SCSI command. By default the timeout value is 0 which means no timeout.
MinDiskCommandTimeout=<secs>
Specify the minimum time in seconds to wait before failing commands to a target device. If this entry is not present in the conf file, a default value of -1 is taken by the driver, which disables the command timeout, allowing commands to be retried forever.
MaxDiskCommandTimeout=<secs>
Specify the maximum time in seconds to wait before failing commands to a target device. If multipath is enabled, the MaxDiskCommandTimeout can be set to a smaller value, say 5 or 10 seconds. The default value is 0.

Фря на эти опции плюет (хоть и не ругается что они есть в конфиге).
Со стороны target задание их также не дает эффекта (тоже не ругается на наличие в конфиге).

Может есть возможность поставить альтернативный iscsi initiator в FreeBSD?

Проблема слишком уж явная и не позволяет делать кластерные решения на iscsi. А альтернативы протоколу нет.

ZFS тоже хорош - нельзя даже отключить зависшее устройство
zpool detach подвисает, пока не получит-таки связи с ним.
zpool offline делает то же самое!

Т.е. нет никакого способа сказать на уровне iscsi или zfs, что удаленный диск отвалился даже вручную!

Интересно, как же устроен HAST что он работает? Видимо, придется юзать его, но ждать синхронизации 2 Тб через сеть при каждой рассинхронизации в байт- совсем не хотелось бы
(ZFS синхронизирует (resilver) только изменения).

Пару недель назад воевал тоже с ZFS на iscsi. На 10-й солярке. Проблема была в другом - после ребута сервера zpool status говорил, что диск offline. Хотя он был живой. Помогало только zpool destroy / zpool import... помогла установка патча, выпущенного ораклом только в феврале этого года.
После выходных попробую отключить массив - гляну как соляра реагирует

Только что вспомнил, что столкнулся с ситуацией, что fibre channel поднимался намного позже zfs, а у меня по FC были подключены диски и создал пул. В итоге тоже писало, что диск offline. Пришлось отказаться от подключения дисков по FC.
Solaris 11.

например конфиг /etc/iscsi.conf отвалился второй диск

надо выполнить