Error en la implementación de la función ext4 dir_index que está utilizando en su sistema de archivos de destino.
Solución:recrear el sistema de archivos sin dir_index. O deshabilite la función usando tune2fs (se requiere precaución, consulte el enlace relacionado Novell SuSE 10/11:Deshabilitar la indexación de H-Tree en un sistema de archivos ext3 que, aunque se relaciona con ext3 puede necesitar una precaución similar.
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4:Misteriosos errores "No queda espacio en el dispositivo"
ext4 tiene una función llamada dir_index habilitada de forma predeterminada, que es bastante susceptible a colisiones hash.
......
ext4 tiene la posibilidad de codificar los nombres de archivo de su contenido. Esto mejora el rendimiento, pero tiene un "pequeño" problema:ext4 no aumenta su tabla hash cuando comienza a llenarse. En su lugar, devuelve -ENOSPC o "no queda espacio en el dispositivo".
Sugerencias de opciones mejores que ext4 para almacenar grandes cantidades de archivos pequeños:
Si está utilizando el sistema de archivos como un almacén de objetos, es posible que desee considerar el uso de un sistema de archivos que se especialice en eso, posiblemente en detrimento de otras características. Una búsqueda rápida en Google encontró Ceph , que parece ser de código abierto y se puede montar como un sistema de archivos POSIX, pero también se puede acceder con otras API. No sé si vale la pena usarlo en un solo host, sin aprovechar la replicación.
Otro sistema de almacenamiento de objetos es Swift de OpenStack . Sus documentos de diseño dicen que almacena cada objeto como un archivo separado, con metadatos en xattrs. Aquí hay un artículo al respecto. Su guía de implementación dice que descubrieron que XFS brindaba el mejor rendimiento para el almacenamiento de objetos. Entonces, aunque la carga de trabajo no es lo mejor para XFS, aparentemente fue mejor que la competencia cuando RackSpace estaba probando cosas. Posiblemente, Swift prefiera XFS porque XFS tiene un soporte bueno/rápido para atributos extendidos. Podría ser que ext3/ext4 funcionara bien en discos individuales como backend de almacenamiento de objetos si no se necesitaran metadatos adicionales (o si se mantuvieran dentro del archivo binario).
Swift realiza la replicación/equilibrio de carga por usted, y sugiere que le proporcione sistemas de archivos creados en discos sin formato, no RAID . Señala que su carga de trabajo es esencialmente el peor de los casos para RAID5 (lo que tiene sentido si hablamos de una carga de trabajo con escrituras de archivos pequeños. XFS generalmente no los empaqueta de la cabeza a la cola, por lo que no obtener escrituras de banda completa, y RAID5 tiene que hacer algunas lecturas para actualizar la banda de paridad. Los documentos de Swift también hablan sobre el uso de 100 particiones por unidad. Supongo que es un término de Swift, y no se trata de hacer 100 sistemas de archivos XFS diferentes en cada Disco SATA.
Ejecutar un XFS independiente para cada disco es realmente una gran diferencia . En lugar de uno gigantesco mapa de inodos libres, cada disco tendrá un XFS separado con listas libres separadas. Además, evita la penalización de RAID5 por escrituras pequeñas.
Si ya tiene su software creado para usar un sistema de archivos directamente como un almacén de objetos, en lugar de pasar por algo como Swift para manejar la replicación/equilibrio de carga, entonces al menos puede evitar tener todos sus archivos en un solo directorio. (No vi que los documentos de Swift digan cómo distribuyen sus archivos en varios directorios, pero estoy seguro de que lo hacen).
Con casi cualquier sistema de archivos normal, ayudará usar una estructura como
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Probablemente alrededor de 10k entradas sea razonable, por lo que tomar 4 caracteres bien distribuidos de los nombres de sus objetos y usarlos como directorios es una solución fácil. No tiene que estar muy bien equilibrado. El extraño directorio de 100k probablemente no sea un problema notable, y tampoco lo serán algunos directorios vacíos.
XFS no es ideal para grandes cantidades de archivos pequeños. Hace lo que puede, pero está más optimizado para transmitir escrituras de archivos más grandes. Sin embargo, es muy bueno en general para uso general. No tiene ENOSPC en colisiones en su indexación de directorios (AFAIK), y puede manejar tener un directorio con millones de entradas. (Pero aún es mejor usar al menos un árbol de un nivel).
Dave Chinner hizo algunos comentarios sobre el rendimiento de XFS con una gran cantidad de inodos asignados, lo que lleva a un touch lento. actuación. Encontrar un inodo libre para asignar comienza a tomar más tiempo de CPU, ya que el mapa de bits del inodo libre se fragmenta. Tenga en cuenta que esto no es un problema de un gran directorio frente a varios directorios, sino un problema de muchos inodos utilizados en todo el sistema de archivos. Dividir sus archivos en varios directorios ayuda con algunos problemas, como el que ext4 se atragantó en el OP, pero no el problema de todo el disco de realizar un seguimiento del espacio libre. El sistema de archivos separado por disco de Swift ayuda con esto, en comparación con XFS gigante en un RAID5.
No sé si btrfs es bueno en esto, pero creo que puede serlo. Creo que Facebook emplea a su desarrollador principal por una razón. :P Algunos puntos de referencia que he visto, de cosas como descomprimir una fuente del kernel de Linux, muestran que btrfs funciona bien.
Conozco reiserfs fue optimizado para este caso, pero apenas se mantiene, si es que se mantiene. Realmente no puedo recomendar ir con reiser4. Sin embargo, podría ser interesante experimentar. Pero es, con mucho, la opción menos segura para el futuro. También he visto informes de degradación del rendimiento en reiserFS antiguos, y no hay una buena herramienta de desfragmentación. (google filesystem millions of small files y mire algunas de las respuestas de stackexchange existentes).
Probablemente me estoy perdiendo algo, así que recomendación final:¡pregunta sobre esto en serverfault! Si tuviera que elegir algo en este momento, diría que pruebe BTRFS, pero asegúrese de tener copias de seguridad. (especialmente si utiliza la redundancia de disco múltiple incorporada de BTRFS, en lugar de ejecutarla sobre RAID. Las ventajas de rendimiento podrían ser grandes, ya que los archivos pequeños son una mala noticia para RAID5, a menos que sea una carga de trabajo de lectura mayoritaria).
Para este problema, a continuación se muestra lo que hice para solucionarlo (es posible que necesite acceso Sudo para los pasos a continuación):
-
El espacio utilizado de Inodes fue del 100%, que se puede recuperar usando el siguiente comando
df -i
Inodos del sistema de archivos IUsed IFree IUse% Montado en
/dev/xvda1 524288 524288 o 100% /
- Necesita liberar el iNoted, por lo tanto, necesita encontrar los archivos que tienen aquí la cantidad de nodos i usando el siguiente comando:
Intente averiguar si se trata de un problema de inodos con:
df -ih
Intente encontrar carpetas raíz con un gran número de inodos:
for i in /*; do echo $i; find $i |wc -l; done
Intenta encontrar carpetas específicas:
for i in /src/*; do echo $i; find $i |wc -l; done
- ahora hemos reducido a cero la carpeta que contiene una gran cantidad de archivos. Ejecute los siguientes comandos uno tras otro para evitar cualquier error (en mi caso, la carpeta real era /var/spool/clientmqueue):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +