LINUX.ORG.RU

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

Исправление sanyo1234, (текущая версия) :

У тебя скорее диск сдохнет или память сбойнёт.

Если ты сравниваешь с вероятностью обнаружения ошибок в OpenZFS или даже просто её нестабильностью вплоть до зависания пула до ребута всего хоста, то ты неправ. У меня дома никогда не помирали диски в пулах, проверенная оперативка тоже очень живучая даже без ECC. А вот подвисшие OpenZFS пулы я встречал, и даже приходилось перезагружать хост из-за таких подвисаний. А ещё иногда дурит resilvering после возврата offline устройств обратно в состояние online. Реализация OpenZFS очень сырая для использования в production. Именно поэтому и нужен DRBD кластер, чтобы если один пул начнёт капризничать, то можно было бы продолжать работу на другом пуле без downtime в то время, как приводишь мозги глючащего пула в нормальное состояние.

Одна из реализаций в один «прекрасный» момент может просто отказаться принимать поток, приняв его за несовместимые данные.

Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive при этом НЕ используется. Ещё раз, ZFS при использовании с DRBD нужен только вместо аппаратного рейда ибо в среднем сильно круче и надёжнее, несмотря на все свои глюки.

Если задача стоит переехать без даунтайма, ты перестрахуешься насколько это возможно.

Я вообще не понимаю, что там нужно @firkax и зачем, уже просил уточнить.

Исходная версия sanyo1234, :

У тебя скорее диск сдохнет или память сбойнёт.

Если ты сравниваешь с вероятностью обнаружения ошибок в OpenZFS или даже просто её нестабильностью вплоть до зависания пула до ребута всего хоста, то ты неправ. У меня дома никогда не помирали диски в пулах, проверенная оперативка тоже очень живучая даже без ECC. А вот подвисшие OpenZFS пулы я встречал, и даже приходилось перезагружать хост из-за таких подвисаний. А ещё иногда дурит resilvering после возврата offline устройств обратно в состояние online. Реализация OpenZFS очень сырая для использования в production. Именно поэтому и нужен DRBD кластер, чтобы если один пул начнёт капризничать, то можно было бы продолжать работу на другом пуле без downtime в то время, как приводишь мозги глючащего пула в нормальное состояние.

Одна из реализаций в один «прекрасный» момент может просто отказаться принимать поток, приняв его за несовместимые данные.

Синхронизация частей DRBD зеркала происходит на уровне DRBD, zfs send | receive при этом НЕ используется. Ещё раз, ZFS нужен только вместо аппаратного рейда ибо в среднем сильно круче и надёжнее, несмотря на все свои глюки.

Если задача стоит переехать без даунтайма, ты перестрахуешься насколько это возможно.

Я вообще не понимаю, что там нужно @firkax и зачем, уже просил уточнить.