Cosa succede quando uccido 'cp'? È sicuro e ha delle conseguenze?


23

Quali sono le conseguenze per un filesystem ext4 quando termino un cpcomando di copia digitando Ctrl+ Cmentre è in esecuzione?

Il filesystem si corrompe? Lo spazio della partizione è occupato dal file copiato incompleto è ancora utilizzabile dopo averlo eliminato?

E, soprattutto, terminare un cpprocesso è una cosa sicura da fare?


1
Tieni presente che mentre le risposte sono corrette per ext4, i filesystem senza journaling potrebbero non essere altrettanto sicuri.
Ave

3
@Ave Journaling non ha nulla a che fare con questo. Le syscall sono atomiche indipendentemente dal filesystem che usi. Il journaling è utile in situazioni in cui il potere può essere improvvisamente perso.
foresta

Risposte:


22

Questo è sicuro, ma potresti non aver finito la copia.

Quando cpviene eseguito il comando, crea syscalls che indica al kernel di creare copie del file. Una syscall è una funzione che un'applicazione può chiamare che richiede un servizio dal kernel, come leggere o scrivere dati sul disco. Il processo userspace attende semplicemente che la syscall finisca. Se dovessi rintracciare le chiamate, sarebbe simile a:

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

Questo si ripete per ogni file che deve essere copiato. Nessuna corruzione si verificherà a causa del modo in cui funzionano queste syscalls. Quando vengono immesse syscall come queste, il segnale fatale avrà effetto solo dopo che la syscall è terminata , non mentre è in esecuzione. Per questo motivo, l'uccisione forzata del processo comporterà la sua conclusione solo al termine della syscall attualmente in esecuzione. Ciò significa che il kernel, dove vive il driver del filesystem, è libero di completare le operazioni che deve completare per mettere il filesystem in uno stato sano. Qualsiasi I / O di questo tipo non verrà mai terminato durante l'operazione, rendendoli operazioni atomiche.

È interessante notare che questo è il motivo per cui comandi come cppotrebbero non terminare immediatamente quando vengono uccisi. Se stai copiando un file molto grande e lo uccidi, anche con SIGKILL, il processo continuerà fino al termine dell'attuale syscall. Con un file di grandi dimensioni, ciò potrebbe richiedere del tempo, poiché il processo sarà ininterrotto.


2
@qwr È probabilmente la parte della libreria glibc, non cpse stessa. Ha varie funzioni di accesso ai file che lo usano internamente come valore.
foresta

2
Bella risposta! Non mi ero mai reso conto che ci fosse un ritardo nel terminare un cpSIGKILL dopo, anche se si trattava di file di grandi dimensioni ... forse la durata di quelle operazioni atomiche ininterrotte di un processo è troppo breve. La stessa spiegazione funziona per l'uccisione dde altri processi di lettura / scrittura del disco?
Seninha,

1
@Seninha Le operazioni sono piuttosto brevi perché gli accessi sono memorizzati nella cache, quindi puoi copiare molti più dati al secondo di quelli che il tuo disco può effettivamente gestire, se fatto a raffica. Se il file è molto grande e su un supporto lento, la cache può riempirsi e uccidere il processo può richiedere del tempo. Per quanto riguarda l'uccisione dd, ciò dipende da ciò che bshai impostato. Se è solo 512 (impostazione predefinita), dovrebbe terminare rapidamente. Se è più grande, potrebbe richiedere un po 'più di tempo.
foresta

3
I blocchi @qwr 128kb sono predefiniti cablati in coreutils durante la lettura da dispositivi a blocchi, questo viene fatto nel tentativo di ridurre al minimo le syscall. L'analisi è fornita nella fonte coreutils
Fiisch

1
@AndrewHenle Forse avrei dovuto dire che sono i metadati del filesystem che sono atomici. Hai ragione che una scrittura può essere parziale.
foresta

20

Poiché cpè un comando userspace, ciò non influisce sull'integrità del filesystem.

Ovviamente devi essere preparato che almeno un file non sarà stato copiato completamente se uccidi un cpprogramma runnning .


14
Perché il downvote? Solo perché è schily?
Stephen Kitt,

6
Sembra che ci sia sicuramente almeno una persona che declassa tutte le mie risposte. Conosci un modo per scoprire chi ha fatto il downvote?
schily,

2
Nemmeno i moderatori possono scoprire chi ha espresso voti specifici, comprensibilmente limitato ai dipendenti SO. Puoi utilizzare il link "Contattaci" per chiedere loro di indagare.
Philip Kendall,

1
Sarebbe piuttosto triste se un programma di spazio utente fosse in grado di compromettere l'integrità del filesystem. Nota: Naturalmente, ci possono essere, ci sono stati e ci saranno bug nelle implementazioni del filesystem. Nota n. 2: Inoltre, ovviamente, i programmi di spazio utente in esecuzione con privilegi elevati (ad es. CAP_SYS_RAWIOIn Linux o equivalenti in altri sistemi operativi) che danno loro accesso diretto al dispositivo sottostante del filesystem (ad es. sudo dd if=/dev/urandom of=/dev/sda1) Possono provocare ogni sorta di caos.
Jörg W Mittag,

3
E se un filesystem fosse abbastanza difettoso da corrompersi dopo un'interruzione cp, probabilmente verrebbe danneggiato anche da un finito cp...
ilkkachu,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.