Si hay como 1,000,000 de archivos individuales (la mayoría de 100k en tamaño) en un solo directorio, de forma plana (no hay otros directorios ni archivos en ellos), ¿habrá algún compromiso en cuanto a la eficiencia o desventajas de cualquier otra manera?¿Qué sucede si hay demasiados archivos en un único directorio en Linux?
ARG_MAX va a tener problemas con eso ... por ejemplo, rm -rf * (mientras está en el directorio) va a decir "demasiados argumentos". Las utilidades que quieran hacer algún tipo de globbing (o un shell) tendrán algún rompimiento de funcionalidad.
Si ese directorio está disponible para el público (digamos vía ftp, o servidor web) puede encontrar problemas adicionales.
El efecto en cualquier sistema de archivos dado depende completamente de ese sistema de archivos. ¿Con qué frecuencia se accede a estos archivos? ¿Qué es el sistema de archivos? Recuerde, Linux (de manera predeterminada) prefiere mantener en la memoria los archivos a los que accedió recientemente al poner los procesos en intercambio, según su configuración. ¿Este directorio se sirve a través de http? ¿Google va a verlo y rastrearlo? Si es así, es posible que deba ajustar la presión de caché VFS y la suavidad.
Editar:
ARG_MAX es un límite para todo el sistema a la cantidad de argumentos se pueden presentar al punto de entrada de un programa. Entonces, tomemos 'rm', y el ejemplo "rm -rf *" - el shell va a convertir '*' en una lista de archivos delimitada por espacios que a su vez se convierte en los argumentos para 'rm'.
Lo mismo va a pasar con ls y muchas otras herramientas. Por ejemplo, ls foo * podría romperse si demasiados archivos comienzan con 'foo'.
Aconsejaría (sin importar qué FS esté en uso) dividirlo en trozos de directorio más pequeños, solo por esa razón.
Cuando accidentalmente ejecuta "ls" en ese directorio, o usa tabulación completada, o desea ejecutar "rm *", tendrá un gran problema. Además, puede haber problemas de rendimiento dependiendo de su sistema de archivos.
Se considera buena práctica agrupar los archivos en directorios que se nombran por los primeros 2 o 3 caracteres de los nombres de archivo, p. Ej.
aaa/
aaavnj78t93ufjw4390
aaavoj78trewrwrwrwenjk983
aaaz84390842092njk423
...
abc/
abckhr89032423
abcnjjkth29085242nw
...
...
mayoría de las distribuciones utilizan Ext3 por defecto, que puede utilizar la indexación b-árbol de directorios grandes. Algunas de las distribuciones tienen esta característica dir_index habilitada de forma predeterminada en otras, usted debería habilitarla usted mismo. Si lo habilita, no hay desaceleración incluso para millones de archivos.
Para ver si dir_index función se activa do (como root):
tune2fs -l /dev/sdaX | grep features
Para activar dir_index función (como root):
tune2fs -O dir_index /dev/sdaX
e2fsck -D /dev/sdaX
Reemplazar /dev/sdaX con partición para la que desea activar eso.
There * is * a penalty, la diferencia es entre una penalización exponencial, lineal o logarítmica – dsm
Haz tus números. Tienes 1mln archivos. Con el índice, le lleva N segundos acceder al archivo por nombre. Ahora lo dividirías en 1000 directorios con 1000 archivos cada uno. Le toma N/2 segundos para acceder al directorio, otro N/2 para acceder al archivo. Total N segundos sin contaje de sobrecarga para conmutar dirs. – vartec
La respuesta obvia es que la carpeta será extremadamente difícil de usar por los humanos mucho antes de cualquier límite técnico, (tiempo tomado para leer la salida de ls para uno, hay docenas de otras razones) ¿Hay alguna buena razón por la que no se puede dividir en subcarpetas?
Mi experiencia con grandes directorios en ext3 y dir_index permitido:
ls en ese directorio) tomará varios minutos por primera vez. Entonces el directorio permanecerá en la memoria caché del kernel y ya no habrá penalización*) no siempre funciona como se esperaba. Esto es sólo si realmente desea realizar una operación en todos los archivos a la vezSin dir_index sin embargo, está muy atornillado :-D
No todos los sistema de archivo soporta que muchos archivos.
En algunos de ellos (ext2, ext3, ext4) es muy fácil alcanzar el límite de inode.
Muchas gracias Señor :) ¡Esta publicación tuya de hecho me ha ayudado mucho! –