The OpenNET Project / Index page

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



"Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS" +/
Сообщение от iZEN (ok), 25-Июн-11, 17:44 
>[оверквотинг удален]
>> предыдущее состояние,
> Малацца, основы CoW зазубрил. Садись, пять. И положи букварь на парту. Только
> у данного устройства ФС есть проблема: относительно небольшое разрушение метаданных может
> вызывать очень невкусные последствия. Знаешь что такое "эффект домино"? Ну вот
> снапшоты - они друг за другом, как костяшки домино. Грохнется что-то
> в одном? Полетит все что было за ним. Потому что зависит
> от предшествующего куска. И уж хотя-бы перестроить метаданные в случае опы,
> например порушеный индекс на основе данных целого индекса - было бы
> очень кстати, не говоря уж про исправление заведомо некорректных метаданных/проблемных
> и прочая.

Матчасть подучи: http://blogs.oracle.com/bonwick/ru/category/ZFS
---
Нисходящее восстановление: пул дисковой памяти - это дерево блоков. Чем ближе к корню дерева находится блок, тем значительнее его потеря, так как она означает потерю доступа к во всем потомкам этого блока.

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

Трудно преувеличить важность этого правила. При прямолинейном копировании всего диска, даже если успешно скопировано 99%, есть неплохой шанс, что один из верхних блоков дерева еще не скопирован. С точки зрения среднего времени восстановления после отказа (MTTR) это значит, что прогресса нет: отказ или ошибка второго диска в этот момент времени все еще будет иметь катастрофические последствия.

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

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

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

>> Если данные не восстановимы в принципе, то пул тупо останавливает свою работу,
> Да. И далее ты или выгребаешь из него хексэдитором нужные файлы или клюешь. Как мило!

Опять двадцать пять. Начинай сначала.

>> чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж
>> администратор должен сам разобраться в проблеме — fsck на такое не способна,
> Администратору приводить метаданные в консистентное и непротиворечивое состояние "немного"
> сложнее и дольше чем утилитам.

Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, чтобы это говорить? На mdraid это вообще бессмысленно.

>> и ни один из линуксовых RAID не может в этом помочь:
> А почему RAID должен помогать в починке метаданных ФС?

А почему нет, если он интегрирован с ФС?

> Если ты вдруг не знал, RAID далеко не панацея и справляется далеко не с любыми сценариями разрушений.

Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :))

> Кстати, даже лучшая конструкция парашюта очень редко но
> все-таки может не сработать. Поэтому изобрели запасные парашюты.
>> http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...
> Тебя так прикалывает демонстрировать свою тупость?

Почему свою? Это ваша тупость, данная вам в ощущениях.


Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Изучение изменения размера кодовой базы Ext4, Btrfs и XFS, opennews, 23-Июн-11, 12:28  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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