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.