O que acontece quando eu mato 'cp'? É seguro e tem consequências?

Quais são as consequências para um sistema de arquivos ext4 quando encerro um cpcomando de cópia digitando Ctrl+ Cenquanto ele está em execução?

O sistema de arquivos é corrompido? O espaço da partição ocupado pelo arquivo copiado incompleto ainda pode ser utilizado após a exclusão?

E, o mais importante, encerrar um cpprocesso é algo seguro a se fazer?

— Seninha
fonte

Lembre-se de que, embora as respostas estejam corretas para o ext4, os sistemas de arquivos sem registro no diário podem não ser tão seguros.

— Ave

O @Ave Journaling não tem nada a ver com isso. Os syscalls são atômicos, independentemente do sistema de arquivos que você usa. O registro no diário é útil em situações em que a energia pode ser perdida abruptamente.

— forest

Respostas:

Isso é seguro, mas naturalmente você pode não ter terminado a cópia.

Quando o cpcomando é executado, ele faz syscalls que instruem o kernel a fazer cópias do arquivo. Um syscall é uma função que um aplicativo pode chamar que solicita um serviço do kernel, como ler ou gravar dados no disco. O processo de espaço do usuário simplesmente aguarda a conclusão do syscall. Se você rastrear as chamadas, seria algo 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

Isso se repete para cada arquivo que deve ser copiado. Nenhuma corrupção ocorrerá devido à maneira como esses syscalls funcionam. Quando syscalls como estes são inseridos, o sinal fatal só terão efeito após a syscall tenha terminado , não enquanto ele está sendo executado. Por esse motivo, a eliminação forçada do processo só fará com que ele seja encerrado após a conclusão do syscall atualmente em execução. Isso significa que o kernel, onde reside o driver do sistema de arquivos, é livre para concluir as operações necessárias para colocar o sistema de arquivos em um estado saudável. Qualquer E / S desse tipo nunca será encerrada no meio da operação, tornando-as operações atômicas.

Curiosamente, é por isso que comandos como cpnão podem terminar imediatamente quando são mortos. Se você estiver copiando um arquivo muito grande e o matando, mesmo com o SIGKILL, o processo ainda será executado até que o syscall atual termine. Com um arquivo grande, isso pode demorar um pouco, pois o processo estará em um estado ininterrupto.

— floresta
fonte

@qwr Isso provavelmente faz parte da biblioteca glibc, não cpela mesma. Possui várias funções de acesso a arquivos que usam internamente isso como um valor.

— forest

Ótima resposta! Eu nunca tinha percebido que há um atraso no término de um cpSIGKILLing depois, mesmo ao lidar com arquivos grandes ... talvez a duração dessas operações atômicas ininterruptas de um processo seja muito curta. A mesma explicação funciona para matar dde outros processos de leitura / gravação de disco?

— Seninha

@Seninha As operações são muito breves porque os acessos são armazenados em cache, para que você possa copiar muito mais dados por segundo do que sua unidade pode suportar, se for feito em rajadas. Se o arquivo for realmente grande e em um meio lento, o cache poderá ser preenchido e a interrupção do processo poderá levar algum tempo. Quanto à matança dd, isso depende do que bsvocê definir para isso. Se for apenas 512 (o padrão), deve terminar rapidamente. Se for maior, pode demorar um pouco mais.

— forest

Os blocos @qwr de 128kb são padrão no coreutils ao ler de dispositivos de bloco, isso é feito com o objetivo de minimizar as chamadas de sistema. Análise é dado na fonte coreutils: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h

— Fiisch

@AndrewHenle Talvez eu devesse ter dito que são os metadados do sistema de arquivos que são atômicos. Você está certo de que uma gravação pode ser parcial.

— forest

Como cpé um comando userspace, isso não afeta a integridade do sistema de arquivos.

Obviamente, você precisa estar preparado para que pelo menos um arquivo não tenha sido copiado completamente se você matar um cpprograma em execução .

— esperto
fonte

Por que o voto negativo? Só porque é manhoso?

— Stephen Kitt

Definitivamente parece haver pelo menos uma pessoa que rebate todas as minhas respostas. Você conhece uma maneira de descobrir quem fez o voto negativo?

— schily

Nem mesmo os moderadores podem descobrir quem fez votos específicos - o que é compreensivelmente restrito aos funcionários da SO. Você pode usar o link "entre em contato" para solicitar que investiguem.

— Philip Kendall

Seria muito triste se um programa de espaço de usuário pudesse comprometer a integridade do sistema de arquivos. Nota: É claro que pode haver, houve e haverá erros nas implementações do sistema de arquivos. Nota 2: Além disso, é claro, os programas do espaço do usuário em execução com privilégios elevados (por exemplo, CAP_SYS_RAWIOno Linux ou o equivalente em outros sistemas operacionais) que lhes dão acesso direto ao dispositivo subjacente do sistema de arquivos (por exemplo sudo dd if=/dev/urandom of=/dev/sda1), podem causar todo tipo de confusão.

— Jörg W Mittag

E se um sistema de arquivos foi suficiente buggy para ser corrompidos depois de uma interrupção cp, seria provavelmente ter corrompido a partir de um terminou cptambém ...

— ilkkachu