dd pendurado e suspensão ininterrupta (quirk do kernel?)

Question

Então, isso tem me incomodado há anos.

Isso acontece com mais programas do que apenas dd, mas eu acho que isso acontece com muita frequência em programas que envolvem manipulação de sistemas de arquivos brutos.

Quando copio com dd - por exemplo, fazendo um disco USB inicializável fazendo sudo dd if=somelinuxdistro.iso of=/dev/sdb bs=64K status=progress , é como se todos os meus sinais fossem ignorados pelo aplicativo. (Ou pelo kernel no caso de SIGKILL ) htop mostra o status D , que aparentemente significa "sono ininterrupto". Ele pode ficar nesse estado por idades se houver uma falha de hardware e, em uso regular, não consigo encontrar nenhuma maneira de desconectá-lo do terminal para que eu possa continuar trabalhando - muitas vezes eu só acabo mudando para um terminal diferente para terminar o meu trabalho.

Eu já vi isso antes, mas eu nunca encontrei uma explicação do que é este estado ou porque o kernel se recusa a matar um processo nesse estado - ou o que exatamente o recomendado é fazer para evitar desperdiçando tempo. (Nem qualquer recomendação do que fazer quando isso acontece.)

Em suma: Eu gostaria de ter uma maneira confiável de forçar a eliminação de processos no estado D, ou pelo menos separá-los do terminal. E eu também gostaria de uma explicação do que está acontecendo em segundo plano para fazer com que eles fiquem nesse estado em primeiro lugar.

    

Answer 1

Se você não pode interromper uma "leitura ininterrupta" e isso não está relacionado a um servidor NFS desligado, você descobriu um erro de driver.

E / S para o armazenamento em segundo plano local não deve ter um tempo limite maior que 5-10 minutos. Então, se você digitar ^C ou ^Z e nada acontecer dentro de 10 minutos, há um erro de driver.

O pano de fundo é que o UNIX define que o chamado fast IO não é interrompido por sinais porque o IO rápido terminará após um período de tempo previsível.

Tornar o IO interrompido por sinais causa uma alta sobrecarga, já que é necessário voltar a um estado limpo. Tudo o que aconteceu depois de iniciar o IO precisa ser desenrolado e um retorno só pode acontecer de onde o IO foi iniciado.

Ainda pior, se um driver de armazenamento em segundo plano implementar IO interrompível, isso causaria problemas inatingíveis nos sistemas de arquivos acima desse driver. Você está usando um driver que deve ser usado como armazenamento em segundo plano para um sistema de arquivos ...

Você pode chamar dmesg e verificar as mensagens do kernel para o seu problema. Se a interrupção realmente não funcionar após 10 minutos (quando se espera que uma chamada de sistema de leitura ou gravação atinja o tempo limite e haja uma chance de matar dd entre dois desses syscalls), será necessário reinicializar.

Se este é um dispositivo na USB, você pode tentar puxar o dispositivo antes de reiniciar.