Como pregunta anterior, ¿7zip (más específicamente p7zip en Linux) utiliza espacio en disco al probar archivos? Como solo tengo una unidad de 2 TB para trabajar y cada archivo tiene un tamaño de entre 800 GB y 1 TB, estaba pensando en probar 2 archivos al mismo tiempo en lugar de solo uno.
La documentación oficial de 7zip no menciona el uso del disco durante las pruebas.
Respuesta1
No debería. (Pero podría)
Para verificar que los datos de un archivo sean correctos al extraerlos, cada archivo o bloque de datos tendrá un CRC o código de detección de errores asociado.
Al descomprimir un archivo tiene mucho sentido, desde una perspectiva de eficiencia, realizar la verificación de errores.antesescribir datos en el disco. De lo contrario, estará desperdiciando valiosos recursos leyendo el archivo, escribiéndolo en el disco y luego volviendo a leer los datos en el disco para realizar una verificación de errores. Con un archivo grande o en un sistema con memoria limitada, esto podría duplicar el tiempo necesario para descomprimir un archivo, lo que sería inaceptable. Supongo en este caso que la lectura y escritura en disco son la parte más lenta del proceso.
Si realiza la verificación antes de escribir, puede transmitir efectivamente el archivo a través del descompresor, a través de su algoritmo de verificación de errores, luego enviarlo al disco y asumir que el subsistema del disco sabe lo que está haciendo. Trabajo hecho.
Al hacerlo de esta manera, "probar" el archivo se convierte en una operación gratuita. Sigue exactamente los mismos pasos que seguiría para la descompresión, pero simplemente desecha los datos sin escribirlos en el disco.
Espero firmemente que así sea como funciona, porque escribir todo en el disco simplemente para probar un archivo parece una locura y no sería más rápido que una descompresión "real" de los datos. Que la "prueba" sea más rápida implica que se omite al menos un paso, muy probablemente escribir datos en el disco.
Respuesta2
No, no es así, al menos no en la versión 19.00.
Probar varios archivos en paralelo funciona muy bien en unidades de estado sólido, pero generalmente reduce el rendimiento en unidades mecánicas; entonces, se requiere mucha búsqueda para leer varios archivos en paralelo. Así, se puede hacer la siguiente recomendación:
Cuando pruebe archivos en unidades de estado sólido (NVMe o SATA SSD), inicie tantos procesos como núcleos tenga (si puede).
Al probar archivos en la misma unidad mecánica (o volumen RAID mecánico), inicie uno o como máximo dos procesos.
Al probar archivos en unidades USB, los resultados variarán.
La triste mayoría de los "pendrives" o "sticks" USB comunes son abismalmente lentos, incluso durante la lectura, es decir, lejos de saturar el ancho de banda de la interfaz USB. Algunas de estas unidades se vuelven aún más lentas cuando acceden a datos desde varias áreas distintas de la unidad al mismo tiempo. Esto se debe a la RAM limitada en el controlador de disco. El controlador no puede incluir todos los metadatos necesarios para acceder a la totalidad de la unidad en la RAM a la vez y terminará releyendo los metadatos del medio flash a medida que cambia las áreas de lectura en la unidad, teniendo que a menudo seguir cadenas de enlaces para Encuéntralo. Estas lecturas de metadatos a menudo no son paralelizadas por la unidad, incluso si el diseño de la memoria flash lo permitiera, y a menudo también se implementan utilizando rutas de código dedicadas que son simplemente lentas.
La única forma segura de solucionarlo es realizar una prueba de ancho de banda. Supongamos que tiene que verificar los archivos a, b, c, y , todos aproximadamente en el mismo orden de magnitud den cuanto a tamaño. Deben ordenarse de forma descendente por tamaño. Primero, cronometre la verificación y calcule el ancho de banda . Luego haga la verificación de y en paralelo y calcule esos anchos de banda. Siempre que su suma sea mayor que , estarás ganando rendimiento. Luego verifique y , en paralelo, calcule esos anchos de banda. Siempre que su suma sea mayor que , estarás ganando rendimiento. Etcétera. Con el tiempo, alcanzará la cantidad de transmisiones en las que el ancho de banda total disminuye en comparación con la prueba anterior. Continúen verificando los archivos restantes utilizando el número menor de secuencias anteriores.efaBW_a = time_a / size_abcsum_BW_bcBW_adefsum_BW_defsum_BW_bc
Este método se puede aplicar a cualquier unidad, aunque la caída del rendimiento en las unidades mecánicas es tan pronunciada que puede afectar indebidamente el rendimiento general de su proceso de verificación. Por eso, las pruebas paralelas deben finalizar cuando se sepa que su ancho de banda es inferior al 90% del ancho de banda del paso anterior. Puede hacerlo volviendo a calcular el ancho de banda cada segundo que se ejecuta la prueba y finalizando la prueba cuando el ancho de banda esté por debajo del punto de corte.