dd ou qualquer outra aplicação não tem “algum tipo de verificação embutida” no sentido em que você provavelmente está pensando: ela não lê os dados do meio de armazenamento para comparar com o que foi escrito. Esse é o trabalho do sistema operacional.
Não é realmente possível fazer uma verificação de leitura para o hardware de um aplicativo. Funcionaria em alguns cenários, mas na maioria dos casos não conseguiria nada. O aplicativo pode ler de volta o que acabou de escrever se estiver gravando diretamente em um meio de armazenamento , mas isso normalmente seria lido em um cache na memória, o que não daria nenhuma garantia útil. Em o exemplo que você cita , dd está escrevendo para um pipe e, nesse caso, não tem controle sobre o que acontece aos dados mais abaixo na linha. No seu exemplo de rsync, uma segunda passagem de rsync --checksum é inútil: em teoria, pode pegar um erro, mas na prática, se ocorrer um erro, a segunda passagem provavelmente não relataria nada de errado, então você está desperdiçando esforço em algo que realmente não dá uma garantia útil.
No entanto, os aplicativos fazem verificar o que acontece com os dados, no sentido de que eles verificam se o sistema operacional aceitou a responsabilidade pelos dados. Todas as chamadas do sistema retornam um status de erro. Se uma chamada do sistema retornar um status de erro, o aplicativo deve propagar esse erro para o usuário, geralmente exibindo uma mensagem de erro e retornando um status de saída diferente de zero.
Tenha em atenção que dd é uma excepção: dependendo dos parâmetros da linha de comandos, dd pode ignorar alguns erros . Isso é extremamente incomum: dd é o único comando comum com essa propriedade. Use cat em vez de dd , assim você não corre o risco de corrupção e pode muito bem ser mais rápido .
Em uma cadeia de cópia de dados, dois tipos de erros podem surgir.
- Corrupção: um bit é invertido durante a transferência. Não há como verificar isso no nível do aplicativo, porque se isso acontecer, é devido a um bug de programação ou a um erro de hardware que provavelmente causará a mesma corrupção durante a leitura. A única maneira útil de verificar se tal corrupção não ocorreu é desconectar fisicamente a mídia e tentar novamente, de preferência em um computador diferente, caso o problema esteja na RAM.
- Truncamento: todos os dados que foram copiados foram copiados corretamente, mas alguns dos dados não foram copiados. Este vale a pena ser verificado algumas vezes, dependendo da complexidade do comando. Você não precisa ler os dados para fazer isso: basta verificar o tamanho.