Что такое & ldquo; md value mismatch_count & rdquo; рассчитывать?
С момента обновления до 11.04 я пытаюсь вернуть мой 5-дисковый RAID5-массив в онлайн-режиме. Сначала массив был разделен на две части, я попытался использовать команду create с опцией take clean, чтобы вернуть ее в один массив. Я думаю, что это принесло больше вреда, чем пользы, потому что mdadm default теперь использует формат метаданных 1.2, а не 0.90, который, по моему мнению, заставлял метаданные записываться поверх некоторых моих данных. Это вызвало сомнения в упорядочении диска, я думал, что массив должен иметь, поскольку этот порядок не приведет к монтируемому диску, поэтому я использовал скрипт для проверки всех возможных заказов на пять дисков, и ни один из них не был установлен, я тогда попробовал один и тот же процесс вместо установки я запускал xfs_check, а затем целевой xfs_repair (с опцией -n, чтобы предотвратить какие-либо фактические изменения).
Все это привело меня к довольно небольшой коллекции дисковых макетов, но я, очевидно, одно изменение, чтобы попробовать xfs_repair, и данные могут быть большими, чтобы попробовать резервное копирование, поэтому я подумал, что если бы массив выполнял проверку на четность, это была бы хорошая идея, я начал с двух порядков дискового массива, которые, как я думал, скорее всего будет правильным проверьте, и, как оказалось, оба они имели ровно 8 для mismatch_count, и эти 8 были обнаружены почти мгновенно. Как это возможно? Оба дисковых упорядочения очень разные (acbde vs adcbe) ... возможно ли, что порядок диска не повлияет на проверку четности? Только по фактическим базовым данным? Если это так, было бы разумно попытаться выполнить ремонт массива из одного из этих макетов, а затем перепроверять файловую систему, чтобы узнать, может ли она теперь монтировать ... но я не решаюсь это сделать, поскольку это будет первый шаг я принял, что намеренно пишет больше, чем метаданные на диски.
14 ответов
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
-
1FYI mismatch_count отслеживает страницы, которые не синхронизированы в массиве. Это скруббер с бедным человеком, который защищает от бит-гниения. Он документирован в документах ядра: lxr.linux.no/linux+v3.1.2/Documentation/md.txt . Я подозреваю, что ваш предыдущий выбор выравнивания создавал несвязанные обращения, которые могли фактически создать устаревшие записи. Это может быть достойно отчета об ошибке. – ppetraki 22 November 2011 в 21:14
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
-
1FYI mismatch_count отслеживает страницы, которые не синхронизированы в массиве. Это скруббер с бедным человеком, который защищает от бит-гниения. Он документирован в документах ядра: lxr.linux.no/linux+v3.1.2/Documentation/md.txt . Я подозреваю, что ваш предыдущий выбор выравнивания создавал несвязанные обращения, которые могли фактически создать устаревшие записи. Это может быть достойно отчета об ошибке. – ppetraki 22 November 2011 в 21:14
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
-
1FYI mismatch_count отслеживает страницы, которые не синхронизированы в массиве. Это скруббер с бедным человеком, который защищает от бит-гниения. Он документирован в документах ядра: lxr.linux.no/linux+v3.1.2/Documentation/md.txt . Я подозреваю, что ваш предыдущий выбор выравнивания создавал несвязанные обращения, которые могли фактически создать устаревшие записи. Это может быть достойно отчета об ошибке. – ppetraki 22 November 2011 в 21:14
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь 512k. Переключение на 64k решило мою проблему.
Любопытно, что моя проблема была второй заменой по умолчанию между созданием массива и версией mdadm, в которой я запускал новое создание, размер по умолчанию для полосы был 64k, а теперь он составляет 512k. Переключение на 64k решило мою проблему.
-
1FYI mismatch_count отслеживает страницы, которые не синхронизированы в массиве. Это скруббер с бедным человеком, который защищает от бит-гниения. Он документирован в документах ядра: lxr.linux.no/linux+v3.1.2/Documentation/md.txt . Я подозреваю, что ваш предыдущий выбор выравнивания создавал несвязанные обращения, которые могли фактически создать устаревшие записи. Это может быть достойно отчета об ошибке. – ppetraki 22 November 2011 в 21:14
Это действительно похоже на тему, наиболее подходящую для списка md. Нил Браун будет лучше знать о вашем обновлении метаданных и о том, как это может повлиять на скруббер диска. Если это не проблема, вы просто «ремонтируете» sync_action »от ремонта вашего массива.