windows - que - mft español

Rendimiento NTFS y grandes volúmenes de archivos y directorios

Question

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

¿Hay alguna guía sobre los límites de los archivos o directorios que puede colocar en un único directorio antes de tener problemas de rendimiento u otros problemas? por ejemplo, una carpeta con 100.000 carpetas dentro de ella es una buena cosa para hacer

Answer 1

100.000 debería estar bien.

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

En caso de que se lo pregunte, el número máximo de archivos técnicos (y espero que sean teóricos ) es: 4.294.967.295

Answer 2

Aquí hay algunos consejos de alguien con un entorno en el que 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 será muy grande cuando tenga muchos hijos. Tenga en cuenta que no distingue entre un niño que es una carpeta y un niño que es un archivo. La única diferencia realmente 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 de alguna manera, pero esto hace que el tema se transmita.
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 permitidos. Es por diseño. Lo confirmé 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 empiece a tocar decenas de millones de archivos, ya que primero alcanzará la limitación de la 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 por 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 usarlo para desfragmentar los datos de un archivo individual.
4. Si HACE desfragmentación, no espere hasta alcanzar el límite máximo de # de fragmento. Tengo una carpeta donde no puedo desfragmentar porque he esperado hasta que sea demasiado tarde. Mi próxima prueba es intentar mover algunos archivos fuera de esa carpeta a otra carpeta para ver si puedo desfragmentarlos. Si esto falla, entonces lo que tendría que hacer es 1) crear una nueva carpeta. 2) mueva un lote de archivos a la nueva carpeta. 3) defragmente la nueva carpeta. repita # 2 y # 3 hasta que esto esté hecho 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 de manera más directa: si está viendo 100 mil entradas, no se preocupe. Vete a la mierda. Si está viendo decenas de millones de entradas, entonces:

a) Haga planes para subdividirlos en subcarpetas (por ejemplo, digamos que tiene archivos de 100 M. Es mejor almacenarlos en 1000 carpetas para que solo tenga 100.000 archivos por carpeta que almacenarlos en una carpeta grande. creará 1000 índices de carpeta en lugar de uno grande que es más probable que llegue al límite máximo de # de fragmentos o

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

Lea a continuación solo si está aburrido.

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

Entonces, lo que tienes 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 el directorio supuestamente almacenó. 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 al usuario, ya que el medio de almacenamiento en sí es lineal.

Answer 3

Cuando crea una carpeta con N entradas, crea una lista de N elementos en el nivel del 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 alguna contención de bloqueo sobre los datos compartidos. Esta afirmación, teóricamente , puede afectar negativamente el rendimiento.

Para escenarios de solo lectura, no puedo imaginar ningún motivo para la degradación del rendimiento de los directorios con gran cantidad de entradas.

Answer 4

Estoy construyendo una estructura de archivos para alojar hasta 2 mil millones (2 ^ 32) archivos y realicé las siguientes pruebas que muestran una caída brusca en Navigate + Read Performance en aproximadamente 250 archivos o 120 directorios por directorio NTFS en una unidad de estado sólido ( SSD):

• El rendimiento del archivo disminuye en un 50% entre 250 y 1000 archivos.
• El rendimiento del directorio cae en 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
• El File-Explorer en Windows 7 puede manejar #Files o #Dirs grandes, pero la Usabilidad sigue siendo mala.
• La introducción de subdirectorios no es costosa

Estos son los datos (2 medidas 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; 
}

Answer 5

Para el acceso local, una gran cantidad de directorios / archivos no parece ser un problema. Sin embargo, si está accediendo a través de una red, hay un notable desempeño después de unos cientos (especialmente cuando se accede desde máquinas Vista (XP a Windows Server w / NTFS parecía funcionar mucho más rápido en ese sentido)).

Answer 6

También hay problemas de rendimiento con la creación de nombres cortos de archivos que ralentizan las cosas. Microsoft recomienda desactivar la creación de nombre corto de archivo si tiene más de 300k archivos en una carpeta [1]. Cuanto menos únicos sean los primeros 6 caracteres, mayor será el problema.

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

Answer 7

Tenía experiencia real con aproximadamente 100 000 archivos (cada varios mb) en ntfs en un directorio mientras copiaba una biblioteca en línea. Se tarda unos 15 minutos en abrir el directorio con el explorador o 7-zip. La 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 1000 000 archivos. Creo que lo peor es que MFT solo puede atravesarse secuencialmente.

Abrir el mismo en 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, usar blobs sin fs podría ser beneficioso. Esa es la forma en que Facebook hace para almacenar fotos.

Aclamaciones.