Como mencioné en el correo aun queda trabajo por hacer...
No veo que la función get_block_size se esté usando en ninguna parte.
Por otra parte, el módulo os.statvfs está marcado para obsolescencia
(deprecated) desde la python 2.6 y de hecho lo quitaron de la versión
3, no sería mejor sustituirlo con algo mas reciente?
La función no se usa, inicialmente intenté hacer una optimización
teniendo en cuenta el tamaño de bloque del HDD, pero resulta que python
se encarga de ello (y el SO y el firmware de los HDD) así que en
realidad solo es necesario definir el tamaño del buffer de memoria, y
para ello no hace falta tener en cuenta el tamaño de bloque. Aún esta el
código por si es necesario hacer algunas pruebas, pero de momento no se
usa, en caso de ser necesario, le voy a buscar un reemplazo a os.statvfs.
Aparte de utilizar threads y un buffer de 16M para los datos a copiar,
utilizas algun otro criterio de optimización?
El principal criterio de optimización es la filosofía de "lee una vez y
escribe a todos", los hilos se utilizan para intentar escribir al mismo
tiempo en distintos dispositivos, inicialmente utilizaba
multiprocessing, para aprovechar los procesadores con múltiples núcleos,
que es lo normal hoy en día, pero resulta que hay algún problema extraño
con la GIL y cuando se le agrega una GUI con Qt se enlentece demasiado,
cosa que no ocurre con los hilos, el lado bueno es que no hay
diferencias de rendimiento entre multiprocessing y threads en cuanto a
IO debido a que el cuello de botella es la lectura y escritura en si.
El tamaño del buffer de memoria es algo en lo que estoy trabajando (el
algoritmo para definir el tamaño), de momento tiene un valor por defecto
y una opción para modificarlo.
Los principales factores a tener en cuenta en el tamaño del buffer de
memoria son principalmente: la cantidad de memoria RAM libre, el tamaño
del fichero a copiar, el tamaño del buffer del sistema de ficheros, y el
tamaño del buffer del dispositivo, pero digo principalmente, porque hay
muchos mas, que incluso cambian en el mismo sistema... pero bueno, se
puede lograr un valor aceptable haciendo unas pruebas escribiendo a un
fichero temporal, el problema viene cuando se va a escribir a distintos
HDD que pueden tener sistemas de ficheros distintos y tamaños distintos
del buffer de escritura, así es un poco mas complicado determinar un
buen valor.
De momento la optimización real esta en la función copy_file, la cual
lee de la fuente y copia al mismo tiempo hacia los destinos, el tamaño
del buffer de 16x1024x1024 es un tamaño considerado bueno para la
mayoría de los dispositivos que se usan hoy en día, pero se puede mejorar.
Por cierto, yo actualizaría las unidades de medida para que realmente
representaran multiplos de 1024:
suffixes=['B','KiB','MiB','GiB','TiB']
Si, o pasar a usar 1000 como casi todo el mundo... que crees mejor?
Esa función aún no se esta usando, al igual que la medición del
progreso, es que el poner una barra de progreso enlentece
considerablemente la copia, y el objetivo principal es la velocidad, la
idea es incluir una opción para mostrar el progreso, pero opcional, o
mostrarlo fichero a fichero, o cada un numero determinado de iteraciones.
Saludos.
--
Este mensaje le ha llegado mediante el servicio de correo electronico que
ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
Nacional de Salud. La persona que envia este correo asume el compromiso de usar
el servicio a tales fines y cumplir con las regulaciones establecidas
Infomed: http://www.sld.cu/
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
