cp o rsync, ¿realmente vale la pena cp?

8

Espero que esto no cuenta como una pregunta sin una respuesta real, ya que parece que no puede encontrar una buena razón para usar cp(1)durante rsync(1)prácticamente en todas las circunstancias. ¿Debería uno preferir rsyncmás cp? ¿Hay alguna buena directriz para su uso?

  • rsync: Transfiere los diferenciales, puede usar compresión, puede usarse de forma remota (y segura), puede reiniciarse a pesar de una interrupción, incluso durante la transferencia de un solo archivo grande. '

  • cp: ¿Quizás es más simple de usar? ¿Es más rápido que rsync?

bash shell rsync utilities cp Soyuz
fuente
44
A veces, la sobrecarga de comparar es mucho más esfuerzo que simplemente copiar los bytes a ciegas.
bahamat
Misma pregunta con mejor respuesta: serverfault.com/questions/43014/…
Daniel

Respuestas:

9

cpes parte de coreutils, por lo tanto, está presente en todas partes. Además, se diseñó principalmente para copiar archivos dentro de una computadora.

rsyncno es parte de coreutils, ni siquiera está presente en el entorno predeterminado. Además, fue diseñado principalmente para transferir archivos a través de la red. También rsynctiene más dependencias en comparación con coreutils, sin embargo, esta diferencia no tiene mucho sentido.

PD: Por cierto, el uso de la CPU sigue siendo importante en los sistemas integrados.

prisa
fuente
6

La razón principal por la que no desea utilizar rsyncpara cada operación de copia es porque rsynctiene una sobrecarga de cálculo. Antes de que la transferencia de datos realmente comience, rsyncescanea todos los archivos. Luego, antes de cada archivo, se realiza una comparación. Esta sobrecarga no es insignificante, incluso con las CPU rápidas disponibles en 2012. Realizo este tipo de transferencias todo el tiempo, y en servidores de tamaño bastante decente, una vez que comienzas a tratar con grandes cantidades de datos, la sobrecarga puede llevar mucho tiempo.

No digo que no use rsync, en absoluto, use en rsynccualquier momento que pueda ahorrar algo de tiempo de transferencia. Simplemente no use rsynccuándo cppodría lograr lo mismo.

Lo que generalmente hago, primero trae los datos usando métodos de copia regulares. Luego, rsyncpara los cambios posteriores, que es cuando esas diferencias se pueden aprovechar.

JM Becker
fuente
¿Es un gran precio a pagar, dado lo poderosos que son nuestros procesadores hoy en día?
Soyuz
3
Grande es subjetivo, y cambiaría dependiendo de la cantidad de archivos vs tamaño de datos vs IO. Mi punto principal sería, no es insignificante, independientemente de los procesadores de hoy. Una cosa para recordar los procesadores de hoy en día, aún debe tratar con los datos de hoy.
JM Becker
Convenido. Las CPU no se aceleran en el vacío. Una de las mejores razones que tenemos para las CPU de GHz es la red de gigabits: una CPU más lenta simplemente no puede mantener una tubería de E / S tan grande. Las computadoras tienden a estar tan bien balanceadas como sabemos cómo hacerlas. Quite algo de la potencia de la CPU y parte de la capacidad de E / S queda inactiva. Aumente la demanda de E / S, y la CPU termina inactivando más, esperando la E / S.
Warren Young
3

Esperaría cpusar menos CPU cuando copie localmente porque no usa diffs, mientras que rsyncpuede reducir las escrituras cuando usa diffs. La compresión debe evitarse localmente porque tiene que leer y escribir todo el archivo / diff de todos modos y requiere cálculos adicionales.

scai
fuente
Entonces, todo se reduce al costo de la CPU o al costo de E / S
Soyuz
2
@soyuz, eso es cierto para los datos que han cambiado, en referencia a otros datos. Cuanto más pequeño es el diff, más rsyncse prefiere. Pero cuando no hay diferencia, rsyncsolo trae gastos generales sin beneficio adicional.
JM Becker
@TechZilla Creo que quieres decir, cuando no hay nada en común. Si no hay diferencias, rsync terminará pronto porque no hay nada que copiar, por lo que es mucho más preferido.
Izkata
@Izkata: Hay al menos una forma de rsynctener el doble de sobrecarga de E / S para dos archivos idénticos en comparación con el oculto cp: un tiempo de modificación modificado. Tendrías que dar --size-onlypara arreglar esto. La única otra forma en que puedo ver esto sería rsyncconfiar en las sumas de verificación del sistema de archivos, pero para la mayoría de los sistemas de archivos no son muy buenos predictores estadísticos de identidad.
Warren Young
3

Aparte de los gastos generales en el caso de una diferencia grande o inexistente, rsyncno parece tener un equivalente de cp --reflink=always, lo que puede ahorrar una enorme cantidad de datos si se copia dentro de un sistema de archivos que lo admite (crea copias de copia en escritura, por lo que los datos en común entre el original y la copia (que es, por supuesto, inicialmente todo) se almacenan solo una vez). rsyncSin embargo, es mejor para actualizar las copias de CoW, utilizando --inplace.

Darael
fuente