История изменений

Не совсем понял, что надо пояснить, но попробую :)
Вот, например, смотрим на вывод «multipath -ll» двумя постами выше. Там 2 пути: один из них активный (status=active, по нему идет ввод/вывод), второй ждет своего часа (отказа активного пути). При отказе активного пути multipath может сразу (на самом деле не сразу, секунд на 15 ввод/вывод колом встанет по любому, но для простоты будем считать, что сразу), переключиться на другой путь, а может и накапливать I/O реквесты некоторое время в очереди, в надежде, что путь поднимется. Все это управляется опциями multipath. Для ОС и особенно кластерного софта отказ пути в зависимости от опций multipath может оказаться не прозрачным. Для разных массивов эти дефолтные опции, вкомпиленные в multipath, отличаются, и могут быть не те, что рекомендует вендор.

Другой пример - вендор может давно поддерживать и рекомендовать политику round-robin, а в multipath для данного массива до сих пор вкомпилен alua.

Не совсем понял, что надо пояснить, но попробую :)
Вот, например, смотрим на вывод «multipath -ll» двумя постами выше. Там 2 пути: один из них активный (status=active, по нему идет вврл/вывод), второй ждет своего часа (отказа активного пути). При отказе активного пути multipath может сразу (на самом деле не сразу, секунд на 15 ввод/вывод колом встанет по любому, но для простоты будем считать, что сразу), переключиться на другой путь, а может и накапливать I/O реквесты некоторое время в очереди, в надежде, что путь поднимется. Все это управляется опциями multipath. Для ОС и особенно кластерного софта отказ пути в зависимости от опций multipath может оказаться не прозрачным. Для разных массивов эти дефолтные опции, вкопиленные в multipath, отличаются, и могут быть не те, что рекомендует вендор.

Другой пример - вендор может давно поддерживать и рекомендовать политику round-robin, а в multipath для данного массива до сих пор вкомпилен alua.