¿Importa cuántos archivos guardo en un solo directorio? Si es así, ¿cuántos archivos en un directorio son demasiados y cuáles son los impactos de tener demasiados archivos? (Esto está en un servidor Linux).

Antecedentes: tengo un sitio web de álbum de fotos, y cada imagen cargada se renombra a una identificación de 8 dígitos hexadecimales (por ejemplo, a58f375c.jpg). Esto es para evitar conflictos de nombre de archivo (si se cargan muchos archivos "IMG0001.JPG", por ejemplo). El nombre de archivo original y los metadatos útiles se almacenan en una base de datos. En este momento, tengo alrededor de 1500 archivos en el directorio de imágenes. Esto hace que la inclusión de los archivos en el directorio (a través de un cliente FTP o SSH) tarde unos segundos. Pero no puedo ver que tenga otro efecto que no sea eso. En particular, no parece haber ningún impacto en la rapidez con que se sirve un archivo de imagen al usuario.

He pensado en reducir el número de imágenes haciendo 16 subdirectorios: 0-9 y af. Luego, movería las imágenes a los subdirectorios según el primer dígito hexadecimal del nombre de archivo. Pero no estoy seguro de que haya alguna razón para hacerlo, excepto la lista ocasional del directorio a través de FTP / SSH.

FAT32 :

• Número máximo de archivos: 268,173,300
• Número máximo de archivos por directorio: 2 ¹⁶  - 1 (65,535)
• Tamaño máximo de archivo: 2 GiB - 1 sin LFS , 4 GiB - 1 con

NTFS :

• Número máximo de archivos: 2 ³²  - 1 (4,294,967,295)
• Tamaño máximo de archivo
  • Implementación: 2 ⁴⁴  - 2 ⁶ bytes (16 TiB - 64 KiB)
  • Teórico: 2 ⁶⁴  - 2 ⁶ bytes (16 EiB - 64 KiB)
• Tamaño de volumen máximo
  • Implementación: 2 ³²  - 1 grupos (256 TiB - 64 KiB)
  • Teórico: 2 ⁶⁴  - 1 grupos (1 YiB - 64 KiB)

ext2 :

• Número máximo de archivos: 10 ¹⁸
• Número máximo de archivos por directorio: ~ 1.3 × 10 ²⁰ (problemas de rendimiento anteriores a 10,000)
• Tamaño máximo de archivo
  • 16 GiB (tamaño de bloque de 1 KiB)
  • 256 GiB (tamaño de bloque de 2 KiB)
  • 2 TiB (tamaño de bloque de 4 KiB)
  • 2 TiB (tamaño de bloque de 8 KiB)
• Tamaño de volumen máximo
  • 4 TiB (tamaño de bloque de 1 KiB)
  • 8 TiB (tamaño de bloque de 2 KiB)
  • 16 TiB (tamaño de bloque de 4 KiB)
  • 32 TiB (tamaño de bloque de 8 KiB)

ext3 :

• Número máximo de archivos: min (volumeSize / 2 ¹³ , numberOfBlocks)
• Tamaño máximo de archivo: igual que ext2
• Tamaño de volumen máximo: igual que ext2

ext4 :

• Número máximo de archivos: 2 ³²  - 1 (4,294,967,295)
• Número máximo de archivos por directorio: ilimitado
• Tamaño máximo de archivo: 2 ^44-1  bytes (16 TiB-1)
• Tamaño de volumen máximo: 2 ⁴⁸  - 1 bytes (256 TiB - 1)

He tenido más de 8 millones de archivos en un solo directorio ext3. libc readdir()que utiliza find, lsy la mayoría de los otros métodos discutidos en este hilo para enumerar directorios grandes.

La razón lsy findson lentos en este caso es que readdir()solo lee 32K de entradas de directorio a la vez, por lo que en discos lentos requerirá muchas lecturas para enumerar un directorio. Hay una solución a este problema de velocidad. Escribí un artículo bastante detallado al respecto en: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

La clave es: usar getdents()directamente: http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html en lugar de cualquier cosa que esté basada en libc readdir()para que pueda especificar el búfer tamaño al leer entradas de directorio del disco.

Tengo un directorio con 88,914 archivos. Al igual que usted, esto se usa para almacenar miniaturas y en un servidor Linux.

Los archivos listados a través de FTP o una función php son lentos, sí, pero también hay un impacto en el rendimiento al mostrar el archivo. Por ejemplo, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg tiene un tiempo de espera de 200-400 ms. Como comparación en otro sitio que tengo con alrededor de 100 archivos en un directorio, la imagen se muestra después de solo ~ 40 ms de espera.

He dado esta respuesta, ya que la mayoría de la gente acaba de escribir cómo funcionarán las funciones de búsqueda de directorio, que no usará en una carpeta de miniaturas, solo muestra archivos estáticamente, pero estará interesado en el rendimiento de cómo se pueden usar realmente los archivos .

Depende un poco del sistema de archivos específico en uso en el servidor Linux. Hoy en día, el valor predeterminado es ext3 con dir_index, lo que hace que la búsqueda de directorios grandes sea muy rápida.

Por lo tanto, la velocidad no debería ser un problema, aparte del que ya señaló, que es que las listas tomarán más tiempo.

Hay un límite para el número total de archivos en un directorio. Me parece recordar que definitivamente funciona hasta 32000 archivos.

Tenga en cuenta que en Linux si tiene un directorio con demasiados archivos, es posible que el shell no pueda expandir comodines. Tengo este problema con un álbum de fotos alojado en Linux. Almacena todas las imágenes redimensionadas en un solo directorio. Si bien el sistema de archivos puede manejar muchos archivos, el shell no puede. Ejemplo:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

o

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

Estoy trabajando en un problema similar en este momento. Tenemos una estructura de directorio jerárquico y utilizamos identificadores de imagen como nombres de archivo. Por ejemplo, una imagen con id=1234567se coloca en

..../45/67/1234567_<...>.jpg

usando los últimos 4 dígitos para determinar a dónde va el archivo.

Con unos pocos miles de imágenes, podría usar una jerarquía de un nivel. Nuestro administrador de sistemas sugirió no más de un par de miles de archivos en cualquier directorio dado (ext3) por eficiencia / respaldo / cualquier otra razón que tuviera en mente.

Para lo que vale, acabo de crear un directorio en un ext4sistema de archivos con 1,000,000 de archivos, luego accedo al azar a esos archivos a través de un servidor web. No noté ninguna prima al acceder a aquellos que tienen (digamos) solo tener 10 archivos allí.

Esto es radicalmente diferente de mi experiencia haciendo esto ntfshace unos años.

El mayor problema con el que me he encontrado está en un sistema de 32 bits. Una vez que pasa un cierto número, las herramientas como 'ls' dejan de funcionar.

Intentar hacer algo con ese directorio una vez que pasa esa barrera se convierte en un gran problema.

He estado teniendo el mismo problema. Intentando almacenar millones de archivos en un servidor Ubuntu en ext4. Terminé ejecutando mis propios puntos de referencia. Descubrí que el directorio plano funciona mucho mejor y es más fácil de usar:

Escribió un artículo .

Si el tiempo necesario para implementar un esquema de particionamiento de directorios es mínimo, estoy a favor. La primera vez que deba depurar un problema que implica manipular un directorio de 10000 archivos a través de la consola, lo comprenderá.

Como ejemplo, F-Spot almacena archivos de fotos como AAAA \ MM \ DD \ filename.ext, lo que significa que el directorio más grande con el que he tenido que lidiar mientras manipulo manualmente mi colección de ~ 20000 fotos es de aproximadamente 800 archivos. Esto también hace que los archivos sean más fácilmente navegables desde una aplicación de terceros. Nunca asuma que su software es lo único que accederá a los archivos de su software.

Depende absolutamente del sistema de archivos. Muchos sistemas de archivos modernos usan estructuras de datos decentes para almacenar el contenido de los directorios, pero los sistemas de archivos más antiguos a menudo solo agregaban las entradas a una lista, por lo que recuperar un archivo era una operación O (n).

Incluso si el sistema de archivos lo hace bien, todavía es absolutamente posible que los programas que enumeran el contenido del directorio se desordenen y hagan una clasificación O (n ^ 2), por lo que para estar seguro, siempre limitaría la cantidad de archivos por directorio a no más de 500.

Realmente depende del sistema de archivos utilizado, y también de algunos indicadores.

Por ejemplo, ext3 puede tener muchos miles de archivos; pero después de un par de miles, solía ser muy lento. Principalmente cuando se enumera un directorio, pero también al abrir un solo archivo. Hace unos años, obtuvo la opción 'htree', que acortó drásticamente el tiempo necesario para obtener un inodo dado un nombre de archivo.

Personalmente, uso subdirectorios para mantener la mayoría de los niveles por debajo de mil elementos. En su caso, crearía 256 directorios, con los dos últimos dígitos hexadecimales de la ID. Use los últimos y no los primeros dígitos, para que la carga esté equilibrada.

ext3 tiene límites de tamaño de directorio y dependen del tamaño de bloque del sistema de archivos. No hay un "número máximo" de archivos por directorio, sino un "número máximo de bloques por directorio utilizado para almacenar entradas de archivo". Específicamente, el tamaño del directorio en sí mismo no puede crecer más allá de un árbol b de altura 3, y el despliegue del árbol depende del tamaño del bloque. Vea este enlace para algunos detalles.

https://www.mail-archive.com/[email protected]/msg01944.html

Esto me mordió recientemente en un sistema de archivos formateado con bloques 2K, que inexplicablemente recibía mensajes de kernel llenos de directorio warning: ext3_dx_add_entry: Directory index full!cuando estaba copiando de otro sistema de archivos ext3. En mi caso, un directorio con solo 480,000 archivos no se pudo copiar al destino.

La pregunta se reduce a qué vas a hacer con los archivos.

En Windows, cualquier directorio con más de 2k archivos tiende a abrirse lentamente para mí en Explorer. Si son todos archivos de imagen, más de 1k tienden a abrirse muy lentamente en la vista en miniatura.

En un momento, el límite impuesto por el sistema fue de 32.767. Ahora es más alto, pero incluso eso es demasiados archivos para manejar a la vez en la mayoría de las circunstancias.

Lo que la mayoría de las respuestas anteriores no muestran es que no hay una respuesta de "talla única para todos" a la pregunta original.

En el entorno actual, tenemos un gran conglomerado de hardware y software diferentes: algunos son de 32 bits, otros son de 64 bits, algunos son innovadores y otros son probados y verdaderos, confiables y nunca cambian. A esto se agrega una variedad de hardware más antiguo y más nuevo, sistemas operativos más antiguos y más nuevos, diferentes proveedores (Windows, Unixes, Apple, etc.) y una gran cantidad de utilidades y servidores que lo acompañan. A medida que el hardware ha mejorado y el software se convierte a una compatibilidad de 64 bits, necesariamente ha habido un retraso considerable para que todas las piezas de este mundo tan grande y complejo funcionen bien con el rápido ritmo de los cambios.

En mi humilde opinión, no hay una única manera de solucionar un problema. La solución es investigar las posibilidades y luego, mediante prueba y error, encontrar lo que funciona mejor para sus necesidades particulares. Cada usuario debe determinar qué funciona para su sistema en lugar de utilizar un enfoque de cortador de cookies.

Por ejemplo, tengo un servidor de medios con algunos archivos muy grandes. El resultado es solo unos 400 archivos que llenan una unidad de 3 TB. Solo se usa el 1% de los inodos, pero se usa el 95% del espacio total. Alguien más, con muchos archivos más pequeños puede quedarse sin inodos antes de que se acerquen a llenar el espacio. (En los sistemas de archivos ext4 como regla general, se usa 1 inodo para cada archivo / directorio). Si bien, en teoría, el número total de archivos que pueden estar contenidos dentro de un directorio es casi infinito, la practicidad determina que el uso general determine unidades realistas, no solo capacidades del sistema de archivos.

Espero que todas las respuestas anteriores hayan promovido el pensamiento y la resolución de problemas en lugar de presentar una barrera insuperable para el progreso.

Recuerdo ejecutar un programa que estaba creando una gran cantidad de archivos en la salida. Los archivos se ordenaron a 30000 por directorio. No recuerdo haber tenido problemas de lectura cuando tuve que reutilizar la salida producida. Estaba en una computadora portátil Ubuntu Linux de 32 bits, e incluso Nautilus mostró el contenido del directorio, aunque después de unos segundos.

Sistema de archivos ext3: un código similar en un sistema de 64 bits funciona bien con 64000 archivos por directorio.

"Depende del sistema de archivos"
Algunos usuarios mencionaron que el impacto en el rendimiento depende del sistema de archivos utilizado. Por supuesto. Los sistemas de archivos como EXT3 pueden ser muy lentos. Pero incluso si se utiliza EXT4 o XFS no se puede impedir que la inclusión de una carpeta a través lso findoa través de una conexión externa como FTP será más lento el más lento.

Solución
Prefiero lo mismo que @armandino . Para eso utilizo esta pequeña función en PHP para convertir ID en una ruta de archivo que da como resultado 1000 archivos por directorio:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

o puede usar la segunda versión si desea usar caracteres alfanuméricos:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

resultados:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Como puede ver en la $intversión-cada carpeta contiene hasta 1000 archivos y hasta 99 directorios que contienen 1000 archivos y 99 directorios ...

¡Pero no olvide que muchos directorios causan los mismos problemas de rendimiento!

Finalmente, debe pensar en cómo reducir la cantidad de archivos en total. Dependiendo de su objetivo, puede usar sprites CSS para combinar múltiples imágenes pequeñas como avatares, iconos, emoticones, etc. o si usa muchos archivos pequeños que no son medios, considere combinarlos, por ejemplo, en formato JSON. En mi caso, tenía miles de mini cachés y finalmente decidí combinarlos en paquetes de 10.

Respeto que esto no responde totalmente a su pregunta sobre cuántos es demasiado, pero una idea para resolver el problema a largo plazo es que, además de almacenar los metadatos del archivo original, también almacena en qué carpeta del disco está almacenado, normalice fuera ese pedazo de metadatos. Una vez que una carpeta crece más allá de algún límite con el que se siente cómodo por su rendimiento, estética o cualquier otra razón, simplemente crea una segunda carpeta y comienza a colocar archivos allí ...

Me encontré con un problema similar. Intenté acceder a un directorio con más de 10,000 archivos. Tardaba demasiado en crear la lista de archivos y ejecutar cualquier tipo de comandos en cualquiera de los archivos.

Pensé en un pequeño script PHP para hacer esto por mí mismo y traté de encontrar una manera de evitar que se agote en el navegador.

El siguiente es el script php que escribí para resolver el problema.

Listado de archivos en un directorio con demasiados archivos para FTP

Cómo ayuda a alguien

No es una respuesta, sino solo algunas sugerencias.

Seleccione un FS (sistema de archivos) más adecuado. Desde un punto de vista histórico, todos sus problemas fueron lo suficientemente sabios como para ser una vez centrales para que los FS evolucionen durante décadas. Me refiero a que los FS más modernos respaldan mejor sus problemas. Primero, haga una tabla de decisión de comparación basada en su propósito final de la lista FS .

Creo que es hora de cambiar tus paradigmas. Por lo tanto, personalmente sugiero usar un sistema distribuido consciente FS , lo que significa que no hay límites en cuanto al tamaño, la cantidad de archivos, etc. De lo contrario, tarde o temprano se enfrentarán a nuevos problemas imprevistos.

No estoy seguro de trabajar, pero si no mencionas algo de experimentación, prueba AUFS sobre tu sistema de archivos actual. Supongo que tiene facilidades para imitar múltiples carpetas como una sola carpeta virtual.

Para superar los límites de hardware, puede usar RAID-0.

No existe una cifra única que sea "demasiada", siempre que no supere los límites del sistema operativo. Sin embargo, cuantos más archivos haya en un directorio, independientemente del sistema operativo, más tardará en acceder a cualquier archivo individual, y en la mayoría de los sistemas operativos, el rendimiento no es lineal, por lo que encontrar un archivo de cada 10,000 toma más de 10 veces más. luego para encontrar un archivo en 1,000.

Los problemas secundarios asociados con tener muchos archivos en un directorio incluyen fallas de expansión de comodines. Para reducir los riesgos, puede considerar ordenar sus directorios por fecha de carga o alguna otra pieza útil de metadatos.