filesystems - ¿Cuántos archivos puedo poner en un directorio?
limit (20)
FAT32 :
- Número máximo de archivos: 268,173,300
- Número máximo de archivos por directorio: 2 16 - 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 32 - 1 (4,294,967,295)
- Tamaño máximo de archivo
- Implementación: 2 44 - 2 6 bytes (16 TiB - 64 KiB)
- Teórico: 2 64 - 2 6 bytes (16 EiB - 64 KiB)
- Tamaño máximo del volumen
- Implementación: 2 32 - 1 grupos (256 TiB - 64 KiB)
- Teórico: 2 64 - 1 agrupaciones
ext2 :
- Número máximo de archivos: 10 18
- Número máximo de archivos por directorio: ~ 1.3 × 10 20 (problemas de rendimiento pasados de 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 máximo del volumen
- 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 13 , numberOfBlocks)
- Tamaño máximo de archivo: igual que ext2
- Tamaño máximo de volumen: igual que ext2
ext4 :
- Número máximo de archivos: 2 32 - 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 máximo de volumen: 2 48 - 1 bytes (256 TiB - 1)
¿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 es 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 cualquier metadata útil 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 lista de archivos en el directorio (a través de un cliente FTP o SSH) tarde unos segundos. Pero no puedo ver que tenga otro efecto aparte de eso. En particular, no parece haber ningún impacto en la rapidez con la que se entrega 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.
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 simplemente 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 cometan errores y hagan una clasificación O (n ^ 2), por lo que, para estar seguro, siempre limitaré la cantidad de archivos por archivo. Directorio a no más de 500.
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 mencionaste, 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 recordarlo definitivamente trabajando hasta 32000 archivos.
El mayor problema que he encontrado es en un sistema de 32 bits. Una vez que pasa un cierto número, las herramientas como ''ls'' dejan de funcionar.
Tratar de hacer algo con ese directorio una vez que pase esa barrera se convierte en un gran problema.
Estoy trabajando en un problema similar en este momento. Tenemos una estructura de directorios jerárquica y utilizamos identificadores de imagen como nombres de archivo. Por ejemplo, una imagen con id=1234567 se coloca en
..../45/67/1234567_<...>.jpg
usando los últimos 4 dígitos para determinar dónde va el archivo.
Con unos pocos miles de imágenes, podría utilizar una jerarquía de un nivel. Nuestro administrador de sistemas sugirió no más de un par de miles de archivos en un directorio determinado (ext3) por razones de eficiencia / respaldo / cualquier otra razón que tuviera en mente.
La pregunta se reduce a lo que vas a hacer con los archivos.
Bajo Windows, cualquier directorio con más de 2k archivos tiende a abrirse lentamente para mí en Explorer. Si todos son archivos de imagen, más de 1k tienden a abrirse muy lentamente en la vista en miniatura.
En un momento dado, el límite impuesto por el sistema era de 32,767. Es más alto ahora, pero incluso eso es demasiados archivos para manejar al mismo tiempo en la mayoría de las circunstancias.
Lo que la mayoría de las respuestas anteriores no pueden mostrar es que no hay una respuesta de "Una talla 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 de 64 bits, algunos son de vanguardia y otros son probados y verdaderos: confiables y nunca cambian. A esto se añade 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 funcionan. A medida que el hardware ha mejorado y el software se ha convertido a una compatibilidad de 64 bits, necesariamente ha habido un retraso considerable para que todas las piezas de este mundo tan grande y complejo jueguen bien con el rápido ritmo de los cambios.
En mi humilde opinión no hay una sola manera de solucionar un problema. La solución es investigar las posibilidades y luego, por prueba y error, encontrar qué funciona mejor para sus necesidades particulares. Cada usuario debe determinar qué funciona para su sistema en lugar de utilizar un enfoque de corte de cookies.
Por ejemplo, tengo un servidor de medios con unos pocos archivos muy grandes. El resultado es solo unos 400 archivos que llenan una unidad de 3 TB. Solo se utiliza el 1% de los inodos, pero se utiliza el 95% del espacio total. Alguien más, con una gran cantidad de 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 utiliza 1 inodo para cada archivo / directorio). Si bien teóricamente el número total de archivos que pueden estar contenidos en un directorio es casi infinito, la practicidad determina que el uso general determina las unidades realistas, no sólo capacidades del sistema de archivos.
Espero que todas las diferentes respuestas anteriores hayan promovido el pensamiento y la resolución de problemas en lugar de presentar una barrera insuperable para el progreso.
Me encontré con un problema similar. Estaba tratando de acceder a un directorio con más de 10,000 archivos. Tomó demasiado tiempo construir la lista de archivos y ejecutar cualquier tipo de comandos en cualquiera de los archivos.
Pensé en un pequeño script de PHP para hacer esto por mí mismo y traté de encontrar una manera de evitar que se agote el tiempo de espera 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
Como ayuda a alguien
No es una respuesta, 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 que una vez fueran fundamentales para la evolución de los FS durante décadas. Me refiero a que los servicios de FS más modernos apoyen mejor tus problemas. Primero haga una tabla de decisiones de comparación basada en su propósito final de la lista de FS .
Creo que es hora de cambiar tus paradigmas. Por lo tanto, personalmente sugiero el uso de un sistema distribuido FS , lo que significa que no hay límites en lo que respecta al tamaño, la cantidad de archivos, etc. De lo contrario, tarde o temprano se enfrentará a nuevos problemas imprevistos.
No estoy seguro de que funcione, pero si no menciona algo de experimentación, pruebe AUFS sobre su 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 utilizar RAID-0.
No hay 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 tiempo tomará acceder a un archivo individual y, en la mayoría de los sistemas operativos, el rendimiento no será lineal, por lo que encontrar un archivo de cada 10,000 tomará más de 10 veces más entonces 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 algún otro metadato útil.
Para lo que vale, acabo de crear un directorio en un sistema de archivos ext4 con 1,000,000 de archivos, luego accedí al azar a esos archivos a través de un servidor web. No noté ninguna prima al acceder a aquellos que tienen (por ejemplo) solo tener 10 archivos allí.
Esto es radicalmente diferente de mi experiencia haciendo esto en ntfs hace unos años.
Prefiero lo mismo que @armandino . Para eso utilizo esta pequeña función en PHP para convertir IDs 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 puedes usar la segunda versión si quieres usar un alfanumérico:
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 para la versión $int cada carpeta contiene hasta 1000 archivos y hasta 99 directorios que contienen 1000 archivos y 99 directorios ...
Pero no olvide que muchos directorios pueden acelerar su proceso de copia de seguridad. Siéntase libre de probar de 1000 a 10000 archivos por directorio, pero no agregue mucho más, ya que tendrá un tiempo de acceso muy largo si desea leer el archivo de directorio por archivo (clientes ftp, funciones de lectura de archivos, etc.).
Finalmente debes pensar en cómo reducir la cantidad de archivos en total. Dependiendo de su objetivo, puede usar sprites CSS para combinar varias imágenes pequeñas como avatares, íconos, caritas, etc. o si usa muchos archivos pequeños que no son de medios, considere combinarlos, por ejemplo, en formato JSON. En mi caso tuve miles de mini-caches y finalmente decidí combinarlos en paquetes de 10.
Realmente depende del sistema de archivos utilizado, y también de algunas banderas.
Por ejemplo, ext3 puede tener muchos miles de archivos; pero después de un par de miles, solía ser muy lento. Principalmente al listar un directorio, pero también al abrir un solo archivo. Hace unos años, ganó la opción ''htree'', que redujo drásticamente el tiempo necesario para obtener un inodo dado un nombre de archivo.
Personalmente, uso los 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 obtenga la carga equilibrada.
Recuerdo haber ejecutado un programa que estaba creando una gran cantidad de archivos en la salida. Los archivos fueron ordenados 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: código similar en un sistema de 64 bits se manejó bien con 64000 archivos por directorio.
Respeto esto, no respondo totalmente a su pregunta sobre cuántos son demasiados, 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 - normalizar fuera esa pieza de metadatos. Una vez que una carpeta crece más allá de algún límite con el que se sienta cómodo por su rendimiento, estética o por cualquier motivo, simplemente cree una segunda carpeta y comience a colocar archivos allí ...
Si el tiempo necesario para implementar un esquema de partición de directorio es mínimo, estoy a favor de ello. La primera vez que tenga que depurar un problema que involucre la manipulación de un directorio de 10000 archivos a través de la consola, lo comprenderá.
Como ejemplo, F-Spot almacena archivos de fotos como YYYY / MM / DD / filename.ext, lo que significa que el directorio más grande con el que tuve que lidiar mientras manipulaba manualmente mi colección de ~ 20000 fotos es de aproximadamente 800 archivos. Esto también hace que los archivos sean más fáciles de navegar desde una aplicación de terceros. Nunca asuma que su software es lo único que accederá a los archivos de su software.
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. Mientras que 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
Tengo un directorio con 88,914 archivos en él. Al igual que usted, esto se utiliza 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 de rendimiento en la visualización del 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 unos 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 en el directorio, que no usará en una carpeta de pulgar, solo muestra los archivos de forma estática, pero estará interesado en el rendimiento de cómo se pueden usar los archivos. .
ext3, de hecho, 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 archivos". Específicamente, el tamaño del directorio en sí no puede crecer más allá de un b-tree de altura 3, y el fanout del árbol depende del tamaño del bloque. Vea este enlace para algunos detalles.
https://www.mail-archive.com/[email protected]/msg01944.html
Me ha mordido esto recientemente en un sistema de archivos formateado con bloques 2K, que inexplicablemente recibía mensajes de kernel llenos en el directorio de 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.
He tenido más de 8 millones de archivos en un solo directorio ext3. libc readdir() utilizado por find , ls y la mayoría de los otros métodos descritos en este hilo para enumerar directorios grandes.
La razón por la que ls y find son lentos en este caso es que readdir() solo lee 32K de entradas de directorio a la vez, por lo que en discos lentos se necesitarán 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: use getdents() directamente - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html lugar de cualquier cosa que esté basada en libc readdir() para que pueda especificar el tamaño del búfer al leer las entradas de directorio del disco.