При запуске кластера Hadoop, который использует HDFS (так что данные уже реплицируются 3 раза), мы часто сталкиваемся с проблемами с ext4, потому что некоторые поврежденные секторы (файловая система не может читать или писать в них) заставляют ext4 перемонтировать файловую систему в режиме только для чтения.
Пока все хорошо, и мы работаем над заменой дисков, но я наткнулся на btrfs и дублирование метаданных, и мне интересно, как btrfs реагирует в такой ситуации?
Ошибки данных для нас не имеют значения, поскольку данные уже подсчитаны и реплицированы HDFS, но более надежная обработка метаданных (например, если метаданные не могут быть записаны в одном месте, используются дублированные метаданные), будет преимуществом, потому что теоретически перемонтирование только для чтения и требуемый fsck не должны происходить так часто, если мы переключимся на btrfs ...
Итак, есть ли здесь кто-нибудь, кто запускает btrfs без рейда на desktop-hdds, и может ли мне сказать, насколько устойчива файловая система против средних ошибок?
Например. используется ли дублирование метаданных на одном диске для восстановления поврежденных метаданных или файловая система все равно выходит из строя?
Я определенно Нет эксперта и у меня очень мало опыта работы с файловой системой в целом. Итак, возьмите то, что я пишу с щепоткой (или горсткой соли) :)
Теперь отказ от ответственности: Btrfs (насколько мне известно) еще не является отказоустойчивым и требует серьезной работы в этом отделе. Если моя память работает правильно, ZFS должна лучше соответствовать вашим требованиям. Я сам рассматривал btrfs, но пока не очень хочу его использовать. Между прочим, opensuse (я думаю) обеспечивает его поддержку, так что, возможно, вы найдете там некоторую информацию.
Пожалуйста, обновите, если вы найдете решение в другом месте.
Надеюсь, я немного помог.
http://en.wikipedia.org/wiki/ZFS
Для ZFS целостность данных достигается за счет использования контрольной суммы (на основе Флетчера) или хэша (SHA-256) во всем дереве файловой системы. [17] Каждый блок данных суммируется, и значение контрольной суммы затем сохраняется в указателе на этот блок, а не в самом блоке. Затем указатель блока вычисляется по контрольной сумме, и значение сохраняется в его указателе. Это контрольное суммирование продолжается на всем пути вверх по иерархии данных файловой системы до корневого узла, который также вычисляется контрольной суммой, создавая таким образом дерево Меркла. [17] Повреждение данных в полете или фантомное чтение / запись (контрольные суммы записанных / прочитанных данных верны, но на самом деле неверны) не обнаруживаются большинством файловых систем, поскольку они хранят контрольную сумму вместе с данными. ZFS хранит контрольную сумму каждого блока в указателе родительского блока, чтобы весь пул прошел самопроверку. [18]
Когда осуществляется доступ к блоку, независимо от того, является ли он данными или метаданными, его контрольная сумма вычисляется и сравнивается с сохраненным значением контрольной суммы того, чем он «должен» быть. Если контрольные суммы совпадают, данные передаются по стеку программирования процессу, который их запросил. Если значения не совпадают, ZFS может восстановить данные, если пул хранения имеет избыточность через зеркалирование ZFS или RAID. [19] Если пул хранения состоит из одного диска, такую избыточность можно обеспечить, указав "copy = 2" (или "copy = 3"), что означает, что данные будут храниться на диске дважды (трижды), что фактически уменьшит вдвое (или, для "copy = 3", уменьшая до одной трети) емкость диска. [20] Если существует избыточность, ZFS получит копию данных (или воссоздает ее с помощью механизма восстановления RAID) и пересчитает контрольную сумму, что в идеале приведет к воспроизведению изначально ожидаемого значения. Если данные проходят эту проверку целостности, система может обновить неисправную копию заведомо исправными данными, чтобы можно было восстановить избыточность.