Запись через multipath. Почему не происходит повреждение порядка запросов с затиранием новых данных старыми (out-of-order)?

Следующая команда не посылается, пока не получен ответ на предыдущую?

Почему не происходит гонки состояний при соединении через двух провайдеров (медленного и быстрого) с балансировкой нагрузки?

происходит. Просто tcp знает про это и восстанавливает порядок.

С udp сложнее. Часть приложение/протоколов знает об этом и умеет бороться, часть - нет.

Следующая команда не посылается, пока не получен ответ на предыдущую?

Неа. Иначе бы iSCSI на длинных линках через интернеты бы пипец как тормозил. Надо очередь делать, чтобы всё быстро работало.

Почему не происходит гонки состояний при соединении через двух провайдеров (медленного и быстрого) с балансировкой нагрузки?

Происходит даже иногда даже внутри одного линка, если он идёт через интернеты. TCP-стек и UDP-приложения знают о том, что всё может пойти не так.
Но мультипас - это не тот случай.

Кстати, если нету BGP, подмены IP или прочей магии, то нагрузка распределяться может только через сессии (одну - на один канал, другую - на другой).

Неа.

Во-первых, в iSCSI используется TCP. Во-вторых, в айскази каждая команда, каждый ответ, статус, блок данных нумеруются по порядку. В-третьих, некоторые части протокола действительно выполняются строго синхронно: инициатор обязан дождаться статуса выполнения таких команд, прежде чем отправлять следующие.

Причём тут вообще iSCSI? Это просто пример. Multipath над ним стоит. И может вообще работать с любыми блочными девайсами. Например: SAS+FC+iSCSI в гибридном хранилище.

Причём тут вообще iSCSI? Это просто пример.

При том, что iSCSI сам по себе умеет несколько соединений в пределах одной сессии, в том числе через несколько сетевых интерфейсов одновременно в некоторых реализациях. Это просто пример.

Я тебе рассказываю о применяемых механизмах. И начал с напоминания о том, что протокол SCSI изначально насквозь синхронный: инициатор /обязан/ дождаться завершения предыдущей команды и получить её статус перед подачей следующей.

Для ускорения работы существует расширение TCQ: можно помещать /нумерованные/ задания чтения/записи в очередь, передавая полностью или частично решение о порядке их выполнения устройству. Но опять-таки, ты сперва создаешь очередь, а потом она выполняется.

baka-kun ★★★★★ (16.01.2016 0:51:33) шарит в storage

as expected

И начал с напоминания о том, что протокол SCSI изначально насквозь синхронный: инициатор /обязан/ дождаться завершения предыдущей команды и получить её статус перед подачей следующей.

Не совсем так. SCSI изначально асинхронный протокол. Если брать исходный параллельный SCSI, то после получения команды таргетом вся инициатива переходит к таргету: он сам делает DISCONNECT от шины, чтобы ее могли использовать другие устройства. С этого момента инициатор может заниматься чем угодно - например, посылать другие команды. Когда же таргет выполнит команду, он сам сделает RECONNECT к инициатору и пошлет ему данные (если команда это подразумевает) и статус команды. Другое дело, что после получения DISCONNECT инициатор знает, что таргет получил команду, и это уже его обязанность гарантировать, чтобы 2 команды записи в один и тот же блок были выполнены в той же последовательности, в которой он их получил.
Хотя параллельный SCSI ушел в небытие, не думаю, что протокол сильно изменился при обертке его в FC/SAS/FCoE.

Если говорить об FC, то там есть различные классы сервиса, которые могут гарантировать порядок доставки PDU или даже отдельных фреймов. Но наиболее часто используемый Class-3 этого не гарантирует. Также это зависит от топологии - для фабрик состоящих из одного коммутатора, и тем более для P2P и FC-AL, порядок доставки фреймов гарантируется. Для фабрик из нескольких коммутаторов - вообще говоря, не гарантируется. Хотя современные коммутаторы вроде умеют это.

Но при отправке 2-х команд записи через 2 разные фабрики двум разным контроллерам все равно может быть гонка. И, мне кажется, что multiptath на хосте должен это предотвращать.

SCSI изначально асинхронный протокол.

Давай не путать божий дар с яичницей. Абсолютно наплевать, что там происходит на физическом, сетевом или транспортном уровне, поскольку на прикладном скази работает именно так, как описано.

все равно может быть гонка

Прикладной уровень SCSI, то есть та часть, которая посылает/принимает команды и отвечает на них, ничего не знает о том, какими путями ходят CDB. Ему и не нужно — он никогда не отправит две противоречащие команды одновременно. Что там device-mapper делает внутри себя, ему тоже по барабану.

Получается, что SCSI тут ни при чем.
DM-Multipath стоит очень высоко в стеке I/O, и балансировка происходит задолго то того, как дело дойдет до уровня SCSI. Фактически dm-multipath отправляет 1000 bio одному блочному устройству, следующие 1000 bio другому, и т.д. по round-robin. Потом они еще и планировщиком I/O переупорядочиваются, т.е. порядок их выполнения тоже по барабану. Видимо, это забота кода ядра более высокого уровня (например, драйвера ФС) не отправлять 2 конфликтующих I/O запроса одновременно.

Именно так, вы отняли у меня хаятельную речь, в который бы я объяснил юнцу, чем отличается scsi generic device от block device, и что к первому MP линукса отношения не имеет (соответственно на синхронность (подтверждение) или нумерацию в очереди не смотрит).

Видимо, это забота кода ядра более высокого уровня (например, драйвера ФС) не отправлять 2 конфликтующих I/O запроса одновременно.

Уже более интересная мысль. А если ФС тупая или вообще приложение (БД) работает прямо поверх блочного устройства?

И, мне кажется, что multiptath на хосте должен это предотвращать.

Хрен там был.

Давай не путать божий дар с яичницей. Абсолютно наплевать, что там происходит на физическом, сетевом или транспортном уровне, поскольку на прикладном скази работает именно так, как описано.

Запись через multipath. Почему не происходит повреждение порядка запросов с затиранием новых данных старыми (out-of-order)? (комментарий)

Разберитесь уже с абстракциями блочного уровня и SCSI.