Hugo, no había visto este correo antes de enviar el anterior, lo leo con
calma y te digo.
Saludos.
El 13/11/15 a las 16:37, Hugo Florentino escribió:
On Fri, 13 Nov 2015 09:21:27 -0500, Carlos Cesar Caballero Díaz wrote:
Usar un bufer compartido tiene también sus implicaciones,
especialmente si los hilos de copia son asíncronos[...]
Por ello la decisión fue realizar la copia de forma síncrona, si bien
de forma asíncrona se puede terminar con un disco antes que acabe el
siguiente, al final el tiempo total de la copia no varía, pues el
disco que tarda más igual demorará el mismo tiempo, si es necesario
hacer un backup hacia varios discos, la tarea no finalizaría hasta que
el último disco termine. [...]
Cierto, si los discos son internos. En el caso por ejemplo de un disco
USB3 o hot-swap, sería útil poder expulsarlo una vez terminada la copia.
De todas formas la diferencia en el tiempo de copia de un disco
rápido y uno lento sería mínima, pues habría que almacenar la
diferencia en memoria, en el buffer, el cual aumentaría según aumente
la diferencia de copia de los discos, lo que no se puede permitir,
porque ocuparía toda la ram, y cuando se limite el tamaño del buffer,
pues el disco rápido solo copiaría a su velocidad normal hasta que el
buffer se llene, luego continuaría a la misma velocidad del disco
lento, lo cual le daría una ventaja mínima. O al menos a esa fue la
conclusión que llegamos por aquí. ¿Tienes alguna idea o una conclusión
diferente?
Mi conclusión es la misma, pero de hecho estuve pensando que quizas
podria utilizarse un doble bufer o alguna alternativa.
Por ejemplo: comenzar con un bufer FIFO y cuando algun hilo de copia
haya consumido digamos mas alla de 2/3 de este, habilitar un segundo
buffer de lectura e ir alimentando con este el primer buffer a medida
que el hilo mas lento vayan utilizando bloques lógicos, y si el hilo
de copia rápido sobrepasa la velocidad de alimentación del primer
buffer, pasarlo a tomar directamente los datos del segundo buffer. En
la eventualidad de que el proceso de copia del hilo rápido sea tan
rapida que los dos buffers no puedan sincronizarse, separar las
operaciones de lectura, aunque esto implique dos lecturas, de todas
formas favorecerá la operación de copia que se supone sea el pollo del
arroz con pollo.
[...] ahora mismo con la opción -n (--only-newer-files) hace una copia
incremental, es decir, que copia teniendo en cuenta la fecha de
modificación del fichero, algo así:
Se copia de A hacia B
Si A/1 existe en B/1:
Si fecha de A/1 > fecha de B/1:
Realiza copia A/1 a B/1
Sino:
Realiza copia A/1 a B/1
Quizá agregar algo como:
Se copia de A hacia B
Si A/1 existe en B/1:
Si fecha de A/1 > fecha de B/1:
Realiza copia A/1 a B/1
Sino si (fecha de A/1 == fecha de B/1) Y (tamaño A/1 != tamaño B/1):
Realiza copia A/1 a B/1
Sino:
Realiza copia A/1 a B/1
Creo que con eso se puede solucionar el tema de los ficheros
corruptos, generar un checksum me parece que enlentecería la copia.
Quizas. En mi experiencia práctica, cuando el tamaño del archivo de
origen coincide con el de destino y los archivos también coinciden
digamos en los primeros y últimos n kilobytes, hay grandes
probabilidades de que el resto del archivo también coincida, de modo
que esto podría usarse como un pseudochecksum para acelerar el proceso
de verificación, incluso podria elaborarse un algoritmo de copia
diferencial elemental, por ejemplo (disculpa los corchetes, ):
si A1 existe en B1 {
si tamaño(A1) > n y tamaño(A1) > tamaño(B1) {
si psum(A1 desde 0 hasta posicion(tamaño(B1 - n))) == psum(B1
desde 0 hasta posicion(tamaño(B1 - n))) {
copiar A1 desde posicion(tamaño(B1 - n)) hasta posicion(fin(A1))
en B1 desde posicion(tamaño(B1 - n))
} de lo contrario {
copiar A1 en B1
}
} de lo contrario {
si tamaño(A1) == tamaño(B1) {
si psum(A1) != psum(B1) {
copiar A1 en B1
}
}
}
} de lo contrario, copiar A1 en B1
Igual en caso de archivos de igual tamaño podrian seccionarse los
archivos y hacerles un pseudochechsum a los bloques de la primera y
segunda mitad, o por tercios, etc. Ya que uno ha decidido humanizar y
hacer eficiente el proceso de copias, por que no aprovecharse de la
potencia computacional?
En fin toma mis ideas con una pizca de sal, son solo ideas.
Vamos a hacer lo siguiente, le preguntamos al resto de la lista cual
prefiere, y ponemos ese por defecto y una opción para el otro :)
Por mi bien, ya sabes que personalmente prefiero los tamaños en binario.
Saludos, Hugo
______________________________________________________________________
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
--
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
