Я пытаюсь понять поведение ZFS при определенных условиях, но в документации об этом не очень подробно сказано, поэтому я остаюсь гадать.
Предположим, у нас есть zpool с избыточностью. Возьмем следующую последовательность событий:
Проблема возникает в связи между устройством D и сервером. Это вызывает большое количество сбоев, и поэтому ZFS вызывает сбой устройства, переводя пул в ухудшенное состояние.
Пока пул находится в деградированном состоянии, пул видоизменяется (данные записываются и / или изменяются).
Проблема с подключением физически устранена, и устройство D снова надежен.
Зная, что большая часть данных на D действительна, и не желая напрасно нагружать пул резервным копированием, администратор вместо этого запускает zpool clear pool D. Это указано в документации Oracle как соответствующее действие, если ошибка возникла из-за временной проблемы, которая была исправлена.
Я читал это zpool clear только очищает счетчик ошибок и восстанавливает устройство в онлайн-состоянии. Однако это немного беспокоит, потому что если это все он оставит пул в несогласованном состоянии!
Это связано с тем, что мутации на шаге 2 не будут успешно записаны в D. Вместо этого D будет отражать состояние пула до сбоя подключения. Это, конечно, не стандартное состояние для zpool и может привести к полной потере данных при выходе из строя другого устройства - однако статус пула не будет отражать эту проблему!
Я бы по крайней мере предположил, основываясь на надежных механизмах целостности ZFS, что попытка прочитать измененные данные из D обнаружит ошибки и исправит их. Однако здесь возникают две проблемы:
Операции чтения не гарантируют попадание во все мутации, если не выполняется очистка; и
Однажды ZFS делает ударил измененные данные, это (я предполагаю) может снова привести к неисправности диска, потому что ZFS может показаться, что это повреждает данные, поскольку он не помнит предыдущие сбои записи.
Теоретически ZFS может обойти эту проблему, отслеживая мутации, происходящие во время деградированного состояния, и записывая их обратно в D, когда он очищается. Однако по некоторым причинам я подозреваю, что этого не происходит.
Я надеюсь, что кто-то, хорошо знакомый с ZFS, сможет пролить свет на этот аспект.
«Теоретически ZFS может обойти эту проблему, отслеживая мутации, которые происходят во время деградированного состояния, и записывая их обратно в D, когда он очищен. Однако по некоторым причинам я подозреваю, что это не то, что происходит».
Собственно, это почти именно то, что он может сделать в данной ситуации. Видите ли, каждый раз, когда диск в пуле ZFS записывается, на диск записывается идентификатор транзакции текущего глобального пула. Скажем, например, что у вас есть описанный вами сценарий, и общее время между потерей соединения и восстановлением меньше 127 * txg_timeout (и это делает много грубых предположений о нагрузке на пул и некоторых других вещах. , но скажите половину этого значения для типичной безопасности, поэтому, если txg_timeout составляет 10 секунд, тогда 600 секунд или 10 минут - разумное время, чтобы ожидать, что это все еще будет работать).
В момент перед отключением пул смог успешно выполнить запись, связанную с идентификатором транзакции 20192. Проходит время, и диск возвращается. В то время, когда диск снова становится доступным, пул прошел через несколько групп транзакций и находится на идентификаторе транзакции 20209. На этом этапе все еще есть все возможности, что ZFS может сделать то, что называется «быстрым восстановлением», при этом выполняется перенос диска, но ТОЛЬКО для идентификаторов транзакции с 20193 по 20209, в отличие от полного восстановления диска. Это быстро и эффективно восстанавливает диск в соответствии со спецификациями остальной части пула.
Однако метод запуска этого действия - это не zpool clear. Если все работает как надо, resilver должен был быть запущен автоматически, как только диск снова стал здоровым. На самом деле, это могло быть так быстро, что вы никогда этого не видели. В этом случае «zpool clear» будет правильным действием для очистки счетчика все еще видимых ошибок, которые могли бы появиться, когда устройство вообще исчезло. В зависимости от версии zfs, которую вы используете, от какой ОС она работает, каким образом устройство отображается в zfs в данный момент и как долго оно находится в этом состоянии, «правильный» способ исправить это различается. На самом деле это может быть 'zpool clear' (очистка ошибок, и следующий доступ к диску должен заметить рассинхронизирующий идентификатор txg и нажать на resilver) или вам может потребоваться использовать 'zpool online' или 'zpool replace' .
Когда все это работает правильно, я привык видеть, что диск исчезает и диск переходит в состояние OFFLINE, DEGRADED, FAULTED, UNAVAIL или REMOVED. Затем, когда диск снова становится доступным на уровне ОС, включаются FMA и другие механизмы ОС, и ZFS узнает, что диск вернулся, и происходит быстрое восстановление, и устройство снова отображается в состоянии zpool как ОНЛАЙН, но может все еще иметь количество ошибок, связанных с ним. Ключ в том, что он находится в состоянии ONLINE, что указывает на успешное автоматическое восстановление (восстановление). Вы можете протестировать его на любом диске, вытащив его, подождав несколько секунд и проверив «zpool status», а затем снова подключив диск и снова проверив «zpool status» и посмотрев, что произойдет. ZFS - не единственная движущаяся часть здесь - ZFS на самом деле в значительной степени полагается на другие механизмы ОС, чтобы информировать его о состоянии диска, и если эти механизмы не работают, вы получите другие симптомы, чем если бы они были успешными.
В любом случае либо быстрое восстановление может быть запущено и успешно, либо это невозможно или не удается. В последнем случае диск будет иметь для завершения полного переноса данных перед возвращением к работе, поэтому две ваши проблемы, перечисленные в нижней части сообщения, обычно не должны быть возможны, если административное переопределение не позволило диску с несоответствующим txgid повторно войти в пул без какой-либо формы исправления для это несоответствие (обычно не может быть возможным). ЕСЛИ это должно было произойти, я бы подозревал, что следующий доступ к диску либо приведет к запуску этого быстрого восстановления (и удастся, или потерпит неудачу и выбьет диск до полного восстановления), либо это закончится тем, что диск будет вытеснен - - или, возможно, паника из-за несоответствия txgid. В любом из этих событий не произойдет потери данных или возврата неверных данных в запрос.
Обратите внимание, что:
zpool scrub ZFSPOOL восстановит данные или распространит данные на все работающие диски для RADZ.У меня было много ошибок DMA на дисках, когда проблема с кондиционером в центре обработки данных и ZFS смогла исправить этот беспорядок. И это было просто зеркало.
Я действительно помню промо-видео, выпущенное SUN, когда они представили ZFS ... они сделали RAIDZ на USB-накопителях, развернутых на 8-портовый USB-концентратор, а затем случайным образом изменили положение в концентраторе для некоторых из них, выполняя ввод-вывод в этом пуле, не наблюдая сбоев.