Смешанные кластеры ocfs2: прямой доступ и iscsi

Доброе утро,
У меня такая конфигурация:
схема конфигурации

Один «общий диск» с одним разделом, отформатированным как OCFS2
Хост A и хост B с прямым доступом к «общему диску»
Хост C с прямым доступом к «общему диску», используемому в качестве цели iSCSI, с linux tgt (iSCSI), настроенным для доступа к «общему диску»
Хост D и хост E с доступом к «общему диску» в качестве инициаторов iSCSI с использованием хоста C
Хост A, B, D и E являются частью одного кластера OCFS2

Я сделал эти тесты:
Одновременно монтируется общая файловая система с использованием OCFS2 только на хостах A и B (на каждом хосте демон ocfs2 регистрирует правильные соединения с кластером при монтировании раздела)
Одновременно смонтированы общие файловые системы с использованием OCFS2 только на хостах D и E. В этом случае каждый хост использует путь iSCSI к общему диску, и монтирование раздела ocfs2 работает правильно на каждом хосте одновременно.
Смонтировал общую файловую систему на хосте A и D (A с прямым доступом к общему диску и B с использованием пути iSCSI к цели iSCSI на хосте C) безуспешно. При монтировании на одном хосте другой, похоже, не видит присоединение к кластеру, и происходит повреждение данных с ошибками ocfs2 в журнале (ошибки пульса)

Этот последний случай является аргументом в пользу вопроса. Может быть проблема с кешем на iSCSI target (кеш блочного устройства или что-то еще)? Возможна ли такая конфигурация кластера при некоторой настройке iSCSI или это невозможно?

Спасибо

Маттео

iscsi ocfs2

После некоторого вникания в проблему, думаю, я мог бы найти решение.
Вместо использования файла устройства / dev / sd * для резервного хранилища на цели iscsi я использовал / dev / sg *
аналог с этой конфигурацией:

<target iqn.2018-02.test.it:lun1>
   <backing-store /dev/sg0>
      bs-type sg
      device-type pt
   </direct-store>
</target>

Как я подумал, возможно, решение может быть связано с кешем страниц на блочном устройстве, возможно, вместо этого sg с использованием прямых команд обходит это ... Я не знаю.
После изменения конфигурации я успешно попытался смонтировать на хосте A, D и E.
В / var / log / messages я обнаружил журнал соединения A, D и E, как и ожидалось, когда ocfs2 работает.
Я также создал тестовый файл и нашел его обновленным на каждом хосте.
На этой неделе я проведу еще несколько тестов, чтобы увидеть, может ли быть повреждение данных, и соответствующим образом обновлю сообщение.

Маттео

ОБНОВИТЬ
Казалось, что все работает правильно, но при выполнении большой копии (более 1 ГБ файлов) на общем диске с хоста на iscsi (инициаторе) хост выходит из строя, и на целевом tgt отображается эта ошибка:

mar 04 17:09:29 debian-shdisk-iscsi tgtd[1515]: tgtd: bs_sg_cmd_submit(228) failed to start cmd 0x0x559a50768510
mar 04 17:09:29 debian-shdisk-iscsi tgtd[1515]: tgtd: graceful_write(87) sg device 11 write failed, errno: 33

Кажется, что ошибка errno 33 (EDOM) в универсальном драйвере ядра Linux 4.19 scsi запускается при записи в очередь cmd, когда она заполнена. На стороне tgtd это, похоже, не обрабатывается, и это вызывает эту ошибку, генерирующую ошибки блока на стороне инициатора. Любое предложение?