Файловая система XFS не работает в RHEL / CentOS 6.x - Что я могу с этим поделать?


28

Последние версии RHEL / CentOS (EL6) принесла некоторые интересные изменения в XFS файловую систему я зависела от степени уже более десяти лет. Я провёл часть прошлого лета, отыскивая ситуацию с разреженными файлами XFS из-за плохо документированного бэкпорта ядра. У других были неудачные проблемы с производительностью или противоречивое поведение после перехода на EL6.

XFS была моей файловой системой по умолчанию для данных и разделов роста, поскольку она обеспечивала стабильность, масштабируемость и хорошее повышение производительности по сравнению с файловыми системами ext3 по умолчанию.

Существует проблема с XFS в системах EL6, которая появилась в ноябре 2012 года. Я заметил, что на моих серверах наблюдалась чрезмерно высокая загрузка системы, даже в режиме ожидания. В одном случае незагруженная система будет показывать постоянную загрузку в среднем 3+. В других случаях было увеличение нагрузки на 1+. Количество смонтированных файловых систем XFS, похоже, влияло на серьезность увеличения нагрузки.

Система имеет две активные файловые системы XFS. Загрузка составляет +2 после обновления до затронутого ядра. введите описание изображения здесь

Копаем глубже, я нашел несколько потоков на список рассылки XFS , которые указывали на повышенной частоте xfsaildпроцесса , сидящей в STAT D состоянии. Соответствующие записи CentOS Bug Tracker и Red Hat Bugzilla описывают специфику проблемы и делают вывод, что это не проблема производительности; только ошибка в сообщении о загрузке системы в ядрах новее, чем 2.6.32-279.14.1.el6 .

WTF?!?

В разовой ситуации я понимаю, что отчетность о нагрузке может не иметь большого значения. Попробуйте управлять этим с помощью своей NMS и сотен или тысяч серверов! Это было идентифицировано в ноябре 2012 года в ядре 2.6.32-279.14.1.el6 согласно EL6.3. Ядра 2.6.32-279.19.1.el6 и 2.6.32-279.22.1.el6 были выпущены в последующие месяцы (декабрь 2012 и февраль 2013) без изменений в этом поведении. С тех пор, как была обнаружена эта проблема, была выпущена новая версия операционной системы. EL6.4 был выпущен и теперь находится в ядре 2.6.32-358.2.1.el6 , которое демонстрирует то же поведение.

У меня была новая очередь на сборку системы, и мне пришлось обойти эту проблему: либо заблокировать версии ядра в выпуске EL6.3 до ноября 2012 года, либо просто не использовать XFS, выбрав ext4 или ZFS , с серьезным снижением производительности для конкретного пользовательского приложения, запущенного поверх. Рассматриваемое приложение в значительной степени опирается на некоторые атрибуты файловой системы XFS для учета недостатков в дизайне приложения.

Идя за платным сайтом базы знаний Red Hat , появляется запись, гласящая:

Высокая средняя загрузка наблюдается после установки ядра 2.6.32-279.14.1.el6. Высокая средняя загрузка вызвана переходом xfsaild в состояние D для каждого устройства в формате XFS.

В настоящее время нет решения по этому вопросу. В настоящее время он отслеживается через Bugzilla # 883905. Обходной путь Понизьте установленный пакет ядра до версии ниже 2.6.32-279.14.1.

(кроме понижения ядра не вариант на RHEL 6.4 ...)

Таким образом, у нас 4+ месяца на решение этой проблемы без реального исправления, запланированного для релизов ОС EL6.3 или EL6.4 Предлагается исправление для EL6.5 и исправление исходного кода ядра ... Но мой вопрос:

В какой момент имеет смысл отойти от предоставленных ОС ядер и пакетов, когда сопровождающий вышестоящий сопровождающий нарушил важную функцию?

Red Hat представила эту ошибку. Они должны включить исправление в ядро ​​с ошибками. Одним из преимуществ использования корпоративных операционных систем является то, что они обеспечивают согласованную и предсказуемую цель платформы . Эта ошибка приводила к повреждению систем, уже находящихся в работе в течение цикла исправлений, и уменьшала уверенность в развертывании новых систем. Хотя я мог бы применить один из предложенных патчей к исходному коду , насколько он масштабируемый? Требуется некоторая бдительность, чтобы постоянно обновляться по мере изменения ОС.

Какой правильный шаг здесь?

  • Мы знаем, что это можно исправить, но не когда.
  • Поддержка вашего собственного ядра в экосистеме Red Hat имеет свой собственный набор предостережений.
  • Как это влияет на право на поддержку?
  • Должен ли я просто наложить работающее ядро ​​EL6.3 поверх вновь построенных серверов EL6.4, чтобы получить надлежащую функциональность XFS?
  • Должен ли я просто подождать, пока это не будет официально исправлено?
  • Что это говорит о недостатке контроля над циклами выпуска Linux на предприятии?
  • Долго ли полагался на файловую систему XFS на ошибку планирования / проектирования?

Редактировать:

Этот патч был включен в самый последний выпуск ядра CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Я тестирую это на своих системах CentOS, но это мало помогает для серверов на базе Red Hat.


3
Я всегда был убежден, что если вы используете EL6 и платите поддержку RHEL, то это их обязанность исправить это для вас?
Том О'Коннор

6
Да ... Red Hat это исправит ... По собственному расписанию !! - Эта проблема всплыла в конце 2012 года. Она до сих пор не исправлена. Это никогда не планируется на ремонт до выхода RHEL 6.5, так что технически они являются заботясь о ней ...
ewwhite

Что ж, с отношением, которое показывает Red Hat (см. Трекер ошибок), я, честно говоря, не верю, что они больше беспокоятся о XFS. Кастомное ядро ​​имеет здесь смысл, но какой смысл платить за поддержку? Может быть, CentOS - твой путь?
pauska

5
<rant> Я понимаю ваше разочарование, я раньше отвечал за смешанную среду RHEL / CentOS, и RH иногда очень усложняет вам держать вещи на складе, видя, как они постоянно "игнорируют", чтобы исправлять критические ошибки, иногда которые они представляют сами , Затем они планируют исправление для следующего основного выпуска, но, поскольку они не поддерживают обновление до следующей основной версии, это мало помогает. В какой-то момент я решил выбить их официальные ядра на некоторых блоках RHEL5 просто потому, что мне пришлось это сделать из-за отсутствия конкретной функции. </ Rant>
Adrian Frühwirth

1
@ MartinSchröder SLES не особенно популярен в США, но это может быть вариант. Сам XFS не сломан, но Red Hat справляется с этим. Это стоит рассмотреть.
ewwhite

Ответы:


14

В какой момент имеет смысл отойти от предоставленных ОС ядер и пакетов, когда сопровождающий вышестоящий сопровождающий нарушил важную функцию?

«В тот момент, когда ядро ​​или пакеты вендора настолько ужасно сломаны, что влияют на ваш бизнес», - мой общий ответ (по совпадению, это также касается момента, когда я говорю, что имеет смысл начать искать пути отхода от отношений с вендором). ,

В принципе, как вы и другие сказали, RedHat, похоже, не хочет исправлять это в своем распределенном ядре (по любой причине). Это в значительной степени оставляет вас в ситуации необходимости накатывать свое собственное ядро ​​(обновлять его самостоятельно, устанавливать собственный пакет и устанавливать его на свои системы с Puppet или аналогичным, или запускать сервер пакетов, который Yum или что-то другое). использовать сегодня можно ссылочку) или забирая шарики и собираясь домой.


Да, я знаю, что забрать свои шарики и пойти домой часто - дорогое предложение - переключение поставщиков ОС - огромная проблема, особенно в мире Linux, где варианты радикально отличаются от административной точки зрения.
Другие варианты, такие как полное закрытие CentOS, также непривлекательны (потому что вы теряете поддержку, и вы по-прежнему получаете код RedHat, созданный кем-то другим, так что у вас все еще будет эта ошибка).

К сожалению, если достаточное количество людей (то есть «огромных компаний») не возьмут свои шарики и не пойдут домой, вендор не будет слишком заботиться о том, чтобы обмануть людей, отправляя плохой код и не исправляя его.


14

Это было исправлено ( незаметно ) Red Hat 23 апреля 2013 г. в RHEL kernel-2.6.32-358.6.1.el6 как часть обновлений 6.4 errata ...


2
Спустя 20 недель после сообщения об ошибке, через 2 недели после публикации здесь, вы думаете, что, возможно, redhat видел все советы, говорящие «гулять»
Jasen

Может быть? Я не уверен.
ewwhite

3

Если вам нужно исправить ядро ​​RHEL, вы можете сделать это самостоятельно и получить официальную поддержку в этом ядре, вам просто нужно, чтобы они его сертифицировали.

В соглашении о поддержке RHEL предусмотрены такие условия: ISTR ограничен 1 или 2 в квартал или год, но вы точно не помните.


Очень приятно знать!
ewwhite

Это не правильно. Вы можете запросить ускоренное исправление в Red Hat, но есть критерии, которым должна соответствовать проблема для доставки, и несколько различных способов доставки поддерживаемого ускоренного исправления. Если вы перекомпилируете свое собственное ядро, это ядро ​​не поддерживается Red Hat.
suprjami

У меня есть клиент, который делает именно это. Я не думаю, что они делают это для всех, но они делают это.
MikeyB
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.