esporadicamente, o rsync demora excepcionalmente

Question

Fazemos backups com o rsync assim:

rsync -axH --inplace --delete --delete-excluded \
--exclude-from=excludes --stats \
--link-dest="${previous?}" "${source?}"/ "${dest?}"/"${stamp?}"

$ pontos anteriores ao backup anterior, para que arquivos inalterados sejam criados usando hardlinks. O sistema de arquivos de destino $ dest está em um disco rígido USB externo com nada mais do que a coleção de backups.

Este método é incrivelmente rápido na maioria dos casos. No sistema de teste, cada backup tem cerca de 200 GB e contém alguns grandes maildirs - ainda assim todo o rsync (desde que não tenha sido alterado muito desde a última execução) leva apenas cerca de um minuto.

No entanto, em casos raros, talvez a cada 100 execuções, em média, são muito longas, cerca de 20 minutos ou mais. As estatísticas do rsync mostram nada incomum. O sistema host não mostra atividade incomum durante essas execuções. Nada empolgante no syslog.

Parece ser pior em alguns sistemas de arquivos (por $ dest) do que em outros. Os números acima são para EXT4. No JFS, por exemplo, as execuções normais levam cerca de 3 minutos e as execuções excepcionais são menos graves, mas ainda são um problema para nós.

Uma olhada na saída de depuração do rsync revela que, durante as execuções longas, certos arquivos (grandes) são considerados não atualizados, embora não tenham sido alterados no remetente. Não são criados hardlinks para esses arquivos, como uma olhada em suas revelações de inode. Mas as estatísticas do rsync não mostram mais bytes transferidos do que o normal e, a partir da observação dos LEDs de atividade do disco rígido, somente a unidade de destino está funcionando nesses casos. Esses arquivos são copiados no destino de um diretório para outro? Isso está se tornando não apenas um problema de desempenho, mas também pode levar a um consumo desnecessário de espaço.

Caso seja importante: diretamente antes do backup, o mais antigo dos backups existentes é excluído usando:

rsync -a --delete empty/ "${dest?}"/"${old?}"

em que 'empty' é um diretório vazio. Isso é muito mais rápido que 'rm -fr'.

Alguém poderia oferecer explicações possíveis para isso e talvez uma cura?

Usando o protocolo rsync versão 3.1.0 versão 31.

    

Answer 1

Resposta curta: o culpado foi a maneira como excluímos os diretórios de backup antigos, ou seja, rsyncing um diretório vazio. Agora usamos:

find "${old?}" -delete

Isso também é rápido e evita o problema.

Resposta mais longa: na verdade, as execuções que levaram excepcionalmente por muito tempo foram absolutamente deterministas. Nós sempre mantemos um número de, digamos, backups e excluímos o mais antigo antes de executar um novo. Todos os (n + 1) backups demoraram muito tempo. Parece que, ao excluir um backup antigo com o rsync, parte dele é de alguma forma invalidada para a operação --link-dest, de modo que alguns arquivos não são vinculados, mas sim copiados (aparentemente copiados do próprio sistema de arquivos de destino). Esse procedimento de cópia inicia um novo "período", que chega ao fim quando o primeiro backup dele é excluído, o que acontece após n execuções. Isto é provavelmente devido a um bug no rsync ou no kernel, mas eu não investigarei mais.