fsutil.exe qué tarda menos tiempo para escribir un archivo grande en el disco de programación?

Question

esta pregunta es de acuerdo a este tema: crear un archivo ficticio enorme en cuestión de segundos en c #

Acabo de comprobar el fsutil.exe en XP / Vista / Seven para escribir una gran cantidad de datos ficticios en el disco de almacenamiento y se necesita menos tiempo para escribir un archivo tan grande en comparación con programmaticly manera.

Cuando estoy tratando de hacer lo mismo con la ayuda de .NET que tomará mucho más tiempo que fsutil.exe.

Nota: Sé que no utilizan .NET código nativo debido a que acabo de revisar este tema con API nativa también, como siguiente:

long int size = DiskFree('L' - 64);
const char* full = "fulldisk.dsk";
__try{
Application->ProcessMessages();
HANDLE hf = CreateFile(full,
                       GENERIC_WRITE,
                       0,
                       0,
                       CREATE_ALWAYS,
                       0,
                       0);
SetFilePointer(hf, size, 0, FILE_BEGIN);
SetEndOfFile(hf);
CloseHandle(hf);
}__finally{
    ShowMessage("Finished");
    exit(0);

y la respuesta fue tan iguales como resultados .NET.

pero con la ayuda de fsutil.exe sólo se necesita menos duración que por encima o enfoques .net decir que es 2 veces más rápido

ejemplo: para la escritura de 400MB con .NET que tomará ~ 40 segundos la misma cantidad con fsutil.exe tomará alrededor de 20seg o menos.

¿hay alguna explicación al respecto? o que funcionan fsutil.exe hace uso que tiene esta velocidad importancia de escribir?

Answer 1

No sé exactamente lo que está haciendo fsutil, pero sí sé de dos formas de escribir un archivo de gran tamaño que son más rápidos que lo que ha hecho anteriormente (o la búsqueda a la longitud que desee y escribir un cero, lo cual tiene el mismo resultado).

El problema con estos enfoques es que un relleno con ceros el archivo en el momento que haces la escritura.

Usted puede evitar el relleno de ceros, ya sea:

1. Creación de un archivo disperso. El tamaño está marcado donde lo desee, pero los datos no existe realmente en el disco hasta que lo escriba. Todas las lecturas de las áreas no escritas volverá ceros.
2. Uso de la SetFileValidData función para ajustar la longitud de datos válidos sin reducción a cero del primer archivo. Sin embargo, debido a posibles problemas de seguridad, este comando requiere permisos elevados.

Answer 2

Estoy de acuerdo con el último comentario. Estaba experimentando con un conductor minifiltro y era la captura IRP_MJ_WRITE IRP de devolución de llamada. Al crear o escribir en el fichero de la línea cmd o aplicación Win32, puedo ver las escrituras bajando. Pero cuando he creado un archivo usando "archivo createnew fsutil ..." de comandos, no veo cualquier escritura. Estoy viendo este comportamiento en Win2k8 R2 en volumen NTFS. Y no creo (no estoy seguro al 100%, aunque) es un archivo disperso tampoco. Probablemente es establecer las propiedades del tamaño de MFT sin asignar ninguna agrupación. fsutil hacer comprobar el espacio libre disponible, así que si el tamaño del archivo es más grande que el espacio libre en el disco, se obtiene el error 1.

También encontré FSCTL_GET_RETRIEVAL_POINTERS programa Sening en el archivo y me dieron una medida para todo el tamaño del archivo. Pero creo que está recibiendo todos los datos

Answer 3

Esto es algo que podría ser

• Escrito en ensamblador (velocidad cegamiento Raw)
• Un nativo de C / C ++ código para hacer esto
• Es posible que una llamada al sistema indocumentado hacer esto o algún truco que no se documenta en cualquier lugar.

Los tres puntos anteriores podrían tener un enorme factor importante - cuando se piensa en ello, cuando se carga un código .NET, que se jit'ted por el tiempo de ejecución (Ok, el factor tiempo no sería apreciable si tiene una ultrarrápido máquina -. en un Pentium extremo humilde, sería notable carga, lento)

Lo más probable es que podría haber sido escrito en C / C ++. Puede que te sorprenda si fue escrito en ensamblador.

Esto se puede comprobar por sí mismo - ver el tamaño del archivo ejecutable y compararlo con el ejecutable de un .NET. Se podría argumentar que el archivo está comprimido, lo cual dudo que sería y por lo tanto estar inclinado a descartar esta posibilidad, Microsoft no iría tan lejos Calculo con el negocio ejecutables compresión.

Espero que esto responda a su pregunta, Atentamente, Tom.

Answer 4

fsutil sólo es rápido en NTFS y exFAT, no en FAT32, FAT16 Esto se debe a algún sistema de archivos tiene un concespt "tamaño iniciada" y así apoyar la inicialización rápida de archivos. Esto sólo se reserva a los grupos, pero no cero a cabo, debido a que las notas en el sistema de archivos que ningún dato se escribe en el archivo y lee válida podían regresar el 00 llenas de memorias intermedias.