Недавно я изучил расширенные файловые системы (Btrfs, ZFS) для обеспечения избыточности и доступности данных и заинтересовался дополнительными функциональными возможностями, которые они предоставляют, особенно их возможностями «самовосстановления» против повреждения данных.
Тем не менее, я думаю, что мне нужно сделать шаг назад и попытаться понять, перевешивает ли это преимущество их недостатки (ошибки Btrfs и нерешенные проблемы, а также доступность и влияние ZFS на производительность) для общего домашнего / SMB-использования по сравнению с обычным mdadm-Raid1 + Решение Ext4. В любом случае доступна зеркальная резервная копия.
Предположим, у меня есть пара файловых серверов, которые используются для архивных целей и имеют ограниченные ресурсы, но память ECC и стабильный источник питания.
Да, функциональная файловая система с контрольной суммой - это очень хорошо. Однако настоящая мотивация заключается не в мифическом "битроте", который, хотя делает бывает, очень редко. Скорее, главное преимущество заключается в том, что такая файловая система предоставляет и контрольная сумма сквозных данных, активно защищая вас от ошибочного поведения диска, такого как неправильная запись и повреждение данных, связанное с отказом и / или некорректным поведением собственного частного кэша DRAM диска из-за проблем с питанием.
Я испытал эту проблему на собственном опыте, когда массив Linux RAID 1 вышел из строя из-за проблемы с источником питания. Кэш одного диска начал искажать данные, а ECC, встроенный в сами сектора диска, ничего не улавливал просто потому, что записанные данные были уже испорчены и ECC был рассчитан на самих поврежденных данных.
Благодаря журналу контрольных сумм, который обнаружил что-то странное и приостановил работу файловой системы, XFS ограничил ущерб; однако некоторые файлы / каталоги были безвозвратно повреждены. Поскольку это была машина для резервного копирования, которая не испытывала немедленных простоев, я восстановил ее с помощью ZFS. Когда проблема возникла снова, во время первой очистки ZFS исправила затронутый блок, прочитав хорошие копии с других дисков. Результат: без потери данных и простоев. Это две очень веские причины использовать файловую систему с контрольными суммами.
Стоит отметить, что контрольная сумма данных настолько ценна, что целевой объект сопоставления устройств для ее предоставления (путем эмуляции спецификаций T-10 DIF / DIX) называется дм-целостность, был разработан как раз для распространения этой защиты на классические блочные устройства (особенно с резервированием как RAID1 / 5/6). В силу Стратис проект, он будет интегрирован в универсальный интерфейс командной строки / API для управления.
Однако вы понимаете, что любое потенциальное преимущество такой файловой системы следует сравнивать с унаследованным от нее недостатком. Основная проблема ZFS в том, что она не включена в стандартное ядро, но в остальном она очень быстрая и стабильная. С другой стороны, BTRFS, будучи основной, имеет много важных вопросов и проблемы с производительностью (обычное предложение для баз данных или виртуальных машин - отключить CoW, который, в свою очередь, отключил контрольную сумму, что, честно говоря, неприемлемо). Вместо того, чтобы использовать BTRFS, я бы использовал XFS и надеялся на лучшее или использовал устройства, защищенные dm-целостностью.
У меня был жесткий диск Seagate, на котором контрольные суммы начинались с ошибкой каждый раз, когда я запускал zfs scrub. Через несколько недель это не удалось. ZFS и Btrfs имеют контрольные суммы для данных и метаданных. ext4 имеет только контрольные суммы метаданных.
Только ошибки CRC и ошибки контрольной суммы метаданных. Может произойти повреждение данных.
Если в нем есть битые сектора, это не проблема. Весь диск будет "неисправным", но у вас есть другой диск "в порядке". Проблема в том, что данные имеют правильный CRC, но данные повреждены. Это может произойти случайно из-за больших дисков.
Я использую ZFS в производстве, как для серверов, так и для NAS домашнего офиса, как под Linux, так и под FreeBSD, более 6 лет. Я нашел его стабильным, быстрым, надежным и лично видел, как он обнаруживает и (когда может) исправлять ошибки, которые md устройство или ext4 файловая система не смогла бы.
Однако я думаю, мне нужно сделать шаг назад и попытаться понять, перевешивает ли это преимущество их недостатки (ошибки и нерешенные проблемы Btrfs, а также доступность ZFS и влияние на производительность).
Что касается лицензирования, ZFS является открытым исходным кодом, она выпущена только под лицензией CDDL, которая не является законно совместим с лицензией GPLv2, под которой выпущено ядро Linux. Подробности здесь. Это не означает, что он находится в состоянии «на какое-то время в подвешенном состоянии», и не означает, что технический несовместимость. Это просто означает, что в исходном коде ядра Linux нет модулей, и их нужно получить откуда-то вроде https://zfsonlinux.org . Обратите внимание, что некоторые дистрибутивы, такие как debian, включают ZFS в свой дистрибутив. Установка ZFS в Debian / Ubuntu обычно выполняется с помощью одного apt команда.
Что касается производительности, при достаточной оперативной памяти производительность ZFS для меня находится в диапазоне от близкого к ext4 до превосходящего ext4, в зависимости от памяти, доступного места в пуле и сжимаемости данных. На мой взгляд, самым большим недостатком ZFS является использование памяти: если у вас меньше 16 ГиБ ОЗУ для производственного сервера, вы можете отказаться от ZFS. Это слишком упрощенное практическое правило; в Интернете много информации о требованиях к памяти для ZFS. Я лично использую пул 10 ТБ и пул 800 ГБ вместе с некоторыми пулами резервного копирования на Linux-системе домашнего офиса с 32 ГБ оперативной памяти и отличной производительностью. Этот сервер также работает LXC и работает несколько служб.
Функции ZFS выходят далеко за рамки возможностей подсчета контрольных сумм и самовосстановления; его мощные снимки намного лучше, чем снимки LVM, а встроенное сжатие lz4 действительно может повысить производительность за счет уменьшения количества операций записи на диск. Лично я добился 1,55-кратной экономии на пуле 10 ТБ (хранение 9,76 ГБ данных только на 6,3 ГБ пространства на диске)
По моему опыту, производительность ZPF достигается, когда пул достигает 75% или 80% использования, поэтому, пока вы остаетесь ниже этой точки, производительности должно быть более чем достаточно для общего использования дома / SMB.
В тех случаях, когда я видел, как ZFS обнаруживает и исправляет неверные данные, основная причина была неясной, но, скорее всего, это был плохой дисковый блок. У меня также есть память EEC и ИБП, поэтому я не верю, что данные в ОЗУ были повреждены. Фактически, вам понадобится оперативная память EEC, чтобы использовать контрольные суммы ZFS. Однако я видел несколько (~ 10-15) случаев блоков, которые не соответствовали контрольной сумме за последние 6 лет. Одним из основных преимуществ ZFS над md RAID является то, что ZFS знает, на какие файлы влияет ошибка контрольной суммы.. Поэтому в тех случаях, когда пул резервных копий без избыточности имел ошибку контрольной суммы, ZFS сообщила мне, что точный файлы, которые были затронуты, что позволяет мне заменить эти файлы.
Несмотря на то, что используемая ZFS лицензия не сопоставима с ядром Linux, установка модулей очень проста (по крайней мере, в Debian), а после знакомства с набором инструментов управление становится простым. Несмотря на то, что многие люди ссылаются на опасения полной потери данных с ZFS в Интернете, у меня никогда потерял какие-либо данные с момента перехода на ZFS, а сочетание снимков ZFS и контрольных сумм / избыточности данных лично спасало меня от потери данных несколько раз. Это явная победа, и я лично никогда не вернусь к md массив.
Насколько вероятно, что я вообще столкнусь с фактическим повреждением данных, делающим файлы нечитаемыми? Как?
Если будет достаточно времени, это почти наверняка произойдет. По совпадению, это случилось со мной на прошлой неделе. На моем домашнем файловом сервере образовалась плохая оперативная память, из-за которой периодически возникали зависания. В конце концов я решил просто списать машину (которая уже довольно устарела) и переместил диски в корпус на другой машине. Скраб после импорта обнаружил и исправил 15 блоков с ошибками контрольной суммы из пула 8 ТБ, которые предположительно были вызваны плохой оперативной памятью и / или зависаниями. Сами диски были подтверждены SMART и прошли проверку при последующей очистке.
Может ли Ext4 или системный файловый менеджер уже обнаруживать ошибки данных при копировании / перемещении, что позволяет мне хотя бы знать о проблеме?
Нет, не совсем. В некоторых форматах файлов могут быть контрольные суммы на уровне приложения, но в остальном ничто не отслеживает тип коррупции, который произошел в моем случае.
Что произойдет, если на одном из дисков madam-Raid1 будут храниться разные данные из-за того, что на одном диске есть битые сектора? Смогу ли я получить нужный файл или массив не сможет решить, какой файл правильный, и полностью его потеряет?
Если вы точно знаете, что один диск неисправен, вы можете вывести этот диск из массива и обработать все операции чтения с хорошего диска (или, что более разумно, заменить неисправный диск, который скопирует данные с хорошего диска на заменяющий). ). Но если данные на дисках различаются из-за случайного переворота битов при записи (что случилось со мной и shodanshok), нет однозначного способа выбрать, какой из двух является правильным без контрольной суммы.
Кроме того, md обычно не уведомление что два диска в зеркале не синхронизированы во время нормальной работы - он будет направлять чтение на один диск или другой любым способом, который даст самый быстрый результат. Существует функция «проверки», которая считывает обе стороны зеркальной пары и сообщает о несоответствиях, но только в том случае, если вы ее запускаете или если ваш дистрибутив настроен на периодический запуск и отчет о результатах.
Насколько вероятно, что я вообще столкнусь с фактическим повреждением данных, делающим файлы нечитаемыми? Как?
Очевидно, что через бесконечное время вы обязательно столкнетесь с этим.
На самом деле, это все еще довольно вероятно, если у вас нет очень дорогого оборудования корпоративного уровня, и даже в этом случае это не очень маловероятно.
Однако более вероятно, что вы столкнетесь с повреждением данных, которое просто изменяет содержимое файла, но не делает его нечитаемым (если у вас нет безумного количества крошечных файлов, простая статистика означает, что у вас с большей вероятностью будет повреждение в данные файла, чем в метаданных файла). Когда это происходит, вы можете получить самые разные странные поведения, как если бы у вас было плохое оборудование (хотя обычно оно будет более согласованным и локализованным, чем плохое оборудование). Если вам повезет, некоторые некритические данные будут повреждены, и вы легко сможете их найти. Если вам в меру не повезло, вам придется перестраивать систему с нуля. Если ты действительно не повезло, вы только что столкнулись с ошибкой, которая привела к банкротству, потому что это случилось с критическими данными в производственной системе, и ваша служба теперь не работает, пока вы восстанавливаете все это с нуля и пытаетесь вернуть базу данных в нужное состояние быть.
Короткий ответ: повреждение данных достаточно вероятно, что даже домашние пользователи должны беспокоиться об этом.
Может ли Ext4 или системный файловый менеджер уже обнаруживать ошибки данных при копировании / перемещении, что позволяет мне хотя бы знать о проблеме?
Ext4, как известно, плох в этом вопросе. Их поведение по умолчанию при возникновении ошибки внутренней согласованности заключается в том, чтобы пометить файловую систему для проверки при следующем повторном подключении, а затем продолжить работу, как будто все в порядке. В прошлом я терял целые системы из-за такого поведения.
В более общем смысле, в большинстве случаев лучшее, на что вы можете надеяться от файловой системы, специально не предназначенной для проверки ее данных, - это перемонтировать только для чтения, если она сталкивается с внутренней ошибкой с ее собственными структурами данных или метаданными файла. Дело в том, что если файловая система специально не обрабатывает проверку своих внутренних структур, помимо простых вещей, таких как проверка границ, это не улавливает все, что-то может пойти не так, как надо.
Чтобы получить что-то еще, вам нужна файловая система для проверки ее собственных внутренних структур данных с помощью контрольных сумм, кодов исправления ошибок, кодирования стирания или другого подобного подхода. Даже в этом случае, если это не относится к файловым данным, вы по-прежнему подвергаетесь незначительному риску потери данных.
Что произойдет, если на одном из дисков madam-Raid1 будут храниться разные данные из-за того, что на одном диске есть битые сектора? Смогу ли я получить нужный файл или массив не сможет решить, какой файл правильный, и полностью его потеряет?
Это зависит от уровня RAID, точной реализации RAID и от того, настроен ли он на автоматическое восстановление. Предполагая, что у вас включено автоматическое восстановление:
Для RAID1 и RAID10:
Для RAID4 / 5/6 и других случаев кодирования со стиранием почти все ведет себя одинаково, когда дело доходит до восстановления: либо данные восстанавливаются с оставшихся устройств, если это возможно, либо массив фактически теряется. ZFS и BTRFS в этом случае просто дают вам более быстрый (с точки зрения общего количества операций ввода-вывода) способ проверить правильность данных или нет.
Обратите внимание, что ни один из них не работает для каждого файла, и большинство из них не позволяет вам легко выбрать «правильный», они либо работают полностью, либо полностью выходят из строя, либо поочередно возвращают хорошие или плохие данные для несинхронизированной области.
Для полноты картины отмечу https://bcachefs.org, которого, по общему признанию, еще нет в ядре, но IMHO планируется заменить ZFS и btrfs, как только это произойдет.
Он основан на bcache, который уже давно присутствует в ядре, создавая функции файловой системы с помощью своей системы B-tree.
Разработчик-одиночка работает над этим постоянно, спонсируется через Patreon и уделяет большое внимание надежности.
На данный момент не для слабонервных, но по мере того, как этот комментарий стареет, bcachefs должен улучшиться :)
Могу добавить, что ZFS безумно надежен, в основном благодаря своему происхождению (он был разработан Sun Microsystems еще в 2001 году). Доступная в настоящее время версия с открытым исходным кодом является форком одной из последних версий с открытым исходным кодом, выпущенных Sun Microsystems около 10 лет назад, которая получила дальнейшее развитие в сообществе открытого исходного кода после того, как Oracle закрыла исходный код ZFS после приобретения Sun Microsystems.
Сами Oracle по-прежнему поддерживает версию ZFS с закрытым исходным кодом, которая используется в их корпоративных системах хранения.
Однако у ZFS есть некоторая кривая обучения, поскольку она довольно мощная, есть довольно много вещей, которые можно настроить. Кроме того, это одна из немногих файловых систем хранения, над которыми я работал, обслуживание которой действительно легко. У меня был один случай, когда пул нужно было перенести с настройки RAID5 на RAID6 (или, точнее, с RAID-Z1 на RAID-Z2). Обычно такая операция означает копирование всех данных, перенастройку RAID и копирование данных обратно. В ZFS вы подключаете вторичное хранилище и копируете пул с помощью одной команды, перенастраивайте массив по своему усмотрению. и скопируйте пул обратно с помощью другой команды.
Однако есть некоторые подводные камни:
Для новичков и в домашних условиях я обычно рекомендую FreeNAS, он очень ухоженный и простой в настройке, что хорошо для новичков.