Описание сообщений об ошибках ZFS (в Linux)

Bueno... ¿elegante?,sí (solo una muestra rápida):

eval echo $(printf "%s" '{{a..z},{A..Z},{0..9}}'{,,} )

Es muy probable que esta expresión completa bloquee su computadora:

eval echo $(printf "%s" '{{a..z},{A..Z},{0..9}}'{,,,,} )

Una opción de bloqueo no -es usar varios bucles:

nl=$'\n'; tab=$'\t'
n=${1:-3}
eval set -- "$2"

eval "varnames=($(echo {a..z}))"

for i in "${varnames[@]:0:$n}"; do
    header+='for '"$i"' do '
    middle+='$'"$i"
    traile+="done; "
done

loop="${header}${nl}    printf %s \"$middle\";${nl}$traile"
#echo "$loop"
eval "$loop"

Llámalo como:

./script 3 '{a..z} {A..Z} {0..9}'

Donde el primer argumento es el número de caracteres y el segundo es la lista (separada por espacios )de los caracteres utilizados.

Eso generará una variable(loop)con el script a ejecutar y la última evaluación ejecutará ese script. Por ejemplo para:

$./script 5 '{a..z} {A..Z} {0..9}'

El valor de loopserá:

for a do for b do for c do for d do for e do
    echo "$a$b$c$d$e";
done; done; done; done; done;
6
16.11.2018, 22:07
2 ответа

Для общего обзора см. Решение проблем с ZFS , наиболее интересная часть:

Во втором разделе выходных данных конфигурации отображается статистика ошибок. Эти ошибки делятся на три категории:

  • READ - ошибки ввода / вывода, которые произошли при выдаче запроса на чтение
  • WRITE - ошибки ввода / вывода, возникшие при выдаче запроса на запись
  • CKSUM - ошибки контрольной суммы, означающие, что устройство вернуло поврежденные данные в результате запроса на чтение

. Эти ошибки можно использовать, чтобы определить, является ли повреждение постоянным. Небольшое количество ошибок ввода-вывода может указывать на временный сбой, в то время как большое количество может указывать на постоянную проблему с устройством. Эти ошибки не обязательно соответствуют повреждению данных в интерпретации приложений. Если устройство находится в резервной конфигурации, устройства могут показывать неисправимые ошибки, в то время как ошибки не появляются на уровне зеркала или устройства RAID-Z.В таких случаях ZFS успешно извлекла нужные данные и попыталась восстановить поврежденные данные из существующих реплик.


Теперь к вашим вопросам:

Во-первых, что означает «устройство» в этом контексте? Они говорят о физическом устройстве, vdev или еще о чем-то? Я предполагаю, что они говорят о каждом «устройстве» в иерархии. В этом случае количество ошибок vdev, вероятно, является суммой подсчетов ошибок его физических устройств, а количество ошибок пула, вероятно, является суммой подсчетов ошибок его vdev. Это правильно?

Каждое устройство проверяется независимо, и все его ошибки суммируются. Если такая ошибка присутствует на обоих зеркалах или сам vdev не является избыточным, он распространяется вверх. Другими словами, это количество ошибок, влияющих на сам vdev (что также соответствует логике отображения каждой строки отдельно).

Но меня действительно интересует, были ли ошибки контрольной суммы на уровне ZFS (а не на уровне оборудования). В настоящее время я убежден, что CKSUM показывает последнее (иначе это не имело бы особого смысла), но я хотел бы знать наверняка.

Да, это аппаратная часть (непостоянные вещи, такие как неисправные кабели, внезапно извлеченные диски, потеря мощности и т. Д.). Я думаю, что это тоже перспектива: сбои на «стороне программного обеспечения» будут означать ошибки в самой ZFS, поэтому нежелательное поведение, которое не было проверено (при условии, что все обычные действия пользователя считаются правильными), и которое не распознается самой ZFS. К счастью, в настоящее время они довольно редки. К сожалению, в большинстве случаев они также довольно серьезны.

В-третьих, если предположить, что ошибки контрольной суммы, о которых они говорят, действительно являются ошибками контрольной суммы на уровне ZFS (а не на уровне оборудования), почему, черт возьми, они показывают только количество неисправимых ошибок? В этом нет никакого смысла. Мы бы хотели видеть каждую ошибку контрольной суммы, исправимую или нет, не так ли? В конце концов, ошибка контрольной суммы означает, что на диске произошло какое-то повреждение данных, которое не было обнаружено оборудованием, поэтому мы, вероятно, захотим изменить этот диск до того, как возникнет какая-либо ошибка (даже если зеркальный диск может по-прежнему выступать в роли «резервной копии»). Так что я, возможно, еще не понял, что именно они подразумевают под «неисправимым».

Неисправные диски уже обозначены ошибками чтения / записи (например, URE с диска). Ошибки контрольной суммы - это то, что вы описываете: блок был прочитан, его возвращаемое значение не было признано правильным по контрольным суммам блоков над ним в дереве, поэтому вместо его возврата оно было отброшено и отмечено как ошибка. «Неисправимый» - это более или менее определение, потому что, если вы получаете мусор и знаете, что это мусор, вы не можете его исправить, но вы можете проигнорировать и не использовать его (или попробовать еще раз). Однако формулировка может быть излишне запутанной.

Согласно этому параграфу, могут быть два вида ошибок: ошибки повреждения данных и ошибки устройства. Зеркальная конфигурация двух дисков, несомненно, избыточна, поэтому (согласно этому параграфу) это не ошибка повреждения данных, если ZFS обнаруживает ошибку контрольной суммы на одном из дисков (на уровне контрольной суммы ZFS, а не на уровне оборудования).Это означает (еще раз в соответствии с этим параграфом), что эта ошибка не будет записана как часть постоянного журнала ошибок.

Повреждение данных в этом абзаце означает, что некоторые из ваших файлов частично или полностью уничтожены,нечитаемы, и вам нужно как можно скорее получить последнюю резервную копию и заменить их. Это когда все меры предосторожности ZFS уже не сработали, и он больше не может вам помочь (но, по крайней мере, он сообщает вам об этом сейчас, а не при следующем запуске контрольного диска загрузки сервера).

Для меня основной причиной перехода на ZFS была его способность самостоятельно обнаруживать тихое гниение бит, то есть обнаруживать и сообщать об ошибках на устройствах, даже если эти ошибки не привели к сбоям ввода-вывода на оборудовании / драйвере. уровень. Но не включение таких ошибок в постоянный журнал означало бы их потерю при перезагрузке, а это было бы фатальным (ИМХО).

Идея систем ZFS заключается в том, что их не нужно удалять, чтобы найти такие ошибки, потому что файловую систему можно проверить в интерактивном режиме. Помните, 10 лет назад эта функция отсутствовала в большинстве небольших систем в то время. Идея заключалась в том, что (конечно, в конфигурации с избыточностью) вы можете проверять ошибки чтения и записи оборудования и исправлять их, используя хорошо известные копии. Кроме того, вы можете каждый месяц выполнять очистку, чтобы прочитать все данные (поскольку не считанные данные нельзя считать достоверными) и исправить любую обнаруженную ошибку.

Это похоже на большой архив / библиотеку старых книг: у вас есть ценные и не очень ценные книги, некоторые могут со временем распадаться, поэтому вам нужен человек, который ходит каждую неделю или месяц и просматривает все страницы всех книг. на наличие плесени, насекомых и т. д., и если он что-нибудь найдет, он вам расскажет. Если у вас есть две идентичные библиотеки, он может перейти в другое здание, посмотреть ту же книгу на той же странице и заменить уничтоженную страницу в первой библиотеке копией.Если он никогда не заглянет ни в какую книгу, 20 лет спустя его может ждать неприятный сюрприз.

6
27.01.2020, 20:28

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

Первый вопрос: что означает «устройство»?

Это было разъяснено пользователем121391; Ничего значимого добавить не смог.

Второй и третий вопрос: что такое неисправимые ошибки / почему в счетчиках ошибок отображаются только неисправимые ошибки?

Формулировка, выбранная Sun / Oracle, очень неясна и вводит в заблуждение.Обычно, когда диск (или любой аппаратный компонент в иерархии) обнаруживает ошибку целостности данных, могут произойти две вещи:

  • Ошибка может быть исправлена ​​(такими механизмами, как ECC и т. Д.), И соответствующий компонент передает данные после того, как они были исправлены (тем самым, возможно, увеличив некоторый счетчик ошибок, который администратор может считать с помощью соответствующих инструментов).

  • Ошибка не может быть исправлена ​​. В этом случае обычно возникает ошибка ввода-вывода, чтобы сообщить оборудованию / драйверу / приложениям, что возникла проблема.

Теперь в редких случаях ошибка ввода-вывода не возникает , даже если была ошибкой целостности данных, которая не была исправлена. Это может быть связано с ошибками в программном обеспечении, отказом оборудования и т. Д. Это то, что я лично имею в виду под «тихой битовой гнилью», и именно для этой цели я перешел на ZFS: такие ошибки обнаруживаются с помощью собственной «сквозной» контрольной суммы ZFS.

Итак, ошибка контрольной суммы ZFS - это именно ошибка данных (целостности) на аппаратном уровне, которая не привела к ошибке ввода-вывода (как должно быть) , и, следовательно, не обнаруживается никаким механизмом, кроме собственной контрольной суммы ZFS, и наоборот. В этом смысле количество ошибок в столбце CKSUM команды zpool status -v - это количество ошибок контрольной суммы ZFS, а также необнаруженных аппаратных ошибок, поскольку эти два числа просто идентичны. .

Другими словами, если бы устройство самостоятельно исправило ошибку целостности или (если ошибка была неисправимой) установило ошибку ввода-вывода, ZFS не увеличила бы свою ошибку CKSUM. прилавок.

Я был сильно обеспокоен этим разделом документации Sun, поскольку термин «неисправимые ошибки» никогда не объясняется и как таковой вводит в заблуждение. Если бы вместо этого они написали «неисправимые аппаратные ошибки, которые не приводили к ошибкам ввода-вывода , как обычно », у меня не было бы никаких проблем с этой частью документации.

Итак, подведем итоги и еще раз подчеркнем: «некорректируемый» в этом контексте означает «не исправляемый и необнаруженный на аппаратном уровне» (необнаруженный в том смысле, что ошибка ввода-вывода не произошла, несмотря на ошибку данных (целостности)), не "неисправимый на уровне ZFS" (на самом деле, насколько мне известно, ZFS не пытается исправить неверные данные на отдельных дисках с помощью механизма исправления ошибок контрольной суммы, но он распознает ошибочные данные с помощью контрольных сумм, а затем пытается исправить данные, если есть правильные копии данных на других дисках (зеркало) или если данные могут быть восстановлены из данных на других дисках (RAIDZ)).

Последний вопрос (относительно постоянного журнала)

Еще раз, документация Sun здесь просто неверна (или, по крайней мере, вводит в заблуждение, что никто не поймет, что на самом деле происходит, прочитав ее):

Очевидно, по крайней мере два постоянных журнала.

Один из них, о котором говорится в документации, - это журнал, в котором подробно указывается, какой файл не удалось прочитать из-за ошибки ввода-вывода приложения, то есть ошибки ввода-вывода или ошибки контрольной суммы ZFS, которые не могли быть исправлены даже с помощью механизмы резервирования ZFS. Другими словами, если ошибка ввода-вывода происходит на уровне диска, но ZFS может исправить эту ошибку с помощью своих механизмов резервирования (RAIDZ, зеркало), ошибка не записывается в этот постоянный журнал.

ИМХО, в этом есть смысл. С помощью этого журнала администратор сразу понимает, какие файлы следует восстановить из резервной копии.

Но есть второй постоянный «журнал», который не упоминается в документации: «Журнал» для счетчиков ошибок. Конечно, счетчики ошибок сохраняются между перезагрузками,были ли обнаружены ошибки во время чистки или во время нормальной работы. В противном случае ZFS не имела бы никакого смысла:

Представьте, что у вас есть сценарий, который запускает zpool status -v один раз в день в 23:00 и отправляет вам результаты по электронной почте, а вы проверяете эти электронные письма каждое утро, чтобы посмотрим, все ли в порядке. Однажды, в полдень, ZFS обнаруживает ошибку на одном из своих дисков, увеличивает счетчики ошибок ввода-вывода или CKSUM для соответствующего устройства, исправляет ошибку (например, потому что на зеркальном диске есть правильные данные) и передает данные. В этом случае нет ошибки ввода-вывода приложения ; следовательно, ошибка , а не будет записана в постоянный журнал ошибок, о котором говорится в документации.

В этот момент счетчики ошибок ввода-вывода или CKSUM являются единственным намеком на то, что возникла проблема с соответствующим диском. Затем, через два часа, вам по какой-то причине необходимо перезагрузить сервер. Давление времени велико, производство должно продолжаться, и, конечно же, вы не будете запускать zpool status -v вручную в этой ситуации перед перезагрузкой (возможно, вы все равно не сможете войти в систему). Теперь, если бы ZFS не записала счетчики ошибок в отдельный «журнал», вы потеряете информацию о том, что на одном из дисков произошла ошибка. Скрипт, проверяющий статус ZFS, запустится в 23:00, а на следующее утро, изучив соответствующее письмо, вы будете рады убедиться, что проблем не возникло ...

По этой причине счетчики ошибок хранятся где-то постоянно (мы могли бы обсудить, следует ли называть это «журналом», но ключевым моментом является то, что они хранятся постоянно, так что zpool status -v после перезагрузки показывает те же результаты, что и непосредственно перед перезагрузкой). Фактически, AFAIK, zpool clear - единственный способ сбросить счетчики ошибок.

Я думаю, что Sun / Oracle не делает себе одолжение при написании такой непонятной документации. Я опытный пользователь (по сути, разработчик) и привык читать плохую документацию. Но документация Sun действительно катастрофична. Чего они ждут? Должен ли я действительно заставить один из моих дисков вызвать ошибку ввода-вывода, а затем перезагрузить сервер, чтобы проверить, сохранились ли счетчики ошибок? Или мне следует прочитать исходный код, чтобы ответить на такие основные и важные вопросы?

Если бы мне пришлось принимать решение за или против ZFS / Solaris, я бы прочитал документацию, а затем принял решение. В этом случае я бы явно отказался, поскольку из документов у меня могло бы сложиться впечатление, что счетчики ошибок не сохраняются при перезагрузке, и это, конечно, было бы совершенно неприемлемо.

К счастью, я попробовал ZFS после прочтения некоторых других статей об этом и до чтения документации Sun. Как плохая документация, настолько хорош продукт (ИМХО).

3
27.01.2020, 20:28

Теги

Похожие вопросы