The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Для Linux доступна нативная поддержка файловой системы ZFS"
Отправлено Anon Y Mous, 02-Июн-10 20:43 
> Вообще то речь шла о том что имея расхождение в xor сумме невозможно однозначно определить блок в котором ошибка

Именно! Как, впрочем, и имея различие в содержимом разных дисков зеркала. Без дополнительной информации определить, какой диск содержит неправильные данные - невозможно.

> т.е. если блок прочитался с ошибкой рейд 5(да и 4) не сможет восстановить страйп, это если диск отказался выдать блок тогда мы знаем какого блока просто нет и его можем восстановить. это простая булева логика.

Строго говоря, в ситуации, когда один диск не вернул данные, мы можем восстановить только некоторое содержимое блока, которое будет давать в результате XOR с остальными 0 (ну или соответствовать другой половине зеркала). Но сказать, правильное это содержимое или нет - нельзя, не привлекая дополнительной информации, разумеется.

> (про 6й рейд ещё не знаю как там суммы делаются)

Там ситуация немножко получше, пока ошибок только одна. Как только их становится две, все сводится к предыдущему случаю.

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

С неявными ошибками - проявляющимися ненулевым результатом XOR содержимого всех дисков страйпа - все еще менее весело. Во-первых, очевидно, что таковая проверка может произойти только при условии, что избыточность еще имеется - если избыточности уже нет, то поздно пить боржоми. Во-вторых, что делать при ее обнаружении? Варианты:

1) считать, что содержимое дисков с данными правильно, и чинить содержимое диска с четностью; при этом, если это действительно было так, то все станет хорошо - содержимое диска с четностью станет правильным. Если неправильным было содержимое какого-либо диска с данными, то в результате действий по этому правилу, мы уничтожим правильное содержимое диска с четностью, которое позволило бы нам вычислить правильное содержимое диска с данными, знай мы о том, какой именно это диск.

2) выбирать диск, содержимое которого считать неправильным, некоторым случайным образом; очевидно, что в этом случае шансы выбрать правильный диск гораздо меньше шансов выбрать неправильный (если речь не идет о зеркале)

3) использовать в качестве критерия дополнительную информацию о дисках типа SMART; понятно, что гарантии того, что в результате будет идентифицирован диск с неправильным содержимым, тоже нет никакой

4) возвращать ошибку при попытке чтения любого из компонентов страйпа

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

Но и это еще не все. Пусть мы обнаружили рассогласование во время профилактической проверки, и даже выбрали четвертый вариант и стали возвращать ошибку при дальнейших попытках чтения. Но что если перед этим мы много раз читали компоненты этого страйпа? Это означает, что ошибка могла распространиться дальше, причем, в худшем случае, оставаясь незамеченной. Это означает, что она могла попасть в бэкапы, в другие системы, и так далее. Можно ли было это предотвратить? Конечно, можно было бы попробовать, прочитав содержимое остальных компонентов страйпа  и выполнив те же действия, что и при профилактической проверке. Но - это бы привело к существенному снижению производительности при отсутствии более-менее твердых гарантий обнаружения ошибки. Делает ли так какой-либо из традиционных аппаратных RAID контроллеров? Я не знаю, но очень сомневаюсь, что такой найдется.

Но и это еще не все. Пусть даже мы не обнаружили рассогласования и все вроде бы хорошо. Рассмотрим пример: пусть A, B, C и D означают содержимое дисков данными данными одного страйпа с первого по четвертый, а P означает содержимое диска с четностью, который будем считать пятым, то есть наш страйп в начале выглядит так: ABCDP. Предположим, мы хотим заменить содержимое второго диска на X, для этого нам придется вычислить новое содержимое для диска с четностью, назовем его Q, и выполнить две операции записи с тем, чтобы наш диск приобрел следующий вид: AXCDQ. Но что если эти операции дисками никогда не выполнятся (в силу, к примеру, одной и той же ошибки в микрокоде)? Наш страйп сохранит свой первоначальный вид, и даже будет без проблем проходить верификацию. Будет ли он при этом содержать правильные данные? Очевидно, что нет.

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

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

Естественно, одной контрольной суммы мало - нужен еще и доступ к информации об избыточности и каждому  компоненту страйпа в отдельности.

Для зеркала накладные расходы попадают в погрешность измерений, но для RAID4/5/6 накладные расходы становятся ощутимее, поскольку для проверки контрольной суммы нужно прочитать все компоненты страйпа, содержащие данные. Соответственно с точки зрения количества случайных операций чтения такой страйп будет равен самому медленному диску в страйпе, а не сумме IOPs дисков с данными.

Вот RAID-Z именно так и поступает, с той лишь дополнительной разницей, что страйпы в нем не имеют фиксированного размера - каждый логический блок файловой системы рассматривается как полный страйп. Естественно, это делает RAID-Z мало пригодным для нагрузок, где преобладают случайные операции чтения. Этот недостаток может быть нивелирован большими кэшами - либо в ОЗУ, либо на SSD (ReadZilla). Впрочем, на потоковое (в том числе - многопотоковое) чтение это не влияет, так все равно нужно будет читать все компоненты страйпа.

Ну и давно известно, что для зады банных зеркало предпочтительнее RAID5 ;-)

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру