Помощь, необходимая для понимания сообщения об ошибках ZFS (в Linux)

Я успешно настроил Debian на ZFS, включая корневую файловую систему. Все работает так, как ожидалось, и я думал, что понял основные понятия – пока не перечитаю документацию Sun ZFS.

Мой сценарий:

  • Как я могу переместить пул ZFS в дочерний пул?
  • Как установить файловую систему zfs на другую файловую систему zfs в ubuntu 16.04
  • Может ли BTRFS использовать массивы RAID RAID?
  • Установите FreeBSD с usb на usb (Root on ZFS)
  • Загадочные ошибки разрешения Samba после миграции службы
  • Каковы потенциальные последствия перехода орехов с разреженными файловыми vdev для миграции LVM на ZFS?
    • Я хотел бы предотвратить (точнее: обнаружить) бесшумную битвую гниль

    • На данный момент я создал корневой пул с одним vdev, который является зеркалом двух одинаковых дисков

    • Конечно, я включил (т. Е. Не выключил) контрольные суммы

    Теперь я столкнулся с этим документом . В конце страницы они показывают вывод команды состояния zpool status для их примерной конфигурации,

     [...] NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 OFFLINE 0 0 0 48K resilvered [...] 

    за которым следует заявление:

    Столбцы READ и WRITE предоставляют количество ошибок ввода-вывода, которые произошли на устройстве, а столбец CKSUM содержит счет нескорректируемых ошибок контрольной суммы, которые произошли на устройстве.

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

    Во-вторых, что они подразумевают под неуправляемыми ошибками контрольной суммы? Это термин, который, как я думал, обычно используется при разговоре о физических дисках, относящихся к передаче данных с диска в электронику диска, в контрольные суммы физических секторов на диске или передачу данных с порта диска (SATA, SAS, …) на системную плату (или контроллер).

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

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

    Затем я столкнулся с этим документом, который еще сложнее понять. В конце страницы указано состояние

    […] ZFS поддерживает постоянный журнал всех ошибок данных, связанных с пулом. […]

    а затем состояния

    Ошибки повреждения данных всегда фатальны. Их присутствие указывает на то, что по крайней мере одно приложение испытало ошибку ввода-вывода из-за поврежденных данных в пуле. Ошибки устройства в избыточном пуле не приводят к повреждению данных и не записываются как часть этого журнала. […]

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

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

    Поэтому, в конце концов, Sun выбрала тревожную формулировку здесь, или я неправильно понял некоторые понятия (не являясь носителем английского языка). Может ли кто-нибудь помочь мне здесь?

  • Контейнер Docker на VM не записывается в набор данных ZFS
  • AES-NI ускорил шифрование ZFS v31 в Solaris 11
  • коэффициент дедупликации zfs «низкий»
  • ZFS Отправить в Pigz, netcat
  • Принудительное использование zpool / dev / disk / by-id в Ubuntu Xenial
  • ZFS перепутали зеркала вверх
  • 2 Solutions collect form web for “Помощь, необходимая для понимания сообщения об ошибках ZFS (в Linux)”

    Общий обзор см. В разделе « Решение проблем с ZFS» , наиболее интересная часть:

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

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

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


    Теперь, для ваших вопросов:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Это было выяснено пользователем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 часа дня и отправляет вам сообщения, и вы проверяете эти письма каждое утро, чтобы узнать, все ли хорошо. Однажды, в полдень, ZFS обнаруживает ошибку на одном из своих дисков, увеличивает счетчики ошибок ввода-вывода или CKSUM для соответствующего устройства, исправляет ошибку (например, потому что зеркальный диск имеет правильные данные) и передает данные. В этом случае ошибка ввода-вывода приложения отсутствует; следовательно, ошибка не будет записана в журнал постоянных ошибок, о котором говорит документация.

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

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

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

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

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

    Linux и Unix - лучшая ОС в мире.