Насколько я понимаю, на жестких дисках и твердотельных накопителях реализовано базовое исправление ошибок внутри накопителя, и большинство конфигураций RAID, например, mdadm, будут зависеть от этого, чтобы решить, когда накопителю не удалось исправить ошибку и его необходимо отключить. Однако это зависит от точности хранения на 100% в диагностике ошибок. Это не так, и обычная конфигурация, такая как зеркало RAID-1 для двух дисков, будет уязвимой: предположим, что некоторые биты на одном диске незаметно повреждены, и диск не сообщает об ошибке чтения. Таким образом, файловые системы, такие как btrfs и ZFS, реализуют свои собственные контрольные суммы, чтобы не доверять ошибочным прошивкам дисков, сбойным кабелям SATA и так далее.
Точно так же, у RAM также могут быть проблемы с надежностью, и поэтому у нас есть ECC RAM, чтобы решить эту проблему.
Мой вопрос заключается в следующем : каков канонический способ защиты файла подкачки Linux от тихого повреждения / гниения, не обнаруживаемого микропрограммой диска в конфигурации с двумя дисками (то есть с использованием драйверов ядра mainline)? Мне кажется, что конфигурация, в которой отсутствует сквозная защита (например, предоставляемая btrfs), несколько отрицает душевное спокойствие, обеспечиваемое ECC RAM. И все же я не могу придумать хороший способ:
- btrfs вообще не поддерживает файлы подкачки. Вы можете настроить петлевое устройство из файла btrfs и произвести обмен на него. Но это имеет проблемы:
- Случайные записи не работают хорошо: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
- Предложение там отключить копирование при записи также отключит контрольную сумму - таким образом победив весь смысл этого упражнения. Они предполагают, что файл данных имеет свои внутренние средства защиты.
- ZFS в Linux позволяет использовать ZVOL в качестве подкачки, что, я думаю, могло бы сработать: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - однако, исходя из моего чтения, ZFS обычно требует памяти и заставляет его работать в режиме подкачки. -только приложение звучит как какая-то работа, выясняя это. Я думаю, что это не мой первый выбор. Почему вы должны использовать какой-то модуль ядра, не имеющий отношения к дереву, просто чтобы надежный обмен не был мне понятен - наверняка есть способ сделать это с большинством современных дистрибутивов / ядер Linux в наше время?
- На самом деле в списке рассылки ядра Linux была ветка с патчами для включения контрольных сумм в самом менеджере памяти, по причинам, которые я обсуждаю в этом вопросе: http://thread.gmane.org/gmane.linux.kernel/989246 - к сожалению, насколько я могу судить, патч умер и не вышел в апстрим по неизвестным мне причинам. Жаль, это звучало как приятная особенность. С другой стороны, если вы установите своп на RAID-1 - если повреждение не поддается восстановлению контрольной суммы, вы бы хотели, чтобы диспетчер памяти попытался прочитать данные с другого диска до паники или чего-то еще, что вероятно, выходит за рамки того, что должен делать менеджер памяти.
В итоге:
- RAM имеет ECC для исправления ошибок
- Файлы на постоянном хранилище имеют btrfs для исправления ошибок
- Своп имеет ??? <--- это мой вопрос
источник
Ответы:
Мы доверяем целостности данных, извлеченных из подкачки, потому что оборудование для хранения имеет контрольные суммы, CRC и тому подобное.
В одном из комментариев выше вы говорите:
«Это» означает контрольные суммы диска здесь.
Это правда, но SATA использует 32-битные CRC для команд и данных. Таким образом, у вас есть 1 из 4 миллиардов шансов незаметно повредить данные между диском и контроллером SATA. Это означает, что источник непрерывной ошибки может вносить ошибку так же часто, как каждые 125 МБ, но редкий случайный источник ошибок, такой как космические лучи, может вызывать необнаружимые ошибки с исчезающе малой частотой.
Поймите также, что если у вас есть источник, который вызывает необнаруженную ошибку со скоростью около 1 на 125 МБ, производительность будет ужасной из-за большого количества обнаруженных ошибок, требующих повторной передачи. Мониторинг и ведение журнала, вероятно, вовремя предупредит вас о проблеме, чтобы избежать необнаруженного повреждения.
Что касается контрольных сумм носителя информации, то каждый диск SATA (и до него, PATA) использует контрольные суммы для каждого сектора. Одной из характерных особенностей «корпоративных» жестких дисков являются большие сектора, защищенные дополнительными функциями целостности данных , что значительно снижает вероятность необнаруженной ошибки.
Без таких мер не было бы никакого смысла в пуле резервных секторов на каждом жестком диске: сам диск не мог обнаружить неисправный сектор, поэтому он никогда не мог бы заменить свежие сектора.
В другом комментарии вы спрашиваете:
Вообще говоря, мы не просим swap для долгосрочного хранения данных. Ограничение на объем подкачки - это время безотказной работы системы , и большая часть данных подкачки длится не так долго, поскольку большая часть данных, проходящих через систему виртуальной памяти вашей системы, относится к гораздо более коротким процессам.
Кроме того, с годами время простоя, как правило, сокращается, что связано с увеличением частоты ядра и
libcобновлений, виртуализацией, облачной архитектурой и т. Д.Кроме того, большая часть данных в разделе подкачки по своей сути не используется в хорошо управляемой системе, поскольку она не исчерпывает себя из основной оперативной памяти. В такой системе единственными вещами, которые заканчиваются в swap, являются страницы, которые программа не использует часто, если вообще когда-либо. Это чаще, чем вы можете догадаться. Большинство динамических библиотек, на которые ссылаются ваши программы, содержат подпрограммы, которые ваша программа не использует, но они должны были загружаться в ОЗУ динамическим компоновщиком . Когда операционная система видит , что вы не используете весь текст программы в библиотеке, она меняет его, освобождая место для кода и данных , что ваши программы будут использовать. Если такие выгруженные страницы памяти будут повреждены, кто когда-нибудь узнает?
Сравните это с ZFS, где мы ожидаем, что данные будут надежно и постоянно храниться, так что они будут работать не только в течение текущего времени безотказной работы системы, но и в течение срока службы отдельных устройств хранения, составляющих систему хранения. ZFS и подобные решения решают проблему с масштабом времени примерно на два порядка дольше, чем проблема, решаемая свопом. Поэтому у нас гораздо выше требования к обнаружению коррупции для ZFS, чем для Linux подкачки.
ZFS и тому подобное отличаются от swap в другом ключевом аспекте: мы не объединяем файловые системы RAID вместе. Когда на одном компьютере используется несколько устройств подкачки , это схема JBOD , а не RAID-0 или выше. (например, схема сцепленных файлов подкачки в MacOS , Linux и
swaponт. д.) Поскольку устройства подкачки являются независимыми, а не взаимозависимыми, как с RAID, нам не требуется обширное контрольное суммирование, поскольку замена устройства подкачки не подразумевает поиск других взаимозависимых устройств подкачки для данные, которые должны идти на замену устройства. С точки зрения ZFS, мы не переносим сменные устройства с избыточных копий на другие устройства хранения.Все это означает, что вы должны использовать надежное устройство подкачки. Однажды я использовал внешний USB-накопитель на жестких дисках за 20 долларов для спасения больного пула ZFS, но обнаружил, что корпус сам по себе ненадежен, внося собственные ошибки в процесс. Сильная контрольная сумма ZFS спасла меня здесь. Вы не можете избежать такой кавалерной обработки носителей с файлом подкачки. Если устройство подкачки умирает и, таким образом, приближается к тому наихудшему случаю, когда оно может выдать необнаружимую ошибку при каждой передаче 125 МБ, вам просто нужно заменить ее как можно скорее.
Общее чувство паранойи в этом вопросе сводится к проблеме византийских генералов . Читайте об этом, подумайте о дате 1982 года в академической статье, описывающей проблему для мира информатики, а затем решите, есть ли у вас в 2019 году свежие мысли, чтобы добавить к этой проблеме. А если нет, то, возможно, вы просто будете использовать технологию, разработанную тремя десятилетиями выпускников CS, которые все знают о проблеме византийских генералов.
Это хорошо подготовленное место. Вы, вероятно, не можете придумать идею, возражение или решение, которое еще не обсуждалось до смерти в компьютерных журналах.
SATA, конечно, не совсем надежен, но если вы не собираетесь присоединиться к академическим кругам или одной из групп разработчиков ядра, вы не сможете существенно улучшить состояние дел здесь. Эти проблемы уже хорошо решены, как вы уже отметили: ZFS, btrfs, ReFS ... Как пользователь ОС, вы просто должны верить, что создатели ОС сами позаботятся об этих проблемах, потому что они также знают, о византийских генералах.
В настоящее время нецелесообразно помещать ваш файл подкачки поверх ZFS или Btrfs, но если вышеперечисленное не убедит вас, вы можете по крайней мере поместить его поверх xfs или ext4. Это было бы лучше, чем использование выделенного раздела подкачки.
источник
дм целостности
Смотрите: Документация / Устройство-сопоставление / dm-целостность.txt
dm-integrityобычно используется в режиме журналирования. В случае обмена вы можете обойтись без журналирования. Это может значительно снизить нагрузку на производительность. Я не уверен, нужно ли переформатировать раздел подкачки-целостности при каждой загрузке, чтобы избежать перехвата ошибок после нечистого завершения работы.В первоначальном объявлении
dm-integrityавтор заявляет о предпочтении «защиты целостности данных на более высоком уровне». В случае подкачки это откроет возможность хранения контрольных сумм в оперативной памяти. Однако этот вариант потребует как нетривиальных изменений текущего кода подкачки, так и увеличения использования памяти. (Текущий код отслеживает обмен эффективно с использованием экстентов, а не отдельных страниц / секторов).DIF / DIX?
Поддержка DIX была добавлена Oracle в Linux 2.6.27 (2008).
Обеспечивает ли использование DIX сквозную целостность?
Вы можете проконсультироваться со своим продавцом. Я не знаю, как вы могли бы сказать, если они лгут об этом.
DIX требуется для защиты данных во время полета между ОС (операционной системой) и HBA .
DIF сам по себе повышает защиту данных во время полета между HBA и устройством хранения . (См. Также: презентацию с некоторыми цифрами о разнице в показателях ошибок ).
Именно потому, что контрольная сумма в защитном поле стандартизирована, технически возможно реализовать команды DIX без какой-либо защиты данных в состоянии покоя. Просто попросите HBA (или устройство хранения) восстановить контрольную сумму во время чтения. Эта перспектива была совершенно ясна в оригинальном проекте DIX.
В одной из ранних публикаций о DIX упоминается возможность использования DIX между ОС и HBA, даже если накопитель не поддерживает DIF.
Полная лживость относительно маловероятна в «корпоративных» контекстах, где в настоящее время используется DIX; люди заметят это. Кроме того, DIF основан на существующем оборудовании, которое может быть отформатировано с 520-байтовыми секторами. Протокол для использования DIF якобы требует, чтобы вы сначала переформатировали диск, см., Например,
sg_formatкоманду.Скорее всего, это реализация, которая не следует истинному сквозному принципу . В качестве одного примера упоминается поставщик, который поддерживает более слабую опцию контрольной суммы для DIX для сохранения циклов ЦП, которая затем заменяется более сильной контрольной суммой в стеке. Это полезно, но это не полная сквозная защита.
В качестве альтернативы ОС может генерировать свои собственные контрольные суммы и сохранять их в пространстве тегов приложения. Однако в текущей версии Linux это не поддерживается (v4.20) . Комментарий, написанный в 2014 году, предполагает, что это может быть связано с тем, что «очень немногие устройства хранения фактически разрешают использовать пространство тегов приложения». (Я не уверен, относится ли это к самому устройству хранения данных, к HBA или к обоим).
Какие устройства DIX доступны для работы с Linux?
Википедия говорит мне, что DIF стандартизирован в NVMe 1.2.1. Для SCSI HBA, кажется, немного сложно определить это, если у нас нет стандарта, на который можно указать. На данный момент наиболее точно можно сказать о поддержке «Linux DIX» :-). Доступны устройства:
Все оборудование, упомянутое в примечаниях к выпуску RHEL 7.5, является Fibre Channel.
Я не знаю этот рынок. Похоже, что в будущем DIX может стать более доступным на серверах. Я не знаю ни одной причины, по которой он стал бы доступен для потребительских дисков SATA - насколько я знаю, фактически не существует стандарта для формата команд. Мне будет интересно узнать, станет ли он более доступным на NVMe.
источник
Своп все еще не защищен в Linux (но см. UPD).
Ну, конечно, в Linux есть ZFS, которая может быть хранилищем подкачки, но при некоторых обстоятельствах она все еще блокируется - таким образом, эффективно отменяя эту опцию.
Btrfs по-прежнему не может обрабатывать файлы подкачки . Они упоминают о возможном использовании loopback, хотя отмечается, что он имеет низкую производительность. Существует неясное указание на то, что в Linux 5 он может быть наконец (?)…
Патчи для защиты самого обычного свопа с контрольными суммами не стали популярными.
Итак, в целом: нет. В Linux все еще есть пробел.
UPD. : Как указывает @ sourcejedi , существует такой инструмент, как dm-целостность. Ядро Linux, начиная с версии 4.12, получило цель устройства отображения, которую можно использовать для предоставления контрольных сумм любым обычным блочным устройствам, и те, которые предназначены для подкачки, не являются исключением. Инструменты не включены в основные дистрибутивы, и большинство из них не имеют никакой поддержки в подсистеме udev, но в конечном итоге это должно измениться. В паре с поставщиком резервирования, скажем, на вершине MD Software, также называемом программным RAID-массивом Linux, должна быть возможность не только обнаруживать битовую гниль, но и перенаправлять запрос ввода-вывода на исправные данные, поскольку dm-целостность будет указывать вопрос и MD должен справиться с этим.
источник
Я не думаю, что существует «канонический» путь, поэтому мое личное мнение таково.
Наблюдая за продвижением btrfs с точки зрения потенциального пользователя, я должен сказать, что он все еще как-то неясен для меня. Есть функции, которые являются зрелыми и готовыми к использованию, и есть функции, которые кажутся незрелыми и опасными для использования.
Лично у меня нет времени, чтобы решить, какую функцию использовать, а какую нет, но я не могу уделить время тому, чтобы выяснить, как отключить или включить эти функции.
В отличие от ZFS является твердым и зрелым (IMHO). Итак, чтобы ответить на ваш вопрос, я бы использовал ZFS (кстати, он не потребляет много памяти - см. Ниже).
Но для вас btrfs может быть правильным выбором, поскольку вы уже используете его (если я вас правильно понял), и в одном из приведенных выше комментариев показано, как использовать его для обмена.
По чистой случайности в последние дни я поставил несколько серверов Linux на ZFS, каждый раз включая корневую файловую систему и раздел подкачки. Прежде чем я это сделал, я провел очень тщательное исследование, которое заняло у меня несколько дней. Краткое резюме того, что я узнал:
Потребление памяти ZFS
Существует распространенное заблуждение относительно потребления памяти ZFS. ZFS в общем случае не потребляет много памяти; фактически он работает с ТБ хранилища на компьютерах с 2 ГБ ОЗУ. Только если вы используете дедупликацию (по умолчанию отключено), тогда ей требуется много и много оперативной памяти.
Обнаружение / исправление аппаратных ошибок
Являются ли SATA, PATA, RAID или другие механизмы обнаружения / исправления ошибок достаточными для целостности данных - это предмет, который вызывает бесконечные дискуссии и даже ожесточенные войны во всех местах сети. Теоретически, аппаратное запоминающее устройство должно сообщать (и, возможно, исправлять) любую ошибку, с которой оно сталкивается, и аппаратное обеспечение передачи данных на всех уровнях (чипсет, память и т. Д.) Должно также поступать.
Ну, они не во всех случаях, или они удивительно реагируют на ошибки. В качестве примера возьмем типичную конфигурацию RAID5. Обычно, если у одного диска есть проблема, он сообщает об этом RAID-массиву, который, в свою очередь, создает данные для чтения с других дисков и передает их, но также записывает их обратно на неисправный диск (который, в свою очередь, вероятно, переназначает сектор перед записью данных); если один и тот же диск сообщает о слишком большом количестве ошибок, RAID переводит его в автономный режим и информирует администратора (если он настроен правильно).
Пока все хорошо, но есть случаи, когда ошибочные данные выводятся с диска без сообщения об ошибке диска (см. Следующий раздел). Большинство RAID-массивов могут обнаружить эту ситуацию, используя информацию о четности, но их реакция глупа: вместо сообщения об ошибке и остановки передачи данных, они просто пересчитают четность на основе ошибочных данных и запишут новую четность в соответствующую диск, таким образом помечая ошибочные данные как правильные навсегда.
Это разумное поведение? Насколько я знаю, большинство аппаратных контроллеров RAID5 и даже md RAID в Linux работают именно так.
Я не знаю, как исправить ошибки btrfs, но в конечном итоге вам следует еще раз внимательно прочитать документы, особенно если вы используете RAID-массив btrfs.
Тихая гниль
Несмотря на все пламенные войны и (псевдо) научные дискуссии: реальность в основном отличается от теории, и бесшумная гниль определенно происходит, хотя теория может утверждать обратное (молчаливый гниль обычно означает, что данные на аппаратном хранилище повреждены, а устройство хранения не сообщает о ошибка при чтении этих данных, но я добавлю к этому определению переключающие биты в любом месте пути передачи).
Это не мое личное мнение: по крайней мере, Google, Amazon и CERN опубликовали подробные технические документы, посвященные именно этому вопросу. Документы доступны для бесплатного скачивания. Они проводили систематические эксперименты с несколькими миллионами жестких дисков и сотнями тысяч серверов / устройств хранения либо потому, что у них были проблемы с необнаруженным повреждением данных, либо потому, что они хотели знать, что нужно сделать, чтобы предотвратить это, прежде чем это произошло.
Таким образом, данные на их серверных фермах были повреждены со скоростью, значительно превышающей статистику MTBF или другую теорию, на которую можно рассчитывать. Под значительно выше я подразумеваю порядки величин.
Так что тихая гниль, то есть необнаруженное повреждение данных в любой точке пути передачи, является проблемой реальной жизни.
Время жизни данных
Уоррен Янг прав, когда говорит, что у своп-данных короткий срок жизни. Но я хотел бы добавить следующее соображение: в своп попадают не только данные (в смысле документов), но (возможно, даже более вероятно) части операционной системы или другого работающего программного обеспечения . Если у меня есть MP3 в обмене, я мог бы жить с переворотом. Если (из-за экстремальной ситуации) части моего производственного программного обеспечения httpd-сервера находятся в режиме подкачки, я ни в коем случае не могу жить с переворачивающимся битом, который позже приводит к выполнению испорченного кода, если его не обнаружить.
эпилог
Для меня ZFS решает эти проблемы или, точнее, перемещает их от дисков к памяти и тем самым снижает вероятность тихого гниения битов на несколько порядков. Кроме того, при правильной настройке (т. Е. Зеркала вместо RAID) он обеспечивает чистое и разумное исправление ошибок, которое работает так, как ожидается, и в конце концов может быть легко понято.
Сказав это, обратите внимание, что вы никогда не получите абсолютную безопасность. Лично я доверяю своей оперативной памяти ECC больше, чем своим дискам, и я убежден, что ZFS с ее сквозными контрольными суммами уменьшает вероятность возникновения проблем на порядки. Я бы никогда не рекомендовал использовать ZFS без ECC RAM.
Отказ от ответственности: я никоим образом не связан с каким-либо поставщиком или разработчиком ZFS. Это верно для всех вариантов (вилок) ZFS. Я просто стал поклонником этого в последние дни ...
источник