¿Qué sucede cuando mato 'cp'? ¿Es seguro y tiene alguna consecuencia?

¿Cuáles son las consecuencias para un sistema de archivos ext4 cuando termino un cpcomando de copia escribiendo Ctrl+ Cmientras se está ejecutando?

¿El sistema de archivos se corrompe? ¿El espacio de la partición ocupado por el archivo copiado incompleto todavía se puede usar después de eliminarlo?

Y, lo más importante, ¿es cpseguro terminar un proceso?

— Seninha
fuente

Tenga en cuenta que si bien las respuestas son correctas para ext4, los sistemas de archivos sin registro en diario pueden no ser tan seguros.

— Ave

@Ave Journaling no tiene nada que ver con esto. Las llamadas al sistema son atómicas independientemente del sistema de archivos que utilice. El registro en diario es útil en situaciones en las que el poder puede perderse abruptamente.

— bosque

Respuestas:

Es seguro hacerlo, pero, naturalmente, es posible que no haya terminado la copia.

Cuando cpse ejecuta el comando, realiza syscalls que indican al núcleo que haga copias del archivo. Una llamada al sistema es una función a la que puede llamar una aplicación que solicita un servicio del núcleo, como leer o escribir datos en el disco. El proceso de espacio de usuario simplemente espera a que finalice la llamada al sistema. Si tuviera que rastrear las llamadas, se vería algo así como:

open("/home/user/hello.txt", O_RDONLY)           = 3
open("/mnt/hello.txt", O_CREAT|O_WRONLY, 0644)   = 4
read(3, "Hello, world!\n", 131072)               = 14
write(4, "Hello, world!\n", 14)                  = 14
close(3)                                         = 0
close(4)                                         = 0

Esto se repite para cada archivo que se va a copiar. No se producirá corrupción debido a la forma en que funcionan estas llamadas al sistema. Cuando se ingresan llamadas de sistema como estas, la señal fatal solo tendrá efecto una vez que la llamada de sistema haya finalizado , no mientras se está ejecutando. Debido a esto, matar el proceso por la fuerza solo hará que finalice una vez que finalice la llamada al sistema en ejecución. Esto significa que el núcleo, donde vive el controlador del sistema de archivos, es libre de terminar las operaciones que necesita completar para poner el sistema de archivos en un estado sano. Cualquier E / S de este tipo nunca terminará en la mitad de la operación, lo que las convierte en operaciones atómicas.

Curiosamente, esta es la razón por la cual los comandos como cppueden no terminar inmediatamente cuando son asesinados. Si está copiando un archivo muy grande y lo mata, incluso con SIGKILL, el proceso seguirá ejecutándose hasta que finalice la llamada al sistema actual. Con un archivo grande, esto puede llevar un tiempo, ya que el proceso estará en un estado ininterrumpido.

— bosque
fuente

@qwr Es muy probable que sea parte de la biblioteca glibc, no en cpsí misma. Tiene varias funciones de acceso a archivos que internamente lo usan como valor.

— bosque

¡Gran respuesta! Nunca me había dado cuenta de que hay un retraso en terminar un cpSIGKILL después de hacerlo, incluso cuando se trata de archivos grandes ... tal vez la duración de esas operaciones atómicas ininterrumpidas de un proceso es demasiado corta. ¿Funciona la misma explicación para matar ddy otros procesos de lectura / escritura de discos?

— Seninha

@Seninha Las operaciones son bastante breves porque los accesos se almacenan en caché, por lo que puede copiar muchos más datos por segundo de los que su disco realmente puede manejar, si se realiza en ráfagas. Si el archivo es realmente grande y está en un medio lento, entonces el caché puede llenarse y matar el proceso puede llevar algún tiempo. En cuanto a matar dd, eso depende de lo que bshayas establecido. Si solo es 512 (el valor predeterminado), entonces debería terminar rápidamente. Si es más grande, puede tardar un poco más.

— bosque

Los trozos @qwr de 128 kb son predeterminados por cable en coreutils cuando se leen desde dispositivos de bloque, esto se hace en un esfuerzo por minimizar las llamadas al sistema. El análisis se da en la fuente coreutils: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h

— Fiisch

@ AndrewHenle Quizás debería haber dicho que son los metadatos del sistema de archivos los que son atómicos. Tiene razón en que una escritura puede ser parcial.

— bosque

Dado que cpes un comando de espacio de usuario, esto no afecta la integridad del sistema de archivos.

Por supuesto, debe estar preparado para que al menos un archivo no se haya copiado por completo si elimina un cpprograma en ejecución .

— astuto
fuente

¿Por qué el voto negativo? ¿Solo porque es astuto?

— Stephen Kitt

Definitivamente parece haber al menos una persona que rechaza todas mis respuestas. ¿Conoces una manera de averiguar quién hizo el voto negativo?

— schily

Ni siquiera los moderadores pueden averiguar quién hizo votos específicos, lo que está comprensiblemente restringido a los empleados de SO. Puede usar el enlace "contáctenos" para pedirles que investiguen.

— Philip Kendall el

Sería bastante triste si un programa de espacio de usuario pudiera comprometer la integridad del sistema de archivos. Nota: Por supuesto, puede haber, ha habido y habrá errores en las implementaciones del sistema de archivos. Nota # 2: Además, por supuesto, los programas de espacio de usuario que se ejecutan con privilegios elevados (por ejemplo, CAP_SYS_RAWIOen Linux o el equivalente en otros sistemas operativos) que les dan acceso directo al dispositivo subyacente del sistema de archivos (por ejemplo sudo dd if=/dev/urandom of=/dev/sda1) pueden causar todo tipo de estragos.

— Jörg W Mittag

Y si un sistema de archivos con errores fue suficiente para obtener corrompido después de una interrupción cp, es probable que se corrompe de un acabado cpdemasiado ...

— ilkkachu