27 votos

El sistema de ficheros XFS se rompe en RHEL/CentOS 6.x - ¿Qué puedo hacer al respecto?

Las últimas versiones de RHEL/CentOS (EL6) trajo algunos cambios interesantes para el sistema de ficheros XFS he dependido fuertemente por más de una década. He pasado parte del verano pasado persiguiendo a un XFS archivo disperso situación resultante de un mal documentado núcleo backport. Otros han tenido la desafortunada problemas de rendimiento o comportamiento incoherente desde que se mudó a EL6.

XFS era mi sistema de archivo predeterminado para los datos y el crecimiento de las particiones, ya que ofrece estabilidad, escalabilidad y un buen impulso en el rendimiento sobre el defecto de los sistemas de ficheros ext3.

Hay un problema con XFS en EL6 de los sistemas que salieron a la luz en noviembre de 2012. Me di cuenta de que mis servidores estaban mostrando abnormaly-altas cargas del sistema, incluso cuando está en reposo. En un caso, un sistema de descarga que muestran una carga constante promedio de 3+. En otros, fue un 1+ golpe en la carga. El número de montar los sistemas de ficheros XFS parece influir en la gravedad de la aumentar la carga.

El sistema tiene dos sistemas de ficheros XFS. La carga es +2, tras la actualización a los afectados del núcleo. enter image description here

Cavar más profundo, he encontrado un par de hilos en el XFS lista de correo que apuntaban a un aumento de la frecuencia de la xfsaild proceso sentado en el STAT D estado. La correspondiente CentOS Bug Tracker y el Bugzilla de Red Hat entradas esquema de los detalles de la cuestión y a la conclusión de que esto no es un problema de rendimiento; sólo un error en la información de la carga del sistema en los núcleos más recientes que 2.6.32-279.14.1.el6.

WTF?!?

En una situación, entiendo que la carga de presentación de informes no puede ser un gran problema. Trate de manejar que con su NMS y cientos o miles de servidores! Este fue identificado en noviembre de 2012 en el kernel 2.6.32-279.14.1.el6 bajo EL6.3. Los núcleos 2.6.32-279.19.1.el6 y 2.6.32-279.22.1.el6 fueron puestos en libertad en los siguientes meses (de diciembre de 2012 y febrero de 2013) sin cambiar este comportamiento. No ha llegado a una nueva versión menor del sistema operativo ya que este problema fue identificado. EL6.4 fue lanzado, y ahora está en el kernel 2.6.32-358.2.1.el6, que presenta el mismo comportamiento.

He tenido una nueva generación del sistema de la cola y se han tenido que solucionar el problema, el bloqueo de las versiones del kernel en el pre-noviembre de 2012 release para EL6.3, o simplemente no usar XFS, optando por el sistema de archivos ext4 o ZFS, a una severa penalización de rendimiento para el específico personalizado de ejecución de la aplicación en la cima. La aplicación en cuestión se basa en gran medida en algunos de los sistemas de ficheros XFS atributos para dar cuenta de las deficiencias en el diseño de la aplicación.

Va detrás de Red Hat paywalled knowledgebase sitio, aparece una entrada que indica:

Alta carga promedio se observa después de instalar el núcleo 2.6.32-279.14.1.el6. El alto promedio de carga es causada por xfsaild va en D estado para cada XFS dispositivo formateado.

Actualmente no hay ninguna solución para este problema. En la actualidad se está seguimiento a través de Bugzilla #883905. Solución Degradar el instalado el paquete del kernel a una versión inferior, a continuación, 2.6.32-279.14.1.

(a excepción de la descalificación de los kernels no es una opción en RHEL 6.4...)

Por lo tanto, estamos de 4 meses con este problema, sin nada de revisión previsto para el EL6.3 o EL6.4 OS libera. Hay una propuesta de solución para EL6.5 y una fuente del kernel patch disponible... Pero mi pregunta es:

¿En qué punto tiene sentido para salir desde el sistema operativo proporcionado por los núcleos y paquetes cuando el mantenedor se ha roto una característica importante?

Red Hat introducido este error. Se debe incorporar una corrección en un parche del kernel. Una de las ventajas del uso corporativo de los sistemas operativos es que proporcionan una consistente y predecible de la plataforma de destino. Este error interrumpido sistemas que ya están en producción durante un ciclo de revisión de seguridad y la reducción de la confianza en la implementación de nuevos sistemas. Mientras yo pueda aplicar una de las propuestas de los parches al código fuente, cómo escalable es eso? Se requeriría algo de vigilancia para mantener actualizado el sistema operativo de los cambios.

¿Cuál es la forma correcta de mover aquí?

  • Sabemos que esto podría ser corregido, pero no cuando.
  • Apoyando a su propio kernel en Red Hat ecosistema tiene su propio conjunto de salvedades.
  • ¿Cuál es el impacto sobre el apoyo a la elegibilidad?
  • Debo superposición de un trabajo EL6.3 núcleo en la parte superior de la recién construir EL6.4 servidores para obtener el adecuado XFS funcionalidad?
  • Debo esperar hasta que este se fija oficialmente?
  • ¿Qué dice esto acerca de la falta de control que tenemos sobre enterprise Linux ciclos de lanzamiento?
  • Estaba confiando en un sistema de ficheros XFS por tanto tiempo de planificación/diseño de error?

Editar:

Este parche fue incorporado en el más reciente CentOSPlus versión del núcleo (kernel 2.6.32-358.2.1.el6.centos.plus). Estoy probando esto en mi CentOS sistemas, pero esto no ayuda mucho para la basada en Red Hat servidores.

14voto

voretaq7 Puntos 63415

¿En qué punto tiene sentido para salir desde el sistema operativo proporcionado por los núcleos y paquetes cuando el mantenedor se ha roto una característica importante?

"En el punto donde el proveedor del núcleo o de los paquetes son tan horriblemente roto que afecten a su negocio" es mi respuesta general (coincidentemente es también sobre el punto en el que me dicen que tiene sentido comenzar a buscar formas de salir desde el proveedor de la relación).

Básicamente, como usted y otros han dicho, RedHat parece que no quieren el parche esta en sus distribuido kernel (por cualquier razón). Que casi te deja en la situación de tener que lanzar su propio núcleo (y se mantiene hasta la fecha en los parches de sí mismo, el mantenimiento de su propio paquete e instalar en sus sistemas con Puppet o similares, o la ejecución de un paquete de servidor que Yum o lo que sea que uso hoy en día puede hacer referencia a), o tomar sus canicas y se va a casa.


Sí, sé que tomar sus canicas y se va a casa es a menudo una proposición costosa -- conmutación de proveedores de sistemas operativos es un gran dolor, especialmente en el mundo de Linux, donde los sabores son radicalmente diferentes desde un punto de vista administrativo.
Otras opciones como ir totalmente CentOS son también poco atractivo (porque se pierde apoyo, y usted todavía está recibiendo esencialmente RedHat del código construido por alguien más, así que usted todavía tiene este error).

Desafortunadamente, a menos que la gente lo suficiente (es decir, "de las compañías más grandes) tomar sus canicas y se van a casa el proveedor no importa tanto dañando a las personas mediante el envío de código de malo y no arreglarlo.

14voto

Tina Puntos 21

Esto fue corregido (en silencio) por Red Hat 23 de abril de 2013 en red hat enterprise linux kernel 2.6.32-358.6.1.el6 como parte de la 6.4 las actualizaciones de erratas...

3voto

MikeyB Puntos 26178

Si usted necesita para aplicar un parche al kernel de red hat enterprise linux, usted puede hacerlo usted mismo y ser compatible oficialmente con ese kernel, solo necesitarás para ellos para certificar.

Hay disposiciones en la RHEL contrato de soporte técnico para hacerlo - ISTR está limitado a 1 o 2 por trimestre o un año, pero no puede recordar por seguro.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: