Discussion:
Copiar mas rápido hacia múltiples destinos
(too old to reply)
Carlos Cesar Caballero Díaz
2015-11-06 12:29:10 UTC
Permalink
Hola Lista, primero quiero comentarles que estoy muy contento por volver
a estar en contacto luego de un tiempo fuera por problemas técnicos...

Bueno, al pollo del arroz con pollo, hemos estado trabajando en una
herramienta que permita hacer copias hacia muchos destinos de forma
eficiente, la cual podría ser de utilidad a la hora de realizar backups
hacia varios dispositivos de almacenamiento, o cuando simplemente
queremos copiar la misma información hacia varios HDD, se llama multicp
y pueden encontrarla ak: https://github.com/daxslab/multicp es necesario
pulirla bien, por lo que aún le faltan varias líneas de código, pero las
pruebas realizadas hasta ahora son bastante alentadoras, básicamente se
puede copiar hacia varios HDD en el mismo tiempo que si se copiara hacia
uno solo.

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/
Alberto José García Fumero
2015-11-07 14:41:54 UTC
Permalink
El vie, 06-11-2015 a las 07:29 -0500, Carlos Cesar Caballero Díaz
escribió:
> Hola Lista, primero quiero comentarles que estoy muy contento por volver
> a estar en contacto luego de un tiempo fuera por problemas técnicos...
>
> Bueno, al pollo del arroz con pollo, hemos estado trabajando en una
> herramienta que permita hacer copias hacia muchos destinos de forma
> eficiente, la cual podría ser de utilidad a la hora de realizar backups
> hacia varios dispositivos de almacenamiento, o cuando simplemente
> queremos copiar la misma información hacia varios HDD, se llama multicp
> y pueden encontrarla ak: https://github.com/daxslab/multicp es necesario
> pulirla bien, por lo que aún le faltan varias líneas de código, pero las
> pruebas realizadas hasta ahora son bastante alentadoras, básicamente se
> puede copiar hacia varios HDD en el mismo tiempo que si se copiara hacia
> uno solo.
>
> Saludos.

Está interesante ese software!

¿Podrás ponerla en algún momento en un sitio de alcance nacional?
--
M.Sc. Alberto García Fumero
Usuario Linux 97 138, registrado 10/12/1998
http://interese.cubava.cu
Una conclusión es el punto en que usted se cansó de pensar.
Carlos Cesar Caballero Díaz
2015-11-08 00:44:34 UTC
Permalink
Tengo un blog de cubava al que le hace falta un poco de cariño... en
cuanto tenga un tiempo lo cuelgo ahí y les digo.

Ahh se me olvido aclarar que la herramienta es de linea de comandos...

Saludos.

El 07/11/15 a las 09:41, Alberto José García Fumero escribió:
> El vie, 06-11-2015 a las 07:29 -0500, Carlos Cesar Caballero Díaz
> escribió:
>> Hola Lista, primero quiero comentarles que estoy muy contento por volver
>> a estar en contacto luego de un tiempo fuera por problemas técnicos...
>>
>> Bueno, al pollo del arroz con pollo, hemos estado trabajando en una
>> herramienta que permita hacer copias hacia muchos destinos de forma
>> eficiente, la cual podría ser de utilidad a la hora de realizar backups
>> hacia varios dispositivos de almacenamiento, o cuando simplemente
>> queremos copiar la misma información hacia varios HDD, se llama multicp
>> y pueden encontrarla ak: https://github.com/daxslab/multicp es necesario
>> pulirla bien, por lo que aún le faltan varias líneas de código, pero las
>> pruebas realizadas hasta ahora son bastante alentadoras, básicamente se
>> puede copiar hacia varios HDD en el mismo tiempo que si se copiara hacia
>> uno solo.
>>
>> Saludos.
> Está interesante ese software!
>
> ¿Podrás ponerla en algún momento en un sitio de alcance nacional?


--
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/
låzaro
2015-11-14 19:51:53 UTC
Permalink
Thread name: "Re: [Gutl-l] Copiar mas rápido hacia múltiples destinos"
Mail number: 5
Date: Thu, Nov 12, 2015
In reply to: Arian Molina Aguilera
>
> El 12/11/15 a las 12:28, låzaro escribió:
> >para nada, por eso no me gusta :D no hay como el mc
> >
> >doublecmd está escrito en Lazarus (Deplhi o Pascal, para linux) raras
> >veces ves algo que salga de esa herramienta y que no sea visual
> >
> ha que bien hay que echarle el ojo a ver que tal esta. salu2.

yo realmente nunca he entendido como la gente se pone a copiar con
file-managers de un solo panel.

Que además, carecen de una gestor de copias DECENTE.

Me imagino que por eso los windowseros usan supercopier y todas esas
pajarerías

Esos manejadores de archivos con un solo panel y donde los archivos se
ven grandes; en cuadrícula, tu no sabes cual es el primero o el
último. Tienes que meter los ojos debajo del ícono para ver la parte
de alante del nombre. Entonces pones la vista de detalles y le siguen
faltando "detalles".

Eso sin contar lo mencionado en el párrafo anterior

y gracias que ahora le pusieron pestañitas pa tener más de una
localización abierta a la vez


--
-------- Warning! ------------
100'000 pelos de escoba fueron
introducidos satisfactoriamente
en su puerto USB.
Alex Vergara Gil
2015-11-17 17:29:10 UTC
Permalink
te hice un pull request, revisa el git
saludos
Alex Vergara

El 14/11/15, låzaro <***@hcg.sld.cu> escribió:
>
>
> Thread name: "Re: [Gutl-l] Copiar mas rápido hacia múltiples destinos"
> Mail number: 5
> Date: Thu, Nov 12, 2015
> In reply to: Arian Molina Aguilera
>>
>> El 12/11/15 a las 12:28, låzaro escribió:
>> >para nada, por eso no me gusta :D no hay como el mc
>> >
>> >doublecmd está escrito en Lazarus (Deplhi o Pascal, para linux) raras
>> >veces ves algo que salga de esa herramienta y que no sea visual
>> >
>> ha que bien hay que echarle el ojo a ver que tal esta. salu2.
>
> yo realmente nunca he entendido como la gente se pone a copiar con
> file-managers de un solo panel.
>
> Que además, carecen de una gestor de copias DECENTE.
>
> Me imagino que por eso los windowseros usan supercopier y todas esas
> pajarerías
>
> Esos manejadores de archivos con un solo panel y donde los archivos se
> ven grandes; en cuadrícula, tu no sabes cual es el primero o el
> último. Tienes que meter los ojos debajo del ícono para ver la parte
> de alante del nombre. Entonces pones la vista de detalles y le siguen
> faltando "detalles".
>
> Eso sin contar lo mencionado en el párrafo anterior
>
> y gracias que ahora le pusieron pestañitas pa tener más de una
> localización abierta a la vez
>
>
> --
> -------- Warning! ------------
> 100'000 pelos de escoba fueron
> introducidos satisfactoriamente
> en su puerto USB.
>
>
> ______________________________________________________________________
> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
> Gutl-***@jovenclub.cu
> https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
>
Carlos Cesar Caballero Díaz
2015-11-19 02:28:20 UTC
Permalink
Muchas gracias, ahora mismo estoy movilizado por las FAR, así que
malamente tengo tiempo para revisar el correo cada varios días...
después del 28 lo miro y continuamos el hilo.

Saludos.

El 17/11/15 a las 12:29, Alex Vergara Gil escribió:
> te hice un pull request, revisa el git
> saludos
> Alex Vergara
>
> El 14/11/15, låzaro <***@hcg.sld.cu> escribió:
>>
>> Thread name: "Re: [Gutl-l] Copiar mas rápido hacia múltiples destinos"
>> Mail number: 5
>> Date: Thu, Nov 12, 2015
>> In reply to: Arian Molina Aguilera
>>> El 12/11/15 a las 12:28, låzaro escribió:
>>>> para nada, por eso no me gusta :D no hay como el mc
>>>>
>>>> doublecmd está escrito en Lazarus (Deplhi o Pascal, para linux) raras
>>>> veces ves algo que salga de esa herramienta y que no sea visual
>>>>
>>> ha que bien hay que echarle el ojo a ver que tal esta. salu2.
>> yo realmente nunca he entendido como la gente se pone a copiar con
>> file-managers de un solo panel.
>>
>> Que además, carecen de una gestor de copias DECENTE.
>>
>> Me imagino que por eso los windowseros usan supercopier y todas esas
>> pajarerías
>>
>> Esos manejadores de archivos con un solo panel y donde los archivos se
>> ven grandes; en cuadrícula, tu no sabes cual es el primero o el
>> último. Tienes que meter los ojos debajo del ícono para ver la parte
>> de alante del nombre. Entonces pones la vista de detalles y le siguen
>> faltando "detalles".
>>
>> Eso sin contar lo mencionado en el párrafo anterior
>>
>> y gracias que ahora le pusieron pestañitas pa tener más de una
>> localización abierta a la vez
>>
>>
>> --
>> -------- Warning! ------------
>> 100'000 pelos de escoba fueron
>> introducidos satisfactoriamente
>> en su puerto USB.
>>
>>
>> ______________________________________________________________________
>> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
>> Gutl-***@jovenclub.cu
>> https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
>>
>
> ______________________________________________________________________
> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
> Gutl-***@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/
Carlos Cesar Caballero Díaz
2015-12-01 15:23:15 UTC
Permalink
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-***@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/
Carlos Cesar Caballero Díaz
2015-12-01 15:18:35 UTC
Permalink
Hola Hugo, estoy otra vez en linea, puse los cambios de la unidad de
medida y ahora si ocurre un fallo en la copia, y algún fichero queda
corrupto (hay diferencias en su tamaño), al reanudar la copia lo
reemplazará, realizar un checksum me parece muy lento, y creo que con el
tamaño funciona.

Saludos.


El 12/11/15 a las 20:43, Hugo Florentino escribió:
> On Thu, 12 Nov 2015 13:20:57 -0500, Carlos Cesar Caballero Díaz wrote:
>> El principal criterio de optimización es la filosofía de "lee una vez
>> y escribe a todos" [...]
>
> Usar un bufer compartido tiene también sus implicaciones,
> especialmente si los hilos de copia son asíncronos.
>
> Supongamos que en un disco de estado sólido tenemos un archivo de 20
> GiB que deseamos copiar simultáneamente a dos destinos: otro disco de
> estado sólido y un disco SATA1 de 5400 rpm. La diferencia de
> velocidades de escritura entre ambos destinos (y por tanto entre hilos
> de copia) debería ser notable.
>
> Que sucederá cuando el hilo de copia hacia el SSD llegue al final del
> buffer?
>
> - Si se renueva completamente el contenido del buffer, la copia hacia
> el disco lento podría corromperse.
> - Si se espera a que el buffer no este usado para renovar su
> contenido, se ralentizará la copia hacia el disco rápido.
> - Si se amplía el buffer o crea uno nuevo, se sobrepasará el tamaño de
> memoria asignado para la aplicación.
>
> Creo que para mitigar un poco el problema podría intentarse usar algo
> asi como un buffer circular de tamaño variable, pero esto es solo un
> idea, realmente ignoro como hacer algo asi en python, y de todas
> formas mientras mayor sea la cantidad de datos a copiar (por ejemplo
> si queremos copiar un repo completo), mas probabilidades habra de que
> eventualmente los problemas anteriormente mencionados ocurran de todas
> formas.
>
> Si los hilos de copia son sincrónicos, entonces el problema es que
> básicamente se estará limitando la velocidad de copia a la del
> dispositivo de destino más lento, que no es lo más eficiente.
>
> En fin, esto son solo consideraciones que se me han ocurrido al pensar
> en la arquitectura de la aplicación.
>
> Otras cosas que conviene tomar en consideración son la tolerancia a
> fallos (por ejemplo que ocurriría si se va la luz en medio de una
> operación de copia), o si se permitirá la reanudación de una copia
> incompleta (idealmente ignorando los archivos identicos mediante algun
> tipo de checksum), etc.
>
> En cuando al tipo de unidad de medida, personalmente prefiero binario,
> pero hay quien prefiere decimal, de modo que quizas seria bueno
> dejarlo en binario por defecto (que es como lo tienes ahora) con la
> opción de usar el sistema decimal.
>
> Saludos, Hugo
>
>
> ______________________________________________________________________
> Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
> Gutl-***@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/
Loading...