ubuntu 10.04 LTS. и? проявлялось и на более старых версиях. я считаю это принципиальная проблема md.
Понимаю ваше недоверие, но зачем же я буду выкладывать свои разработки просто так.
В качестве примера реальной необходимости ограничения скорости в других программах посмотрите как это сделано в xtrabackup
как вы объясните, что после синхронизации массива или выдергивании одного диска, так же самая команда reisefschk с теми же самыми ключами все-таки нормально ее исправляет ? причем тут журнал?
нет, только если не загрузилось. быстрый способ загрузить - выдернуть один диск. Я таких всего два случая могу припомнить с этой машиной. Еще один когда она нормально загрузилась, но потом при работе вылезли ошибки в dmesg, которые я показывал.
Гораздо чаще после перезагрузки детектирует грязную метку и нормально грузится с первого диска. Остальные в похожих конфигурациях на reiserfs просто не перегружаются внезапно.
У меня меня есть такой скрипт. Пусть называется superpuperslowbackup.
Предполагалось, что объясните откуда при внезапной перезагрузке возникает рассинхронизированность не заметная md , учитывая что специальные действия против этого драйвер md все-таки делает.
А файловая система ничего не знает о нижележащем устройстве. Последовательные запуски reiserfschk без синхронизации устройства не приводят к успеху.
причем тут телепатия? два человека написали вам - не помогает.
Ну можно же использовать не произвольный, а специальный.
В описываемой ситуации я бы посоветовал уменьшить максимальную и минимальную скорость проверки массива - sysctl dev.raid.speed_limit_max
насчет md. вот читаю ман:
Что есть md driver marks an array as "dirty" ? запись специальной метки на оба диска.
Допустим, резет произошел в тот момент, когда первый диск еще не успела записаться метка, а но на второй записались и данные и метка (хотя из-за ncq возможно записались только данные).
Драйвер md, похоже, просто посылает команды на нижний уровень, но результат и очередность не контролирует.
Хотя в мане не акцентирован этот момент, но метка не записана туда постоянно как только смонтирован raid. raid без нагрузки спокойно переживает резет без рассинхронизации или ругани. Метка dirty при этом не помечена.
Если у вас есть другое объяснение почему до синхронизации массива reisefschk завершается с ужасной ошибкой, а после синхронизации точно такая же команда работает - расскажите.
Raistlin, я имел ввиду кнопку reset. на любом компьютере такая есть. понажимайте у себя чтобы понять что именно происходи.
или же, что более вероятно, проблему вызывает какая-то железная проблема приводящая к внезапной перезагрузке.
Не понятен. Объясните подробнее зачем бы мне запускать все дисковые операции с idle. Я этого не делаю. ---------- Добавлено в 17:46 ---------- Предыдущее сообщение было в 17:43 ----------
Опять 25.
Скорее всего, ваше предложение насчет ionice лишь незначительно уменьшит негативные эффекты от бекапа. Действеннее уменьшать скорость бекапа и тем самым обеспечить нормальным операциям резерв. В этом состоит мое замечание.
Кстати, синхронизация и проверка md происходит с ограничением по скорости именно поэтому.
Можно еще забыть про шедулер дисковых операций - для ionice не нужно использовать deadline. Но даже если переключать шедулер, то у меня толку все равно мало было.
Ну вам Dimanych написал, что у него не работает. Неужели все врут специально вам ?
Разумеется, любой разумный человек будет запускать процесс для бекапа с классом idle, а остальные без ionice. Что в этом сценарии неправильно? Как заставить ionice работать?---------- Добавлено в 17:18 ---------- Предыдущее сообщение было в 17:17 ----------
я после резета ничего не вижу, на то он и резет.
Если raid "не знает" что он рассинхронизирован, то будет происходить чтение с с обоих дисков. Ошибки на уровне md не возникает. Ошибка возникает на уровне логической структуры файловой системы.
А ionice фактически бесполезен. Вроде бы он работает, но на приличной нагрузке я не наблюдал чтобы он спасал ситуацию. В отличие от обычных приоритетов cpu, с диском невозможно отменить или заморозить операцию ввода-вывода.
Зато можно ограничить бекап в скорости работы.
Произвольный характер доступа не позволяет использовать такую технику везде.
Так что в mysql это используется только для текстовых индексов и только в myisam.
Кроме того, есть утилита myisampack, которая позволяет сжать и записи таблицы . Правда таблица становится только для чтения.
Другие субд тоже могут использовать эту технику.
Уменьшение объема вследствие нормализации куда более реально.
StarDust, но ведь исходные данные в файлах тоже могут содержать какие-то денормализованные поля-связи , а значит в процессе нормализации эти поля уменьшатся.
