Sistema de archivos gran cantidad de archivos en un solo directorio

De acuerdo, no es tan grande, pero necesito usar algo donde se almacenan alrededor de 60,000 archivos con un tamaño promedio de 30kb en un solo directorio (este es un requisito, por lo que no se puede dividir en subdirectorios con un menor número de archivos).

Se accederá a los archivos de forma aleatoria, pero una vez creados, no habrá escrituras en el mismo sistema de archivos. Actualmente estoy usando Ext3 pero lo encuentro muy lento. ¿Alguna sugerencia?

Deberías considerar XFS. Admite una gran cantidad de archivos tanto en el sistema de archivos como a nivel de directorio, y el rendimiento sigue siendo relativamente constante incluso con una gran cantidad de entradas debido a las estructuras de datos del árbol B +.

Hay una página en su wiki con una gran cantidad de artículos y publicaciones que detallan el diseño. Te recomiendo que lo pruebes y lo compares con tu solución actual.

Mil millones de archivos en Linux

El autor de este artículo profundiza en algunos de los problemas de rendimiento en sistemas de archivos con grandes cantidades de archivos y hace algunas buenas comparaciones del rendimiento de varios sistemas de archivos ext3, ext4 y XFS. Esto está disponible como una presentación de diapositivas. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

Muchos archivos en un directorio en ext3 se han discutido en profundidad en el sitio hermano stackoverflow.com

En mi opinión, 60 000 archivos en un directorio en ext3 está lejos de ser ideal, pero dependiendo de sus otros requisitos, podría ser lo suficientemente bueno.

OKAY. Hice algunas pruebas preliminares usando ReiserFS, XFS, JFS, Ext3 (dir_hash habilitado) y Ext4dev (kernel 2.6.26). Mi primera impresión fue que todos fueron lo suficientemente rápidos (en mi robusta estación de trabajo): resulta que la máquina de producción remota tiene un procesador bastante lento.

Experimenté algo extraño con ReiserFS incluso en las pruebas iniciales, así que lo descarté. Parece que JFS tiene un 33% menos de requisitos de CPU que todos los demás, por lo que lo probará en el servidor remoto. Si funciona lo suficientemente bien, lo usaré.

Estoy escribiendo una aplicación que también almacena muchos archivos, aunque los míos son más grandes y tengo 10 millones de ellos que dividiré en varios directorios.

ext3 es lento principalmente debido a la implementación predeterminada de la "lista vinculada". Entonces, si tiene muchos archivos en un directorio, significa que abrir o crear otro será cada vez más lento. Hay algo llamado índice htree que está disponible para ext3 que, según los informes, mejora mucho las cosas. Pero, solo está disponible en la creación del sistema de archivos. Ver aquí: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Como tendrá que reconstruir el sistema de archivos de todos modos y debido a las limitaciones de ext3, mi recomendación es que busque usar ext4 (o XFS). Creo que ext4 es un poco más rápido con archivos más pequeños y tiene reconstrucciones más rápidas. El índice Htree está predeterminado en ext4 por lo que yo sé. Realmente no tengo ninguna experiencia con JFS o Reiser, pero he oído que la gente lo recomienda antes.

En realidad, probablemente probaría varios sistemas de archivos. ¿Por qué no probar ext4, xfs y jfs y ver cuál ofrece el mejor rendimiento general?

Algo que un desarrollador me dijo que puede acelerar las cosas en el código de la aplicación no es hacer una llamada "stat + open" sino más bien "abrir + fstat". El primero es significativamente más lento que el segundo. No estoy seguro si tiene algún control o influencia sobre eso.

Vea mi publicación aquí en stackoverflow. Al almacenar y acceder a hasta 10 millones de archivos en Linux, hay algunas respuestas y enlaces muy útiles.

Usar tune2fs para habilitar dir_index podría ayudar. Para ver si está habilitado:

sudo tune2fs -l /dev/sda1 | grep dir_index

Si no está habilitado:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Pero tengo la sensación de que podría estar yendo por el camino equivocado ... ¿por qué no generar un índice plano y usar algún código para seleccionar aleatoriamente en función de eso? Luego puede usar subdirectorios para una estructura de árbol más optimizada.

ext3 y versiones inferiores admiten hasta 32768 archivos por directorio. ext4 admite hasta 65536 en el recuento real de archivos, pero le permitirá tener más (simplemente no los almacenará en el directorio, lo que no importa para la mayoría de los propósitos de los usuarios).

Además, la forma en que se almacenan los directorios en los sistemas de archivos ext * es esencialmente como una gran lista. En los sistemas de archivos más modernos (Reiser, XFS, JFS) se almacenan como árboles B, que son mucho más eficientes para conjuntos grandes.

Puede almacenar inodos de archivo en lugar de nombres de archivo: acceder a los números de inodo debería ser mucho más rápido que resolver nombres de archivo

No quiere meter tantos archivos en un directorio, quiere algún tipo de estructura. Incluso si es algo tan simple como tener subdirectorios que comienzan con el primer carácter del archivo puede mejorar sus tiempos de acceso. Otro truco tonto que me gusta usar, es forzar al sistema a actualizar su caché con metainformación es ejecutar updatedb regularmente. En una ventana, ejecute slabtop, y en otra ejecute updatedb y verá que se asignará mucha memoria al almacenamiento en caché. Es mucho más rápido de esta manera.

No especificó el tipo de datos en estos archivos. Pero por lo que parece, debería usar algún tipo de base de datos con indexación para búsquedas rápidas.

El sistema de archivos probablemente no sea el almacenamiento ideal para tal requisito. Algún tipo de almacenamiento de base de datos es mejor. Aún así, si no puede evitarlo, intente dividir los archivos en varios directorios y use unionfs para montar (vincular) esos directorios en un solo directorio donde desea que aparezcan todos los archivos. No he usado esta técnica para acelerar en absoluto, pero vale la pena intentarlo.