☰

¿Son cp/rsync asíncronos?

tag-icon • tag-icon bash rsync tar cp
¿Son cp/rsync asíncronos?

Estamos ejecutando un script de respaldo que primero copia un archivo a un destino y luego tarlo ejecuta.

DIR2BCK='/foo/bar'
TMPDIR=$(mktemp -d)
rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1
tar czf /tmp/foo.backup.tar ${TMPDIR}

Después de ejecutar este último comando, en ocasiones se muestra la siguiente advertencia:

/tmp/tmp.blqspkA136: el archivo cambió mientras lo leíamos

Copiamos el destino a un directorio temporal precisamente para evitar cambios de archivos en el momento de la compresión. Este comportamiento también es reproducible cuando se utiliza el cpcomando en lugar de rsync. Toda mi vida pensé que estos comandos eran sincrónicos, pero esta advertencia parece mostrar lo contrario.

Si pongo un sleepcomando entre rsync/ cpy las tarlíneas, la advertencia no aparece, pero considero que esta no es una solución del todo limpia.

Algunos hechos:

  • Intenté agregar un synccomando entre los comandos rsyncy tarcon el mismo resultado.

  • Como lo sugirió @jcbermu, también intenté cambiar el script para que las dos líneas sean:

    rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
wait

    Ejecuté el script varias veces y algunas mostraron el mismo comportamiento, afirmando que el archivo cambió al copiarlo.

  • El sistema de archivos utilizado es EXT4 tanto para ${TMPDIR}como para ${DIR2BCK}.

  • ${DIR2BCK}está en un sistema de archivos remoto; en realidad, este es un punto de montaje samba de una máquina remota. ${TMPDIR}está en el sistema de archivos local. Sin embargo, cambiar ${DIR2BCK}al sistema de archivos local no supone ninguna diferencia.
  • Todos los sistemas de archivos están basados ​​en hardware RAID-5.

¿Son estos comandos realmente sincrónicos? Si no es así, ¿hay alguna manera de hacerlo así o un comando alternativo?

Respuesta1

Una solución es reescribirlo como:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 ; tar czf foo.backup.tar ${TMPDIR}

Entonces, tarno empezará hasta que rsynctermine.

La otra solución es enviar el cp/ rsyncal fondo y esperar hasta que termine con el comando wait.

Por ejemplo:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
wait
tar czf foo.backup.tar ${TMPDIR}

El último &en la rsynclínea envía la ejecución a un segundo plano (se convierte en unniñode la sesión actual), y luego waitobliga a esta sesión de shell a esperar hasta que todos los elementos secundarios hayan terminado para continuar.

Respuesta2

Puse un comando de suspensión entre las líneas rsync/cp y tar, la advertencia no aparece, pero considero que esta es una solución no del todo limpia.

Bueno para ti o tener estándares. ¿Qué pasa si, en lugar de dormir, utilizas:

sincronización sudo; eco 3 | sudo tee /proc/sys/vm/drop_caches

¿Consideras que es una buena solución?

Nota: /proc/sys/vm/drop_caches parece ser lo que usa Ubuntu y no se espera que sea un enfoque que funcione en todos los Unix (aunque tal vez en todos los Linux). Lo menciono después de haber leído.https://ubuntuforums.org/showthread.php?t=589975y, después de leer un informe inicial que cuestiona la seguridad de hacer esto, leer más publicaciones en hilos del foro que confirman su seguridad.

información relacionada