Rendimiento NTFS y grandes volúmenes de archivos y directorios.

¿Cómo funciona Windows con NTFS con grandes volúmenes de archivos y directorios?

¿Hay alguna guía sobre los límites de archivos o directorios que puede colocar en un solo directorio antes de encontrarse con problemas de rendimiento u otros problemas?

Por ejemplo, ¿es correcto tener una carpeta con 100,000 carpetas dentro?

Aquí hay algunos consejos de alguien con un entorno donde tenemos carpetas que contienen decenas de millones de archivos.

1. Una carpeta almacena la información de índice (enlaces a archivos secundarios y carpeta secundaria) en un archivo de índice. Este archivo se hará muy grande cuando tengas muchos hijos. Tenga en cuenta que no distingue entre un elemento secundario que es una carpeta y un elemento secundario que es un archivo. La única diferencia es que el contenido de ese niño es el índice de la carpeta del niño o los datos del archivo del niño. Nota: Estoy simplificando esto un poco, pero esto hace que se entienda.
2. El archivo de índice se fragmentará. Cuando se fragmente demasiado, no podrá agregar archivos a esa carpeta. Esto se debe a que hay un límite en el número de fragmentos permitido. Es por diseño. Lo he confirmado con Microsoft en una llamada de incidente de soporte. Entonces, aunque el límite teórico para la cantidad de archivos que puede tener en una carpeta es de varios miles de millones, buena suerte cuando comience a golpear decenas de millones de archivos, ya que primero alcanzará la limitación de fragmentación.
3. Sin embargo, no todo es malo. Puede usar la herramienta: contig.exe para desfragmentar este índice. No reducirá el tamaño del índice (que puede alcanzar hasta varios Gigs para decenas de millones de archivos), pero puede reducir el número de fragmentos. Nota: La herramienta de Desfragmentación de disco NO desfragmentará el índice de la carpeta. Desfragmentará los datos del archivo. Solo la herramienta contig.exe desfragmentará el índice. FYI: También puede usar eso para desfragmentar los datos de un archivo individual.
4. Si desfragmentas, no esperes hasta alcanzar el número máximo de límite de fragmentos. Tengo una carpeta donde no puedo desfragmentar porque he esperado hasta que sea demasiado tarde. Mi próxima prueba es tratar de mover algunos archivos de esa carpeta a otra carpeta para ver si puedo desfragmentarlo. Si esto falla, entonces lo que tendría que hacer es 1) crear una nueva carpeta. 2) mover un lote de archivos a la nueva carpeta. 3) desfragmentar la nueva carpeta. repita # 2 y # 3 hasta que se haga esto y luego 4) elimine la carpeta anterior y cambie el nombre de la nueva carpeta para que coincida con la anterior.

Para responder a su pregunta más directamente: Si está viendo 100K entradas, no se preocupe. Ve a noquearte. Si está viendo decenas de millones de entradas, entonces:

a) Haga planes para subdividirlos en subcarpetas (por ejemplo, supongamos que tiene 100 millones de archivos. Es mejor almacenarlos en 1000 carpetas para que solo tenga 100,000 archivos por carpeta que almacenarlos en 1 carpeta grande). creará 1000 índices de carpeta en lugar de uno solo grande que sea más probable que alcance el límite máximo de # de fragmentos o

b) Haga planes para ejecutar contig.exe regularmente para mantener el índice de su carpeta grande desfragmentado.

Lea a continuación solo si está aburrido.

El límite real no está en el número de fragmentos, sino en el número de registros del segmento de datos que almacena los punteros al fragmento.

Entonces, lo que tiene es un segmento de datos que almacena punteros a los fragmentos de los datos del directorio. Los datos del directorio almacenan información sobre los subdirectorios y subarchivos que supuestamente almacenó el directorio. En realidad, un directorio no "almacena" nada. Es solo una función de seguimiento y presentación que presenta la ilusión de jerarquía para el usuario, ya que el medio de almacenamiento en sí es lineal.

También hay problemas de rendimiento con la creación de nombres de archivo cortos que ralentizan las cosas. Microsoft recomienda desactivar la creación de nombres de archivo cortos si tiene más de 300k archivos en una carpeta [1]. Cuanto menos únicos son los primeros 6 caracteres, más problemático es este.

[1] Cómo funciona NTFS en http://technet.microsoft.com , busque "300,000"

Estoy creando una estructura de archivos para alojar hasta 2 mil millones (2 ^ 32) de archivos y realicé las siguientes pruebas que muestran una fuerte caída en el rendimiento de navegación + lectura en aproximadamente 250 archivos o 120 directorios por directorio NTFS en una unidad de estado sólido ( SSD):

• El rendimiento del archivo se reduce en un 50% entre 250 y 1000 archivos.
• El rendimiento del directorio cae un 60% entre 120 y 1000 directorios.
• Los valores para Números> 1000 permanecen relativamente estables

Curiosamente, el número de directorios y archivos NO interfiere significativamente.

Entonces las lecciones son:

• Los números de archivo superiores a 250 cuestan un factor de 2
• Los directorios superiores a 120 cuestan un factor de 2.5
• File-Explorer en Windows 7 puede manejar grandes #Files o #Dirs, pero la usabilidad sigue siendo mala.
• Introducir sub-directorios no es costoso

Estos son los datos (2 mediciones para cada archivo y directorio):

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

Y este es el código de prueba:

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}

100,000 deberían estar bien.

He visto (anecdóticamente) a personas que tienen problemas con muchos millones de archivos y yo mismo he tenido problemas con Explorer simplemente porque no tengo idea de cómo contar más de 60 mil archivos, pero NTFS debería ser bueno para los volúmenes que está hablando.

En caso de que se lo pregunte, el número máximo técnico (y espero teórico ) de archivos es: 4,294,967,295

Para el acceso local, un gran número de directorios / archivos no parece ser un problema. Sin embargo, si está accediendo a ella a través de una red, hay un notable rendimiento después de unos pocos cientos (especialmente cuando se accede desde máquinas Vista (XP a Windows Server con NTFS parecía correr mucho más rápido en ese sentido)).

Cuando crea una carpeta con N entradas, crea una lista de N elementos a nivel de sistema de archivos. Esta lista es una estructura de datos compartidos en todo el sistema. Si luego comienza a modificar esta lista continuamente agregando / eliminando entradas, espero al menos cierta contención de bloqueo sobre los datos compartidos. Esta discusión, teóricamente , puede afectar negativamente el rendimiento.

Para escenarios de solo lectura, no puedo imaginar ninguna razón para la degradación del rendimiento de los directorios con una gran cantidad de entradas.

Tenía experiencia real con aproximadamente 100 000 archivos (cada uno de varios MB) en NTFS en un directorio mientras copiaba una biblioteca en línea.

Se tarda unos 15 minutos en abrir el directorio con Explorer o 7-zip.

Copia del sitio de escritura con winhttrack siempre se atascará después de un tiempo. También se ocupó del directorio, que contiene alrededor de 1 000 000 de archivos. Creo que lo peor es que el MFT solo puede atravesarse secuencialmente.

Abrir el mismo bajo ext2fsd en ext3 dio casi el mismo tiempo. Probablemente mudarse a reiserfs (no reiser4fs) puede ayudar.

Intentar evitar esta situación es probablemente lo mejor.

Para sus propios programas que usan blobs sin ningún fs podría ser beneficioso. Así lo hace Facebook para almacenar fotos.