Файловая система XFS сломана в RHEL / CentOS 6.x - Что я могу с этим поделать?
Последние версии RHEL / CentOS (EL6) внесли некоторые интересные изменения в Файловая система XFS Я зависел от сильно уже более десяти лет. Я провел часть прошлого лета в погоне за Ситуация с разреженными файлами XFS в результате плохо документированного бэкпорта ядра. У других было досадные проблемы с производительностью или непоследовательное поведение с момента перехода на EL6.
XFS была моей файловой системой по умолчанию для данных и разделов роста, поскольку она обеспечивала стабильность, масштабируемость и хороший прирост производительности по сравнению с файловыми системами ext3 по умолчанию.
В ноябре 2012 года возникла проблема с XFS в системах EL6. Я заметил, что мои серверы показывали аномально высокую нагрузку на систему даже в режиме ожидания. В одном случае ненагруженная система будет показывать постоянную среднюю нагрузку 3+. В других случаях был скачок нагрузки на 1+. Количество смонтированных файловых систем XFS, по-видимому, влияло на степень увеличения нагрузки.
В системе есть две активные файловые системы XFS. Нагрузка +2 после обновления затронутого ядра. 
Копнув глубже, я нашел несколько тем на Список рассылки XFS что указывало на повышенную частоту xfsaild процесс сидит в СТАТИСТИКА D штат. Соответствующие Отслеживание ошибок CentOS и Red Hat Bugzilla записи обрисовывают специфику проблемы и делают вывод, что это не проблема производительности; только ошибка в сообщении о загрузке системы в ядрах новее 2.6.32-279.14.1.el6.
Какого черта?!?
Я понимаю, что в разовой ситуации отчет о нагрузке может не иметь большого значения. Попробуйте управлять этим с помощью вашей 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, который демонстрирует такое же поведение.
У меня была новая очередь сборки системы, и мне пришлось обходить эту проблему, либо блокируя версии ядра в выпуске до ноября 2012 года для EL6.3, либо просто не используя XFS, выбрав ext4 или ZFS, в серьезный штраф за производительность для конкретного настраиваемого приложения, запущенного поверх. Рассматриваемое приложение в значительной степени полагается на некоторые атрибуты файловой системы XFS для учета недостатков в дизайне приложения.
Идя за Red Hat's платный сайт базы знанийпоявится запись, в которой говорится:
Высокая средняя нагрузка наблюдается после установки ядра 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 представила эту ошибку. Oни должен включить исправление в ядро опечаток. Одним из преимуществ использования корпоративных операционных систем является то, что они обеспечивают последовательная и предсказуемая цель платформы. Эта ошибка нарушила работу уже работающих систем во время цикла исправлений и снизила уверенность в развертывании новых систем. Пока я мог применить один из предлагаемые патчи к исходному кодунасколько это масштабируемо? Это потребует некоторой бдительности, чтобы обновляться по мере изменения ОС.
Какой здесь правильный ход?
- Мы знаем, что это возможно исправить, но не когда.
- Поддержка собственного ядра в экосистеме Red Hat имеет свой набор предостережений.
- Как это влияет на право на поддержку?
- Должен ли я просто наложить работающее ядро EL6.3 поверх недавно построенных серверов EL6.4, чтобы получить надлежащую функциональность XFS?
- Мне просто подождать, пока это официально не исправят?
- Что это говорит об отсутствии у нас контроля над циклами выпуска корпоративных версий Linux?
- Вы так долго полагались на файловую систему XFS из-за ошибки планирования / проектирования?
Редактировать:
Этот патч был включен в самую последнюю CentOSPlus выпуск ядра (ядро-2.6.32-358.2.1.el6.centos.plus). Я тестирую это на своих системах CentOS, но для серверов на базе Red Hat это не очень помогает.
Это было исправлено (тихо) от Red Hat 23 апреля 2013 г. в Ядро RHEL-2.6.32-358.6.1.el6 в рамках обновления 6.4 ...
В какой момент имеет смысл отказываться от ядер и пакетов, предоставляемых ОС, если ведущий разработчик нарушил важную функцию?
«В тот момент, когда ядро или пакеты поставщика настолько ужасно сломаны, что влияют на ваш бизнес» - вот мой общий ответ (по совпадению, это также тот момент, когда я говорю, что имеет смысл начать искать способы отойти от отношений с поставщиками) .
В основном, как вы и другие сказали, RedHat, похоже, не хочет исправлять это в своем распределенном ядре (по какой-либо причине). Это в значительной степени оставляет вас в ситуации, когда вам придется свернуть собственное ядро (поддерживать его в актуальном состоянии с помощью исправлений, поддерживать свой собственный пакет и устанавливать его в своих системах с помощью Puppet или аналогичного, или запускать сервер пакетов, который Yum или что-то еще, что они использовать сегодня можно ссылку), или взять свои шарики и пойти домой.
Да, я знаю, что взять свои шарики и вернуться домой часто бывает дорогим предложением - смена поставщика ОС - огромная боль, особенно в мире Linux, где с административной точки зрения варианты радикально отличаются.
Другие варианты, такие как переход на полностью CentOS, также непривлекательны (потому что вы теряете поддержку, и вы по-прежнему получаете код RedHat, созданный кем-то другим, поэтому у вас все еще будет эта ошибка).
К сожалению, если достаточное количество людей (т.е. «огромные компании») не возьмут свои шарики и не пойдут домой, поставщик не будет так сильно заботиться о том, чтобы обмануть людей, отправив плохой код и не исправив его.
Если вам нужно исправить ядро RHEL, вы жестяная банка сделай это сам и получи официальную поддержку на который ядро, вам просто нужно, чтобы они его сертифицировали.
В соглашении о поддержке RHEL для этого есть положения - ISTR вы ограничены 1 или 2 в квартал или год, но не можете вспомнить наверняка.