¿Cuántos archivos puedo poner en un directorio?


561

¿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.

Respuestas:


736

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 de volumen máximo
    • Implementación: 2 32  - 1 grupos (256 TiB - 64 KiB)
    • Teórico: 2 64  - 1 grupos (1 YiB - 64 KiB)

ext2 :

  • Número máximo de archivos: 10 18
  • Número máximo de archivos por directorio: ~ 1.3 × 10 20 (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 13 , 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 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 de volumen máximo: 2 48  - 1 bytes (256 TiB - 1)

24
Supongo que estos son el número máximo de archivos para toda la partición, no un directorio. Por lo tanto, esta información no es demasiado útil con respecto al problema, porque habría un número igual de archivos independientemente del método (a menos que cuente los directorios como archivos).
extraño

19
Como estamos en 2012 ahora, creo que es hora de dejar en claro que ext4 no tiene ningún límite con respecto al número de subdirectorios. También el tamaño máximo de archivo creció a 16 TB. Además, el tamaño total del sistema de archivos puede ser de hasta 1 EB = 1,048,576 TB.
devsnd

77
Aparentemente, ext3 también tiene un límite de 60,000 archivos (o directorios o enlaces) por directorio. Descubrí el camino difícil sobre esto.
stackular

8
Respuesta anterior, lo sé ... pero cuando escribes EXT4 - Número máximo de archivos: 2³² - 1 (4,294,967,295) y Número máximo de archivos por directorio: ilimitado realmente me confundiste porque 2³² - 1! = "Ilimitado". Supongo que necesito un café ahora. ;) Sin embargo +1
e-sushi

11
los límites del sistema de archivos no responden a la pregunta " ¿Importa cuántos archivos guardo en un solo directorio? "
Etki

191

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.


66
¡LecturA INTERESANTE! ¿Puedo preguntar en qué situación tenía 8 millones de archivos en un directorio? jaja
Aᴄʜᴇʀᴏɴғᴀɪʟ

Yo tuve lo mismo. He migrado la columna de blob de una tabla, cada columna de blob que he exportado como un archivo. Son alrededor de 8 millones de archivos :)
Spike

65

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 .


66
Esta es la única respuesta útil. Hemos hecho experiencias similares. Nuestro límite es de 1.000 archivos para reducir los problemas con las copias de seguridad (también se ralentizan demasiados directorios).
mgutt

1
Puede ser útil montar una unidad con noatime también: howtoforge.com/… y leer esto también: serverfault.com/questions/354017/…
mgutt

2
¿Qué sistema de archivos estás usando donde se ralentiza tanto? XFS, por ejemplo, debería ser capaz de manejar fácilmente 100,000 archivos en un directorio sin una desaceleración notable.
Ethan

1
Contradiciendo la opinión de la mayoría de los demás, quiero confirmar esta respuesta. Tenemos cientos de miles de imágenes en nuestro sitio web de redes sociales. Para mejorar el rendimiento, nos vimos obligados a tener 100 (o 1000 para algunos archivos) subdirectorios y distribuir los archivos en ellos (ext3 en linux + Apache para nosotros).
wmac

57

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.


44
Gnome y KDE cargan directorios grandes a un ritmo muy rápido, Windows almacenará en caché el directorio, por lo que es razonable. Me encanta Linux, pero kde y gnome están mal escritos.
torre el

1
Y ext4 parece tener el equivalente de dir_index por defecto.
contrato del Prof. Falken incumplió

22
Hay un límite de alrededor de 32K subdirectorios en un directorio en ext3, pero el OP está hablando de archivos de imagen. No hay límite (¿práctico?) En los archivos en un sistema de archivos ext3 con el índice Dir habilitado.
Peter N Lewis

1
Esta respuesta está desactualizada, hoy en día el valor predeterminado es ext4 .
Boris

1
"No hay límite (¿práctico?) En los archivos en un sistema de archivos ext3 con el índice Dir habilitado" - Acabo de quedarme sin espacio de archivos en un directorio en un sistema de archivos ext4 de 4TB, con dir_indexhabilitado. Tenía unos 17 millones de archivos en el directorio. La respuesta fue encender large_dircon tune2fs.
lunixbochs

49

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

33
@ Steve, use find (1) y / o xargs (1) para estos casos. Por la misma razón, es una buena idea usar tales herramientas en los scripts en lugar de la expansión de la línea de comandos.
Dave C

3
@ Steve, ¿ves que el rendimiento baja cuando aumenta el número de archivos en una carpeta? ¿O no hay relación?
Pacerier

66
Este es un buen punto, pero para dar una paliza, la razón dada es incorrecta. La lista de argumentos demasiado larga es una limitación no del shell, sino de la execimplementación del sistema . El shell normalmente puede expandir el comodín muy bien: es la llamada a exectantos argumentos lo que devuelve el error.
jw013

Tuve el mismo error anoche (Fedora 15) con "rm" (algunos archivos *) con aproximadamente ~ 400,000 archivos en un directorio. Pude recortar los archivos más antiguos con "buscar" hasta el punto en que podía "rm" con un comodín.
PJ Brunet

10,000,000 archivos a un directorio en etx4 funciona bien. No hay mucho éxito en el rendimiento al acceder. Pero bastante lento con comodín. ¡Tenga cuidado al usar programas de shell que le gusta ordenar nombres de archivos! :)
Simon Rigét

25

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.


1
Esta es una buena solución. Cada nivel de su directorio hasta el archivo tendría como máximo 100 entradas si se queda con el desglose de 2 dígitos, y el directorio más inferior solo tendría 1 archivo.
RobKohr

Implementación de PHP: stackoverflow.com/a/29707920/318765
mgutt

21

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.


que tipo de archivos ? texto o imágenes que estoy en ext4 y tienen que importar 80000 imágenes en un único directorio en wordpress y me gustaría saber si va a estar bien
Yvon Huynh

1
@YvonHuynh: el tipo de archivo es completamente irrelevante. La sobrecarga en el directorio de listado / seguimiento del archivo es la misma independientemente.
TJ Crowder

14

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.


9

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:

punto de referencia

Escribió un artículo .


Un enlace a una solución es bienvenido, pero asegúrese de que su respuesta sea útil sin él: agregue contexto alrededor del enlace para que sus otros usuarios tengan una idea de qué es y por qué está allí, luego cite la parte más relevante de la página volver a vincular en caso de que la página de destino no esté disponible. Se pueden eliminar las respuestas que son poco más que un enlace.
Samuel Liew

1
Interesante. Descubrimos que incluso después de 10,000 archivos, el rendimiento se degradó muy rápidamente hasta el punto de ser inutilizable. Resolvimos dividir los archivos en subdirectorios de aproximadamente 100 en cada nivel para lograr un rendimiento óptimo. Supongo que la moraleja de la historia es siempre compararla en sus propios sistemas con sus propios requisitos.
Joshua Pinter

7

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.


66
Publico anuncios contra particiones por fecha porque las importaciones masivas pueden agrupar archivos en una fecha determinada.
max

Un buen punto Definitivamente, debe considerar sus casos de uso antes de elegir un esquema de partición. Importo fotos durante muchos días en una distribución relativamente amplia, Y cuando quiero manipular las fotos fuera de la fecha F-Spot es la forma más fácil de encontrarlas, por lo que es una doble victoria para mí.
Sparr

7

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.


7

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.


66
Si los nombres de los archivos fueran completamente aleatorios, no importaría qué dígitos se usaran.
extraño

De hecho, estos nombres de archivo se generan aleatoriamente.
Kip

2
O use los primeros N bytes del resumen SHA-1 del nombre del archivo.
gawi

6

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/cwelug@googlegroups.com/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.


5

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.


5

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.


4

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.


4

"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.


3

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í ...


3

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


1

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.