Raquel, parte de nuestro equipo de trabajo, nos ha hecho el favor de crear esta crónica porque conoce a la perfección este tema.
Solución:
extensión[234] los sistemas de archivos tienen un número máximo fijo de inodos; cada archivo o directorio requiere un inodo. Puede ver el recuento actual y los límites con df -i. Por ejemplo, en un sistema de archivos ext3 de 15 GB, creado con la configuración predeterminada:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda 1933312 134815 1798497 7% /
No hay límite en los directorios en particular más allá de esto; Sin embargo, tenga en cuenta que cada archivo o directorio requiere al menos un bloque de sistema de archivos (generalmente 4 KB), incluso si se trata de un directorio con un solo elemento.
Sin embargo, como puede ver, es poco probable que 80,000 inodos sean un problema. y con el dir_index opción (activar con tune2fs), las búsquedas en directorios grandes no son demasiado importantes. Sin embargo, tenga en cuenta que muchas herramientas administrativas (como ls o rm) puede tener dificultades para manejar directorios con demasiados archivos. Como tal, se recomienda dividir sus archivos para que no tenga más de unos pocos cientos o miles de elementos en un directorio determinado. Una manera fácil de hacer esto es codificar cualquier ID que esté usando y usar los primeros dígitos hexadecimales como directorios intermedios.
Por ejemplo, supongamos que tiene el ID de artículo 12345 y se reduce a 'DEADBEEF02842.......'. Puede almacenar sus archivos en /storage/root/d/e/12345. Ahora ha reducido la cantidad de archivos en cada directorio en 1/256.
Si el sistema de archivos de su servidor tiene la dir_index característica activada (ver tune2fs(8) para obtener detalles sobre cómo verificar y activar la función), entonces puede almacenar razonablemente más de 100,000 archivos en un directorio antes de que el rendimiento se degrade. (dir_index ha sido el predeterminado para los nuevos sistemas de archivos para la mayoría de las distribuciones durante varios años, por lo que solo sería un antiguo sistema de archivos que no tiene la función activada de forma predeterminada).
Dicho esto, agregar otro nivel de directorio para reducir la cantidad de archivos en un directorio por un factor de 16 o 256 mejoraría drásticamente las posibilidades de cosas como ls * trabajando sin sobrepasar el máximo del kernel argv Talla.
Por lo general, esto se hace con algo como:
/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...
es decir, anteponiendo una letra o un dígito a la ruta, en función de alguna característica que pueda calcular a partir del nombre. (Los dos primeros caracteres de md5sum o sha1sum del nombre del archivo es un enfoque común, pero si tiene identificadores de objeto únicos, entonces 'a'+ id % 16 es un mecanismo bastante fácil para determinar qué directorio usar).
60000 no es nada, 20000 también. Pero debe agrupar estos 20000 por cualquier medio para acelerar el acceso a ellos. Tal vez en grupos de 100 o 1000, tomando el número del directorio y dividiéndolo por 100, 500, 1000, lo que sea.
Por ejemplo, tengo un proyecto donde los archivos tienen números. Los agrupo en 1000, así que tengo
id/1/1332
id/3/3256
id/12/12334
id/350/350934
En realidad, es posible que tenga un límite estricto: algunos sistemas tienen inodos de 32 bits, por lo que está limitado a una cantidad de 2 ^ 32 por sistema de archivos.
Te mostramos comentarios y calificaciones
Nos encantaría que puedieras dar visibilidad a esta división si lograste el éxito.